Analyzing and Interpreting Test Results - Software Testing: Testing Across the Entire Software Development Life Cycle - page 181

12.4 DEFECT DISCOVERY FOCUSING ON THE
DEFECT BACKLOG

The fi rst testing metric that we talked about at the beginning of this chapter was the
number and ratio of planned test cases versus attempted test cases to give us a sense
of how far we have progressed with our planned testing activities. The second testing
metric that we talked about is the number and ratio of attempted test cases versus
unsuccessful test cases to give us a sense of how defect free the testers are fi nding
the software at that point in the testing schedule.
Successful incremental defect tracking can provide a third testing metric nor-
mally called the defect backlog. If your testing has discovered 300 software defects
and development has successfully corrected 100 of these defects, then a backlog of
200 defects still needs to be corrected. The challenge for the development team is to
determine if there is enough time and programming and testing resources available
to reduce the defect backlog to zero before the development due date. Most times
the answer is “no.” The challenge then becomes one of the developers and testers
reviewing the defect backlog to identify more severe defects for correction fi rst. The
hope is that when development time runs out, the remaining defects in the defect
backlog are minor and will not adversely impact the software user's business. The
residual uncorrected defect backlog typically becomes part of an interim fi x pack or
unfi nished work for the next release.
In simple terms, the defect backlog is the list of all defects on the defect tracking
log that have not been corrected by the reporting date, usually weekly. If the defect
tracking log in Figure 12.2 is updated with a week's worth of developer correction
effort, the uncorrected defects become the defect backlog shown in Figure 12.3.

Figure 12.3 The defect backlog