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

occurring. Additional code review for the less frequently occurring code earmarks
may not add much value.
There are three reasons for the recommendation to review the program code and
design behind the top three code earmarks. The fi rst and most obvious reason is the
dominant discovery of defects in these code earmarks over all other code earmarks.
The second, less obvious reason is that these three code earmarks account for 45.5%
of all defects discovered during the Preliminary construction phase. The third and
fi nal reason is that two of the three top offenders come from the same major program
module, the AP module. So a consolidated review of AP234 and AP745 could pay
extra dividends.
These clusters occur due to a variety of development process infl uences such
as incomplete or inaccurate design, inadequate code design, inadequate code writ-
ing, and inadequate debugging. More subtle infl uences are the coding standards that
might actually encourage bad coding habits, or programmers with inadequate pro-
gramming language skills for the complexity of the application.
Regardless of what might be causing the code earmark clustering in the defect
log, the motivation for the reviews is to determine if there are, in fact, many more
possible defects in the same earmark area that could be prevented or minimized
by a design review, a specifi cation review, or even a code walkthrough. Here is the
payoff for the developer who takes the time to identify code earmarks for the defect
log. The tester is able to say, “revisit this code one time thoroughly and you will
probably reduce the number of times you must revisit the same code for additional
corrections.”
For the sake of demonstration, assume that the project team agrees with the
testing team's root cause analysis. The team takes a couple of days to walk through
the AP module and the GL module with AP234, AP745, and GL106 as their guide to
potential trouble areas in the code. Sure enough, a major design fl aw was discovered
in the AP module. Additionally, subroutines in the GL module were found to violate
programming standards regarding branching logic that left several dead end logic
paths.
As a result of the review, the start of the Final construction phase was postponed
3 weeks to allow the developers to implement the review recommendations and the
testers to rerun all their test cases for the AP and GL modules (regression testing).
As with all coding revisions, the regression testing discovered 50 more defects that
were added to the defect tracking log. Because none of the additional 50 defects
were showstoppers, they were considered part of the defect backlog that could be
corrected during the early part of the Final construction phase.
Halfway through the Final construction phase, the test team did another root
cause analysis. This time the analysis focused on defects discovered and corrected
thus far just in that phase. The test team was interested in seeing what effect the post-
Preliminary construction code correction cycle had on the defects of the next phase.
Recall that there is a human tendency to introduce new software defects during code
correction. The team was also interested in seeing if other coding earmarks now
arose as possible areas of review. Figure 12.6 shows the second root cause analysis
report.