How to avoid missing defect in Software Testing?

Posted on Aug 11 2012 - 6:25am by Raj

Missing defects is a very sensitive topic although omission of defects occurs on every project.  The article below suggests some effective ways to avoid slipping defects while testing.
There are various reason which could lead to defect slippage, few of them which you might have faced as tester are:
•    Test schedules are not flexible enough to align with the constantly changing release scope and plan
•    Business scenarios/use cases are not in place thus testers cannot visualize requirements.
•    Ineffective communication plan with limited involvement from various stakeholders to manage dependencies, issues, risks and defect prioritization
•    Absence of standard strategy for Test Data creation and management.
•    Limited time allotted for testing
•    Not enough resources assigned for test case writing and execution
As per Caper Jones study – Poor software quality has become one of the most expensive topics in human history: > $150 billion per year in U.S.; > $500 billion per year world wide.Further, Projects cancelled due to poor quality >15% more costly than successful projects of the same size and type.
In a perfect world, all applications would be completely tested, in all possible scenarios and environments, before the application is released into production (regardless of whether it takes weeks or months to complete 100 percent testing). Since this is not feasible as it involves huge investment and although testing team struggles with tight timelines and lack of sufficient resources to perform testing, still missing defects can be detected earlier.
With the focus of your testing on business objectives, business complexity, and the cost of failure. Well defined test cases and test strategies, as well as strong preparatory work can help you to mitigate the risk of missing defects.
Here a few of my views:
1.    Defining test strategy and performing preparatory work before testing is very important. Following activities should be performed before commencing testing:
•    Setup Test Strategy, testing processes and tools
•    Test data creation / usage guidelines
•    Business Rampup, requirements & testability review
•    Test Planning & Scheduling
•    Environment Setup & Shake-out
•    Test Scenario Creation & Review (Progression/Regression/UAT Packs)
•    Test Data Creation
2, Create test scenarios for end to end testing which run across the integrated modules of application.
3.    The focus should be to find as many defects as possible during the first cycle of testing. This insures defect fixing during early stage of project hence minimizing cost of quality.  
4.    The defect description should be clear and concise so that while fixing defect developer should not miss any of the scenario.

The other aspect is to estimate defects and then monitor the number of defects against the estimates. This helps in analyzing the missing defects during any stage. Defect estimation in a project involves estimating the defect injection at various stages and defect detection by various QC activities. The basis for estimating the defects injected/detected in a project is by using historical data. Either data on similar projects from the process database, or data from process capability baseline, can be used. The procedure for estimating the defects is same whatever be the basis chosen by the project.

Following are possible actions when deviations are beyond limits


Possible Reason

Actions to consider

If defects found are less than limits

Work product was very simple

· Combine reviews


Reviews may not be thorough

Check coverage rate; if too low, reschedule a review, perhaps with a different team


Reviewers do not have sufficient training on group reviews or experience with the reviewed material

· Schedule or conduct group review training

· Re-review with a different team


Work product is of very good quality

· Confirm this by coverage rate, experience of the developer, reviewers, etc.; Revise defect prediction in down-stream activities

If defects found are more than limits

Work product is of low quality

· Examine training needs for developer

· Consider reassigning future tasks


Work product is very complex

· Ensure good review or testing downstream

· Increase estimates for system testing

· Break the work product into smaller components


Too many minor defects (and too few major defects)

Identify cause of minor defects; correct for future by suitably enhancing checklists and making developers aware of the common causes


Reference document against which review was done is not precise and clear

Get the reference document reviewed and approved



Reviewed modules are the first ones in the project

· Analyze the defects, update review checklist, and inform developers

· Schedule training

Possible Reason

Actions to consider

If actual number of defects found is less than estimate by more than allowable limit

Work product is of high quality

Identify reason and see if there are possible lessons for the project or for the process


Inadequate testing

· Check the effort spent on testing; review the test plan and enhance it

· Schedule further testing


Very thorough execution of earlier quality control activities

· Examine all review and testing records for the project

· Check if there are possible lessons for the project on the process


Defect estimates are too high

Identify cause and correct estimates

If actual number of defects found is more than estimate by more than allowable limit

· Inadequate execution of quality control activities so far

· Insufficient reviews and unit tests planned

· Examine all testing and review records

· Schedule reviews of critical modules before continuing with testing

· Enhance test plan and schedule further testing

· Review estimates and plans for acceptance


Defect estimates are too low

Identify cause and correct estimates

About the Author

Leave A Response