Check in the
configuration management database. There??™s always a bit of overtime worked around the time of
a major release. How big is that bit?)
12. The number of abandoned test runs. There are two good reasons and one bad one for abandoning
test runs:
??? The number of bugs is so high that the testers spend more time filling in bug reports than in testing.
??? Important parts of the system simply do not work.
??? The developers arbitrarily change the test environment (thus halting the use of the present
release) or impose a new release by simply installing it over the existing one.
The first two are unfortunate; the last is unforgivable and indicates that the development function
is out of control. If the last happens, then it can mean that some part of the system never gets
tested until too late and that developers don??™t hear of bugs in time because test coverage is poor.
You can get this data from the test management tool or direct from the testers.
13. The risk the project runs. Is there a risk log? Review it.
14. The number of bugs is being introduced with each fix. This will really make people scream. The
truth is, all fixes induce some bugs. Hopefully the ratio is less than 1:1 fixes to new bugs. See
section 2.7.2 for more on this.
15. How many extraordinary delays occurred before the first release, because key parts of the product
had neither been prototyped nor modeled and were found not to work far too late for corrective
measures to be taken?
Structure your report like this:
1.
Pages:
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95