75

Company pays me to test good and not be careless. You are asking this question here - you are not careless, you care about the job you do and the things you can improve on. Don't take it personally and be professional The point of finding bugs is not to blame anyone, but to enhance the product's quality. If your manager is blaming you personally, this is ...


38

There will always be smart technical people who do not like to code. There will always be ways of taking advantage of their talents. I'm a coder. And I love my manual tester. She see's the world differently than I do and that's exactly what I need. What I hate are manual test scripts that pile up without any automation behind them. The solution isn't to ...


35

Please do not resign. As alecxe has said in his post, Perfect Software is a myth. I would like to add, the difference between a tester and a developer is: It is very difficult to see how much a tester has contributed. When a developer is given a task to develop a feature, this developer will produce a tangible result, e.g. a clickable button. But when a ...


33

They cannot be 100% sure of a bug free system. They can increase their confidence that the system is bug-free by use of static analysis and testing. Some people advocate bebugging as a way of estimating how many bugs remain in a system. There are at least two forms of static analysis. If the system goes wrong then it goes wrong. There are assorted methods ...


28

NASA's Software Assurance Technology Center at Goddard once did a test to see how few defects they could get in some code for the shuttle. After a truly rigorous and vastly, vastly expensive process, with multiple levels of review, using very small functions to minimize the risk in each, they managed to get it down to 1 defect per 10,000 lines of code (might'...


27

I'd like to address the reporting aspect of the question. You say... I just keep on writing excellent test cases and executing them, but then I don't have anything to show to the management. Sometimes it makes me think that I am not providing any value to the product Even in the perfect world where the software leaves the developers' hands 100% bug free ...


26

Testing no longer means testing Confused? We can imagine! The purpose of testing used to be fairly clear–“Testing is the process of executing a program with the intent of finding errors”. This changes when adopting agile and lean development. read more... I think the testing manifesto has it at the right end. Focus on preventing defects over ...


24

A hard coded sleep statement is generally supposed to represent some sort of mocked delay in the application that doesn't exist during testing. The harmful aspect of this is that a hard coded value can't represent the complexity that actually exists in what its mocking. Take for example a network delay. Your production system usually takes 4 seconds to go ...


23

It is very admirable for you to consider a tester's role from this perspective. The hard cold fact: No one is happy when there is a bug found in their code. Imagine yourself as a developer, you have done coding, you have done unit testing and you feel pretty good when you check in your code. How would you feel when someone shows up shortly before code ...


23

Yes, while rather crude and possibly not the most graceful of test cases, such 'abusive' test cases are an important tool in stepping off 'happy path' thinking and testing. Effectively a test like this is a crude load/response test. While in theory it shouldn't happen in the real world environment, the fact that a bug was discovered with such abusive ...


22

The traditional definitions would be something like this: A test suite is a collection of test cases related to the same test work. You might have a suite for regression, one for build verification tests, a suite that is specific for a component, and so on. A test plan is generally a document which describes testing approach and methodologies being used for ...


20

All non-trivial software has bugs. Risk is part of life. It is foolhardy to attempt to remove all possible risk, because in the process, you introduce the risk that you will accomplish nothing. Even if your algorithm and your implementation are perfect, your software does not live in a vaccuum: it depends on compilers, interpreters, libraries, operating ...


19

If I was being interviewed and was asked this question, first of all i would start off by trying to quench my curiosity. How much time do i have? What type of a toaster is it? How much power limit does it operate on as per the vendor? Does the vendor provide any user manual or claims documentation? How does it work? Is it timer based or manual toaster? What ...


19

First of all, "no technical solution" isn't exactly correct. From my understanding, the technical solution is in fact very simple; either: improve the Excel macro to provide better validations or, make the import function of your application more robust to prevent errors (abort the import) and to clearly signal the problem values to the user. I propose you ...


18

As the other answers have said, do not blame yourself. Nobody can test any piece of software completely, any more than anyone can write completely bug-free software. It's too complex. I'm going to quote an example from an article I wrote over at the Ministry of Testing Dojo: Ten Misconceptions About Software Testing. The quote is from a section explaining ...


16

Katrina, It is possible to include some important approaches and goals for software testing that tend to be beneficial in creating effective test case scenarios in a wide variety of testing situations. They include: Don't repeat yourself (e.g., keep scenarios "DRY"); don't repeat combinations of test inputs more than you need to because you would find ...


16

Yes and No More often than not, an inverted pyramid (ice cream cone) is an anti-pattern, but there are circumstances where it is not. Your example of needing to rebuild an API in a different language is one such example. Some other circumstances where you might want to invert the pyramid include: You have an integration to a third party API. Your lowest ...


16

Great Question Niels. Given that it will depend on the given situation I would consider approaching this as a data gathering exercise. I would investigate what is the normal distribution from many repeated runs. If 99% of the time it remains correct after 1 minute (i.e. after 1 minute doesn't then change again) and the business considers a 1% failure (and ...


15

All engineers (application and automation) test algorithms by providing known inputs and having knowledge of the expected output in order to perform verifications. The verification values can be found by manual calculations and/or different algorithm(s). If the algorithm and manual calculation approach are not known another approach is BDD (Behaviour-Driven ...


14

For testers to become more valuable and helpful for the development team... Focus on helping developers earlier in the process Focus on adding value much earlier in the process. Focus on working with developers before and as the code is being written, not after it has been deployed in a testing/staging environment. This will help change your role from a ...


14

Test automation can NEVER replace manual testing. One classic argument is test automation can never catch random bugs that can be caught via manual exploratory testing. I have had two colleagues in the past who did not know any coding skills and hated coding, but they were extremely good manual testers, were able to catch bugs no one else could. Having ...


13

A requirement is typically a general statement, whereas a use case is typically a specific statement implied or derived from the requirement. A requirement may map to multiple use cases. A scenario might be a set of background assumptions that put a use case in context, or it might be grouping of use cases. Here is a contrived example. The requirement is ...


13

A key strategy for me is to convince the business of what needs to be tested where, otherwise... they'll end up directing testing everything through the UI... So the two key main points I am making to my business are the need for test automation that performs well in terms of two key factors: Speed Reliability Success in both speed and reliability for ...


13

Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve. Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest ...


12

Welcome to SQA, Ana. I see at least two questions: Does it make sense to distinguish between focused tests and workflow tests? Yes, it does. A focused test concentrates on a particular feature, including things like edge conditions. It attempts to answer the question, "Does this feature work in all circumstances?" A workflow test verifies that the ...


12

There is definitely a focus on test automation, not automated testing—simply because the latter is hard to do. I think this is related to the testing vs. checking debate (started by James Bach and Michael Bolton): Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: ...


11

You're asking a unicorn question. Why? Because you've skipped over the point of all that work. It doesn't matter what proportion of different types of testing you do, it doesn't matter what your organisation is, and it doesn't matter what technologies you use, if you don't know what information your stakeholders want to discover from your testing. That's ...


11

Combinatorial testing is an approach to testing an operation that has many inputs. For that website, I would start by identifying the operations. Sometimes there will be a specification for the system, but often there is not, and in any case the specification is unlikely to match the system in every detail. I recommend reading the specification and then ...


11

You could setup personas which are designed around real world of users. We have found this quite useful and it really helps to provide a fresh perspective e.g. Today I'm going to be Andy, the super user of the system. Andy is very sharp with numbers and is the user that is responsible for the administration of the system. He enjoys watching sports on the ...


11

Add an automated test for each defect. Make sure they never return. Now it is a short cycle, you caught it fast. I have seen long cycles. One client asking to remove/change/fix something. Release some months later, one client complains something is missing. The team fixes it, until the other clients comes back. You need someway to document the changes. I ...


Only top voted, non community-wiki answers of a minimum length are eligible