Review all the 3rd-line support calls and fixes against the tests which should have found them.
b. Identify any trends such as a particularly-buggy or particularly undocumented feature or
insufficient time spent performance testing or bugs occurring at a particular time or in a
particular configuration.
c. Review the test process model, test plan, and test specifications to identify what changes should
have been made to detect the bug. Write a report if only as an
aide-memoire
for the next time.
d. Have the test suite changed and rerun the tests to exhibit the bug(s) in the old release. Run
the tests against the new fix.
See also section 9.7.7.
Consider creating a model office environment with copies of both old and new systems completely
separate from the operational systems but including copies of all other network-coexisting systems. Once
the model office environment has been created and the tests have been run once, switch off the networkcoexisting
systems not known to be codependent, and re-run the tests. This should allow you to identify
if network-coexisting systems are really independent of the existing system:
??? The system is installed either in your own or customer organizations.
??? A low-traffic time is identified and the cutover made.
??? The old system is retained for as long as is considered safe and then decommissioned, and the
software archived.
??? Bug reports are received from Support.
Pages:
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249