In those cases testers should be encouraged to submit full crash details plus screenshots not only to the
bug-management tool but also to the test manager. Since it is unwise to submit undemonstrable bugs
to developers it is essential they be recorded somewhere. This spreadsheet is a good place. After a while
patterns can emerge.
8.6.6 Weekly/Daily Bug Report Count
FIGURE 8.17 Test events log tab
FIGURE 8.18 Crash log tab
FIGURE 8.19 Weekly bug report count tab
Test Documents 145
Either using an ODBC link to your bug-management tool or a daily dump of raw bug reports into your
spreadsheet you can get the weekly running totals of found and cleared bug (SCR reports).
Closing SCRs becomes a major pressure point on testing. Developers need to know their fixes were
valid. Closing each bug takes time which testers prefer to spend testing. Bugs are best closed by the tester
who found them. But if the bug is evident, a good manager might simply do it himself.
8.6.7 Charts
The charts tab draws on a number of pieces of data obtained from the bug-management tool and the
test management tool.
1. Test execution status (Figure 8.20) is best measured by test execution steps. Why? Because if some
tests have only 3 steps and some have 15 it will be very difficult for you to know just how far through
test execution you really are. This chart shows that much testing remains to be done, but that very
few tests are failing. One confidence test failed1 and one could not be run for environmental reasons.
Pages:
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326