Interview Questions

How to choose which defect to remove in 1000000 defects? (because It will take too much resources in order to remove them all.)

Software QA/Testing Technical FAQs

(Continued from previous question...)

How to choose which defect to remove in 1000000 defects? (because It will take too much resources in order to remove them all.)

Are you the programmer who has to fix them, the project manager who has to supervise the programmers, the change control team that decides which areas are too high risk to impact, the stakeholder-user whose organization pays for the damage caused by the defects or the tester?
The tester does not choose which defects to fix.
The tester helps ensure that the people who do choose, make a well-informed choice.
Testers should provide data to indicate the *severity* of bugs, but the project manager or the development team do the prioritization.
When I say "indicate the severity", I don't just mean writing S3 on a piece of paper. Test groups often do follow-up tests to assess how serious a failure is and how broad the range of failure-triggering conditions.
Priority depends on a wide range of factors, including code-change risk, difficulty/time to complete the change, which stakeholders are affected by the bug, the other commitments being handled by the person most knowledgeable about fixing a certain bug, etc. Many of these factors are not within the knowledge of most test groups.

As a tester we don't fix the defects but we surely can prioritize them once detected. In our org we assign severity level to the defects depending upon their influence on other parts of products. If a defect doesnt allow you to go ahead and test test the product, it is critical one so it has to be fixed ASAP. We have 5 levels as

Dev can group all the critical ones and take them to fix before any other defect.

Priority/Severity P1 P2 P3

Generally the defects are classified in aboveshown grid. Every organization / software has some target of fixing the bugs.
Example -
P1S1 -> 90% of the bugs reported should be fixed.
P3S3 -> 5% of the bugs reported may be fixed. Rest are taken in letter service packs or versions.

Thus the organization should decide its target and act accordingly.
Basically bugfree software is not possible.

Ideally, the customer should assign priorities to their requirements. They tend to resist this. On a large, multi-year project I just completed, I would often (in the lack of customer guidelines) rely on my knowledge of the application and the potential downstream impacts in the modeled business process to prioritize defects.
If the customer doesn't then I fell the test organization should based on risk or other, similar considerations.

(Continued on next question...)

Other Interview Questions