It is useful to distinguish between bugs, and failure. A failure is only the expression of the existence
of one or more bugs. A failure is what we see: for example when a radio starts to smoke. The bug which
causes the smoke lay in plugging the aerial into the power point.
Bugs can be analyzed using the following headings:
1. What kind of bug? Use [Beizer 3] or Appendix C to classify the bugs.
2. Where was the bug made? In a specification? In a manual? In the code? The answer to this question
helps answer several others:
a. Which units have the greatest number of bugs?
b. Is there any correspondence between the most bug-laden units, and any other unit characteristics
such as complexity (see section 18.8.4), size, or number-of-changes?
c. Which units/interfaces/features should be most heavily tested?
d. Is any (part of any) specification particularly bug-related?
e. Which variables have provoked the bug to throw a failure?
3. When was the bug made? In which phase of the project was the bug committed? (See Table 7.1
for an illustration.) This can show:
a. How many bugs have persisted through two or more phases,
b. Which reviews or tests failed to find the bug.
4. Who made the bug (and using what tools)? Which groups, individuals, and environments were
involved? Note that a degree of collective responsibility is required: it is pointless blaming some
programmer for a bug in some unit if that unit has been reviewed.
Pages:
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274