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

Figure 12.6 Second root cause analysis of defect logs

Several conclusions can be drawn from the second root cause analysis. The
original top three code earmarks are no longer the major offenders. So the time and
effort that went into the review, programming revisions, and retesting defi nitely re-
duced the number of hidden defects. The new top three code earmarks represent only
4.7% of the total defects corrected indicating a more even distribution of earmarks
throughout the software observed as the software becomes stable. Therefore, there
will not be much benefi t expected from another 3-week effort to review, correct, and
retest these new code earmarks in preference to other development activities. The
fact that AP234 and GL106 are still on the list is neither alarming nor unexpected.
Programming that starts out troublesome usually continues to be troublesome at
some level for the duration of the development project.
Root cause analysis is normally less valuable during the middle-third of the
development than it is during the fi rst-third. There are two reasons for this reduced
analytical value. First, by midproject most of the code has been tested several dif-
ferent times, which will tend to reinforce the earlier identifi cation of particularly
defective code with few new surprises. Second, by midproject the developers have
little time or opportunity to fully review code design and structure that is well on its
way to being fi nished code.
During the last third of the development, code earmarks tend to be used to pri-
oritize the backlog of uncorrected defects rather than analyze the corrected defects.
Recall that the code earmark is expected to come from the developer who corrects
the code. By defi nition, the defect backlog has not been corrected; therefore, you do
not expect to fi nd code earmarks on the defect backlog entries. Consider doing a lit-
tle guesswork on the most severe backlog defects. Have a brief meeting in which the
developers are asked to guess which code earmark is most likely contributing each
backlogged severe defect. Use this code earmark guess to see if there are clusters
of high-priority backlogged defects based on code earmark. If clusters appear, then