Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

When do you decide to stop testing, for me it boils down to -

  1. Allocated time is exhausted
  2. No high severity/priority defects are found

Any other pointers which you consider while deciding to stop testing?

share|improve this question
    
This question feels like a "your answer is provided along with the question, and you expect more answers: “I use ______ for ______, what do you use?” which is should not be asked, voting to close. –  Bruce McLeod May 4 '11 at 21:51
add comment

closed as not constructive by Bruce McLeod, Dan Snell, Dori May 5 '11 at 2:10

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers

up vote 8 down vote accepted

The notion of "when do you" stop testing is a misnomer. The goal of QA should be to assess the risks and to report them to the team and product owner. It is up to the team to decompose the risks and assign a severity to them.

Therefore the decision to stop testing is a team/product owner decision. Stopping occurs when the level of risk is at an acceptable level. Defining an acceptable level is where the true difficulty lies.

share|improve this answer
add comment

Short answer... Never. :)

Long answer...

When you are out of money, or the program is no longer developed. But then you still have to provide support.

And that's all there is to it really.

There is no other point to regard. You always have to test as long as the project is developed in some way. And then STILL. You could find legacy bugs, old bugs, which haven't been found yet.

So really... You never stop with testing.

share|improve this answer
    
well said +1.... –  Tarun May 4 '11 at 17:06
    
thanks Tarun. :) –  Hannibal May 5 '11 at 6:25
add comment

You should decide, as part of your product planning, what your criteria are for shipping. That includes your test bar. For some products you may say "I'll test all I can before the ship date". For others, like the products I work on, there are quite a few explicit quality metrics they have to meet, particularly in the area of security.

Note that inevitably, no matter what criteria you set at the beginning, the final decision about whether the product is 'good enough' tends to be complex, relying as much on tradeoffs and expertise as it does on your original intentions when you started design.

share|improve this answer
add comment

I definitely agree with #1. You may be breaking company policy by continuing to work on a project that has been cut off for funding.

I don't necessarily agree with #2. How do you know no defects are found if you stop? Now, if you're saying "Go until you're out of time, and until there's no major known defects" I guess it makes sense, but if you are out of time, you're out of time - period. You'll have to get more time allocated to test the new changes. This may differ depending on your corporate setup, of course.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.