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

for each defect that they correct. Up to this point, all of the defect tracking informa-
tion has come from the tester who discovers and logs the defect. Now a reporting
partnership is established where both test team and development team contribute
data to the defect tracking log for defect analysis. Figure 12.4 shows how Figure 12.3
defect tracking log might appear with a code earmark column included.
This augmented defect tracking log can be used for root cause analysis. There
are a number of good statistical textbooks available that provide the mathematical
basis and practical application of root cause analysis to software defect logs. [48]
The simplifi ed explanation of root cause analysis for testing is the mathematical
search for the “buggiest” code. This search can be accomplished by a simple fre-
quency count of corrected defect code earmarks, ordered with the most frequently
occurring code earmarks fi rst. Clusters or groupings of defects will arise by code
earmark. This kind of analysis is most helpful during the fi rst third to fi rst half of the
software development cycle when the software is least stable and more susceptible to
large numbers of corrections and updates.
Figure 12.5 shows the possible results of a ranked frequency count of 2,000
defects corrected by the end of the preliminary construction phase of a hypothetical
software project.

Figure 12.5 Using the defect tracking log for root cause analysis

The analysis shows that three or four code earmarks were the primary contribu-
tors to the defect log during the Preliminary construction phase of development. It
would be very prudent for the testing team to urge a project team review of AP234,
AP745, and GL106 before proceeding with the Final construction phase. A review of
AR218 might pay dividends, but its defect contribution does not make as compelling
a case for review as the other three code earmarks. This becomes a judgment call
based on what else the testing team has learned about the AR module during testing.
All earmarks below AR218 on the report were an order of magnitude less frequently