(When the system is in use) Which kinds of bugs we failed to find and which kinds of extra
tests are needed
By setting up a system to answer such questions well before testing begins, management has the information
required:
??? To make tactical decisions during the testing and support phases
??? To make strategic decisions during the planning phase of the next project
??? To justify such choices to senior and customer management
7.6.4 Bug Source Table Example
From the bug details to the bug management database you can create a pivot table in Excel as shown in
Table 7.1. This partial table shows that 45% of critical bugs are being introduced by design and 50% are
being introduced by coding.
Trap the data as it is created, typically at bug triage sessions where those most-knowledgeable are together.
7.6.5 Bug Detection Effectiveness
A more-detailed analysis shown in Table 7.2 demonstrates that although the requirements review was fairly
effective (thirty-nine bugs found out of sixty-four), the architecture design review (43/(64 + 106 ??“ 39)) was
not. On deployment sixty-six bugs were found out of a total of 374 so the bug elimination level (or overall
bug removal effectiveness) so far is 82%. Note that:
??? You will be unable to complete this table until the release to which it refers is removed from
service. Only then can any deployment (field) bugs be totaled.
??? The table assumes that at each stage the bugs discovered at a previous stage have been removed.
Pages:
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276