Assume 4 builds: A, B, C, and D. If the total number of bugs found in each
build is proportional to the number of changes to that build (a large number of changes equates
to a large number of bugs, and a small number equates to a small number of bugs), then the
release is probably stable. If (measured over a number of builds) the relationship of changes to
bugs found is inversely proportional (that is, more bugs are found as the number of changes falls),
then you possibly have a problem.
2. Measuring the number of bugs found in each iteration of each test. Assuming you can run all the
tests to completion on each build,
how many bugs do the tests find on each build?
Is the number
growing, fluctuating, or reducing? If it is not reducing overall, then is the number of priority-1 bugs
reducing?
However, there are other possibilities. Table 2.3 shows 6 cases. The prerequisites are above the thick,
black line and the conclusions below it.
FIGURE 2.1
Which is the buggiest feature?
TABLE 2.3
Identifying whether testing or development is affecting quality
Case 1 2 3 4 5 6
Have the tests been revised or the test regime changed? Y N N N Y Y
Are the numbers of bugs found by unit tests increasing? N N Y Y N N
Is the defect rate/KLOC much greater than in the last release? Y Y Y N N Y
Is code turmoil high? N N N ??” ??” Y
Is there evidence of increased code complexity? N Y ??” ??” ??” ??”
Testers are getting better at system testing Y N Y
Developers are creating more bugs Y Y
Developers are reducing the number of bugs Y
Multi-language
support-
German 1%
Correction
1%
Sources of defects
Dynamic
constraints
1%
Alerts
26%
Major
transactions
26% Input parsing
9% Coding
7%
Searches
6%
Other 2%
Data feeds
2%
All 2%
MetaData
repository 1%
Coding
assistant 1%
26
Manage Software Testing
2.
Pages:
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130