To simplify matters some organizations identify each of these changes as a Request For
Change, review it with all the stakeholders, and agree it with the customer and senior or contract management.
Note that the review must ensure that the requirements specification itself be not compromised. These
RFCs are then added to the specifications as the baselines against which all stakeholders must work.
This tab enables a test manager to check the status of all RFCs.
8.6.3 Test Status
This shows the critical information for each build concerning the feature, the tester in charge, the
number of test objectives, and tests prepared, and the percentage run, passed, and failed for each build.
By using Conditional formatting on the tests failed column those exceeding some limit can be highlighted
in red. In this case not only was the feature buggy, but management had decided in mid-release to
change the specification.
8.6.4 Test Events Log
As testing proceeds and tensions rise, it is invaluable to have a log of events such as test environment
down, build available at 10 am such that causes of delays, etc. can be simply determined. This log is quite
distinct from the Crash log.
FIGURE 8.15 RFC list tab
FIGURE 8.16 Test status tab
144 Manage Software Testing
8.6.5 Crash Log
Particularly at the start of testing a number of critical events may occur:
??? The system may crash, possibly explicably.
??? Unrepeatable bugs may be seen.
Pages:
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325