This may be one of
three kinds:
??? Investigate the bug
??? Resolve the bug
??? Do nothing ??” either because the bug is already known or because its priority is too low
TABLE 8.4 A bug report
Bug report
project name bug report no.
controlled item/feature version/variant
workpackage name of observer
bug name related bug report numbers
test identifier category priority
bug details
summary
description
related activities
effect
signature function date
results of investigation
effect
root cause
severity priority justification
signature function date
action
signature function date
156 Manage Software Testing
In any case the project manager should ensure that category and (fix) priority are completed as defined
in Appendix C.
In the first case complete the following fields:
??? results of investigation: a definition of the cause of the bug
??? effect: a definition of all the changes required to resolve the problem; this may consist of a simple
reference to a change plan which itself refers to all the documents, code, and tests requiring changes
??? severity of the bug (see section Appendix C)
??? priority: there may be lots of high-severity bugs needing fixing; this lets the project manager
decide the order
??? justification if not obvious from the bug description
??? signature of the person investigating the cause of the problem
??? function of the investigator ??” the group within which the investigator works or the responsibility
held at the time of the investigation
??? date the investigation was made
??? related bug numbers: if the bug has already been reported or if it is believed that the bug is related
to others, then add the numbers of the relevant observation reports
In all cases complete the following fields:
??? action decided by the project manager; this will be either to do nothing, raise a change request
or authorize that the bug be fixed
??? root cause (see section 2.
Pages:
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341