Tying Testing and Development Together
The previous few sections have described waterfall models for the software development process and for the test process. The two models have common starting and ending points, but the test and development teams are involved in separate and different activities all along the way. This section presents two models that tie the two sets of activities together.
One way of seeing how test and development activities are related is shown with the V diagram, which is illustrated in Figure 1.4. In this model, also called the hinged waterfall, the analysis and design activities form the left side of the V. Coding is the lowest point of the V, and the testing activities form the right side. Maintenance activities are omitted for simplicity.
Figure 1.4 The V diagram or hinged waterfall.
The double-headed, dashed arrows in the figure highlight the relationships between the test activities on the right side of the diagram and the requirements and design activities on the left. The top dashed arrow shows that the purpose of acceptance testing is to validate requirements, and that the acceptance tests are based upon the requirements. Similarly, system testing serves to verify the system design, and the system tests are derived from the system design. One purpose of the V diagram, therefore, is to show the purpose of the test activities in terms of verification or validation of earlier development activities.
Although the V diagram helps illustrate the relationship between development and testing, it does not show the two parallel threads of activities that the two teams perform during the course of development. One way to show the separate activities that are associated with development and testing is illustrated by the parallel waterfall model in Figure 1.5. This figure is a little more complex than the previous models, but it has several key features that make the extra complexity worthwhile.
The parallel development and test threads are clearly shown.
The arrow connecting system test to system design shows that the purpose of the system test phase is to verify the system design.
The arrow connecting acceptance test to requirements shows that the purpose of the acceptance test is to validate the requirements.
Similar arrows show that the purpose of the unit and integration test is to verify the program design and the purpose of test debugging is to verify the test design.
Each remaining phase of the development and test threads have "feedback loops" whose purpose is to verify that the work products of system design, program design, test planning, and so on meet the requirements placed upon them at the beginning of the phase. This check is done using static testing.
Figure 1.5 Parallel waterfall model.
A little reflection on Figure 1.5 shows why software testing is such a demanding and difficult job. Even while working in the traditional waterfall environment, the test team must perform a range of activities, each of which is dependent on output from the development team. Good communication must be maintained between the development and test threads of the process, and each team needs to participate in some of the other team's verification activities. For example, the test team should participate in verifying the system design, and the development team should participate in verifying the test plan.