16.4 Test

Deliveries

A good many items produced during test are deliveries, in the sense that they're documents, which may be composed of test cases. It may be useful for later retesting and regression tests to define deliveries composed of the test object and the associated test configuration items, especially the test environment. As an example, a module might be assembled with associated test cases, driver, stubs, and test data into a module test deliveryone configuration item. Likewise, a test delivery will often be defined as the entire system, including the system test specification, associated test data, test hardware, and so on.

Drivers and Stubs

Drivers and stubs are source code that simulate how a test object is activated and other modules it uses. Real modules (actual modules to be delivered, rather than specially made drivers or stubs that are not delivered) may be used as drivers or stubs and should be under configuration management. If drivers and stubs are developed, they should be placed under configuration management like all other types of source code. Their unique identification should be defined so that it's apparent to which test item a driver or stub belongs.

Tracing

Tracing for test specifications may be and should be performed to any relevant preceding documentation and at as detailed a level as possible. This aspect should be taken into consideration when planning the granularity of the objects placed under configuration management. Figure 16-2 shows tracing for test- related configuration items performed according to the classic waterfall development model.

Figure 16-2. Test-Related Tracings

Storage

Storage should be performed in the same manner and in the same place (in the same structure) as for corresponding configuration items from other development activitiesdocuments, source code, and hardware. It may be necessary and useful to "store" (build and maintain) completely independent test environments (hardware, directory structure, and so on) to ensure having them later, when they are needed. It may be worth the effort and cost to build and maintain a system test or acceptance test environment as a complete copy (perhaps with reduced size for data) of the real production environment. It's a configuration management activity to describe and maintain such environments.

Change Control

Change control should preferably be in place for modules, integration system, subsystems, complete systems, and related documents before test activities start. Change control must also be in place for test-related items, since events may also occur for test specifications, for example.