Similarly if bugs can be traced
to the use or non-use of some tool, such a relationship can provide management with new
insights.
5. What was done wrong? This can be partly answered by using the classification shown in Appendix
C. A fuller answer can be derived from the following questions:
a. Why was the bug made? Answers to this question are central to improving the software project
process. See section 15.7.1 as a means of analyzing the operations most likely to expose bugs.
Those bugs remaining in the system for more than one phase provoke the further question:
why wasn??™t the bug found earlier?
b. In which phase was the bug made?
c. How often should the bug have been caught by a test?
d. Which test(s) should have caught it?
e. Which review should have caught it?
f. Which bugs were related to it?
g. Which test group found it (if there is more than one)?
6. Which program constructs have to be changed most frequently? (See section 13.6 for more on
this).
7. What is the relationship between the bugs? (An analysis of the circumstances likely to cause the
bug. See section 15.7.1 for an example.)
8. What could have been done to prevent this bug? This is an antidote to the pious hand-wringing
that frequently succeeds a major problem.
108 Manage Software Testing
9. Which test approach (could have) found this bug? The answers to this question help us decide:
a. Which testing methods are most effective at finding what kind of bug
b.
Pages:
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275