e. The bug is confirmed but is being addressed in a bug-management plan which will become
operative at a later date.
f. The bug report is rejected for the following reasons:
i. The bug is already raised. (If bugs are raised by more than one test group then note this:
it will help you estimate the number of bugs in the system. See section 18.10.4 in Chapter
18 for more on this.)
ii. The bug report has been wrongly-raised ??” the system is working as specified (note that
on occasions the specification may be wrong and the rejected bug report can become the
basis of a specification change request).
4.
Assign bugs.
The bug is assigned to a developer to fix.
5.
Fix and unit-test bugs.
The developer makes the fix, unit-tests it, updates the headers in the
various code files which have been changed, and marks the bug as ready for inclusion in the next
???build.??? The configuration manager will then incorporate the changed code in the next ???build.???
The change may also require changes to user documents and these should be reviewed too.
6.
Retest bugs.
After finishing the smoke and confidence tests, the system test team retests the unittested
bug fixes, and marks them as either ???closed??? (if the bug no longer appears) or ???open???
otherwise. For bug-fix-only releases this will then be followed by a regression test.
7.
Manage bug database.
The bug management tool manager:
a. Identifies all the unit-tested bug fixes to be included in the next
build
b.
Pages:
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269