Assuming that the bugs not closed
are trivial, a release could be made shortly.
FIGURE 4.11 A bug detection curve of a project which is a long way from release
FIGURE 4.12 Release readiness shown in terms of a bug curve
600
500
400
300
200
100
0
Raised and closed bugs
Raised
Closed
300
150
250
200
100
50
0
Raised and closed bugs
Closed
Raised
Test Planning and Management 63
You may hear occasionally this argument: ???What matters is not the total number of bugs found but the
number of bugs remaining to be fixed.??? This is mostly daft because:
??? Until you find them you won??™t know what bugs need fixing.
??? Developers may inject bugs as they fix them.
There are two ways of showing these problems:
??? If Code turmoil is high it is probable that bugs are being introduced. See Chapter 18.
??? If previously bug-free units (and the tests which go with them) show new bugs it is probable that
they weren??™t there before. See Figure 8.25.
So you need to monitor the Fix backlog metric (see section 18.9.1). The total number of bugs matters
because by counting the total number of bugs found we can answer the following questions:
??? Have we found the total we expected to find?
??? Are we finding fewer and fewer bugs per day, consistently?
Only then will you know whether the total number of bugs needing to be fixed is realistic. Remember
also that if the developers whose work you test tend to create bugs as they fix them, then you could be
greatly underestimating the number of bugs needing fixing anyway.
Pages:
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197