These records are handled by different people and enable you to monitor your development progress in different ways. The sequence of creating and handling veri®cation and test records is as follows:

1.Veri®cation records are created in the notReady state when a defect or feature is accepted. This indicates that someone on the development team has begun implementing the changes warranted by the defect or feature, but the changes are not yet ready to be veri®ed. A work area is also created for the part changes.

2.When a driver is committed all part changes associated with the driver members are integrated into the release.

3.To create test records, the driver is completed. This action creates one test record for each environment on the release's environment list. The testers on your development team use the test records to accept or reject the results of their tests on the part changes.

4.After all test records have been accepted or abstained, the veri®cation records are moved to the ready state. This indicates that the part changes have been tested in the context of the build and each individual defect or feature is ready to be accepted or rejected by the person who opened it.

5.The defect or feature originator accepts or abstains the veri®cation record to close the defect or feature. The originator can also reject the veri®cation record to move the defect or feature back to working state.

50User's Guide

Page 70
Image 70
IBM SC34-4499-03 manual Users Guide