Identify and record bugs.
Testers analyze the results, identify bugs, and submit a
bug report
(see
Chapter 8 for an example). Note that everyone in a project should be free to submit bug reports.
This has several advantages:
a. All whinges can be dealt with in the project manager??™s time.
b. Verbal whinges can be quickly repressed:
write it up in a bug report!
c. Everyone knows how to get a whinge answered.
d. The project manager can direct all bugs to a deputy.
e. Field or customer-discovered bugs are included along with developer- and tester-discovered
bugs. It is more likely in this way that patterns of bugs will emerge.
3.
Review and triage bugs.
Bug reports are reviewed by the test manager, the project manager, the
design authority, the configuration manager, a user representative, and possibly senior developers.
There are various outcomes:
a. The bug is confirmed.
b. The bug severity is changed because it has been mis-classified. See Appendix C.
c. The bug is assigned a priority. This simply determines the speed with which it will be fixed
and is usually related to the degree to which the bug delays testing. It is not necessarily related
to bug severity.
d. The bug is confirmed but cannot be resolved by the developers ??” it may be in the compiler
or in some COT software which will not be changed in time. The user representative and
management agree that the bug exists and must remain unfixed.
Pages:
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268