This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Testing and the V Models
Figure 1.1 illustrates a common way of modeling system engineering: the traditional V Model of system engineering activities.1 On the left side of the V are the analysis activities that decompose the users’ problem into small, manageable pieces. Similarly, the right side of the V shows the synthesis activities that aggregate (and test) these pieces into the system that solves the users’ problem.
)
Figure 1.1 Traditional Single V model of system engineering activities
While useful, the traditional V model does not really represent system engineering from the tester’s viewpoint. The next three figures show three increasingly detailed V models that better capture the testing-specific aspects of system engineering.
Figure 1.2 illustrates a V model oriented around work products rather than activities. Specifically, these are the major executable work products because testing involves the execution of work products. In this case, the left side of the V illustrates the analysis of ever more detailed executable models, whereas the right side of the V illustrates the corresponding incremental and iterative synthesis of the actual system. This V model shows the executable things that are tested rather than the general system engineering activities that generate them.
)
Figure 1.2 The Single V model of testable work products
Figure 1.3 illustrates the Double-V model, which adds the corresponding tests to the Single V Model [Feiler 2012]. The key ideas to take away from this model are:
- Every executable work product should be tested. Testing need not, and in fact should not, be restricted to the implemented system and its parts. It is also important to test any executable requirements, architecture, and design. In this way, associated defects are found and fixed before they can migrate to the actual system and its parts. This typically involves testing executable requirements, architecture, or design models of the system under test (SUT) that are implemented in modeling languages (typically state-based and sufficiently formal) such as SpecTRM-RL, Architecture Analysis and Design Language (AADL), and Program Design Language (PDL); simulations of the SUT; or executable prototypes of the SUT.
- Tests should be created and performed as the corresponding work products are created. The short arrows with two arrowheads are used to show that (1) the executable work products can be developed first and used to drive the creation of the tests or (2) Test Driven Development (TDD) can be used, in which case the tests are developed before the work product they test.
- The top row of the model uses testing to validate that the system meets the needs of its stakeholders (that is, that the correct system is built). Conversely, the bottom four rows of the model use testing to verify that the system is built correctly (that is, architecture conforms to requirements, design conforms to architecture, implementation conforms to design, and so on).
Finally, in practice, the two sides of the bottom row typically are combined so that the unit design models are incorporated into the units and so that the programming language is used as a program design language (PDL). Similarly, the unit design model tests are incorporated into the unit tests so that the same unit tests verify both the unit design and its implementation.
Figure 1.3 The Double V model of testable work products and corresponding tests
Figure 1.4 documents the Triple-V model, in which additional verification activities have been added to verify that the testing activities were performed properly. This provides evidence that testing is sufficiently complete and that it will not produce numerous false-positive and false-negative results.
Figure 1.4 The Triple V model of work products, tests, and test verification
Although the V models appear to show a sequential waterfall development cycle, they also can be used to illustrate an evolutionary (that is, incremental, iterative, and concurrent) development cycle that incorporates many small, potentially overlapping V models. However, when applying a V model to the agile development of a large, complex system, there are some potential complications that require more than a simple collection of small V models, such as:
- The architecturally significant requirements and the associated architecture need to be firmed up as rapidly as is practical because all subsequent increments depend on the architecture, which is difficult and expensive to modify once the initial increment(s) have been based on it.
Multiple, cross-functional agile teams will be working on different components and subsystems simultaneously, so their increments must be coordinated across teams to produce consistent, testable components and subsystems that can be integrated and released.
Finally, it is interesting to note that these V models are applicable not just to the system under development but also to the development of the system’s test environments or test beds and its test laboratories or facilities.
)
)