Information Technology Reference
In-Depth Information
suggest that the developers concentrate on the fi rst few in the cluster as their correc-
tion priority. Because the developers will be working on the most severe defects, no
valuable (and scarce at this time in the development) correction time is squandered.
After the fi rst couple of most severe defects have been corrected, compare the actual
code earmarks with the guesses. If the guesses are correct, continue to pursue the
remaining code earmarks in that most severe defect cluster. If the guesses are incor-
rect, attack the fi rst few defects in the next cluster. The risk is spending a little extra
time up front with the developers when they are under the most pressure to complete
the software. The benefi t is giving them some analytical road signs that could make
the remaining correction time and effort they have left most wisely spent from a
quality perspective.
Figure 12.7 demonstrates what such a defect backlog root cause analysis might
show for a backlog of 500 defects during Final construction.
Figure 12.7
Defect backlog root cause analysis
In this example, the development team is already concentrating on correction
code around earmark AR477 because it has exhibited a Severity 1 defect. The
development team might be surprised that so many of the Severity 2 defects are
possibly colocated with the Severity 1 defect around earmark AR477 that they
are already attempting to correct. Another possible conclusion of this analysis is
for the test team to lend support to the development team that has been arguing
with project management about the correction diffi culties in this area of code due
to vague or confl icting design specifi cations. One more possible conclusion of this
analysis is what our Canadian friends would call “the dead moose on the table”: The
development team has been in denial that the AR477 earmark code area has major
problems that present a real risk to the customer.
Search WWH ::
Custom Search