Information Technology Reference
In-Depth Information
The challenge for the backlog analysis team is that the backlog is a weekly
moving target as defects are corrected and new defects are discovered. It is not un-
common for new defects discovered late in the development cycle to be immediately
promoted to the top of the backlog as “must fi x” backlog list.
At this juncture, fi ery debates will arise over the quality of the software because
“software quality” has no industry standard defi nition or measurements. For the
purposes of this textbook, software quality goals and measurements for the software
under test are included in the software requirements. The intended implication is that
if the developer writes software that unequivocally meets all the development re-
quirements and the tester successfully validates the software against all of the devel-
opment requirements, then the software is considered to be of good quality. It is rela-
tively easy to fi nd publications that document how pervasive poor-quality software
(using the above defi nition) is in the marketplace. [11] Those software products that
do achieve this verifi ed consistency with their development requirements are then
challenged to defi ne whether the requirements themselves are of good quality—a
whole different quality issue beyond the scope of this textbook.
12.5 DEFECT DISCOVERY FOCUSING ON
CLUSTERS OF DEFECTS
The metrics used to track the incremental discovery and correction of software de-
fects can be leveraged for valuable test analysis beyond one-by-one defect review and
backlog analysis. Consider the cost/benefi t trade-off from adding one more column
of information to the defect-tracking record: the identifi cation of the code that con-
tained the defect. We will call this the “code earmark.”
The cost of adding this code earmark is not high, but it is usually not free either.
First, the development team must agree on a standard way to identify the code in
which defect corrections are applied. Programming specifi cations usually contain
unique identifi ers for the modules, subroutines, and classes that can also serve as
code earmarks for defect tracking. Second, the development team must agree to take
the extra time and effort to report back to the defect tracking log the code earmark
Figure 12.4
Defect tracking log with code earmarks
Search WWH ::
Custom Search