1, then it seems highly probable
that the release was snatched away from testers at the moment they were finding the most bugs.
Note that only a third had been fixed. Were they the most critical? Find the number of 3rd-line
support calls (problems per user month) made against that release and compare them with those
made for a ???well-tested??? release whose bug detection curve looks like the one in Figure 1.2. (Notice,
though, that this release had far too many unfixed low-level bugs in it.)
4. The number of lines of code per bug in each release over the last two years, and show it on a
chart. Are things getting better or worse? (See Figure 18.19 for a nasty example.)
5. Number of bugs found in the field compared with those found during system testing (try to see
how easy is it for some user to raise a bug report, and how easy is it for you to read it). Go and
talk to real users. If there are very few bugs reported from the field it is probably because that??™s
difficult for users to do.
6. The number of click-outs or click-throughs on a web page. If you??™re testing a web application,
create some user action logs and look at them. At what point do people click out?
7. The number of 3rd-line support calls (measured as problems per user month in some companies)
and which bits of the system provoked the most. (Why wasn??™t the buggiest bit tested better? Review
the tests and find out.) The support desk is either:
??? Overwhelmed with calls
??? Already abandoned by customers because it doesn??™t work
??? Regularly hand-holding important users
FIGURE 1.
Pages:
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93