From Waterfall to V-Model
The waterfall model has several visual disadvantages in communicating the sequence of stages and activities needed for system development. These often lead to a naive implementation of the model where every stage has to be completed and signed off before the next can start. This rigidity affects the flexibility in iterating back to earlier stages of development with the consequence problem of poor quality. The V-Model attempts to prevent that by explicitly showing the connections between the development and testing stages, both in text and crucially in the diagram.
Testing Types Matched to Development Stages
Bent Waterfall Model
The first noticeable point of the V-Model is that the Test stage of the Waterfall model is bent upwards to make it a “V”. This stage is now separated out into the various types of testing which are described in the article on Types of Testing. So this first step visually points out that there is more than one type of testing to consider for system development and that like the other development steps they build on one another, and have different objectives.
The next important part of the “V” is to match each type of testing against the development stage it matches e.g. we have Component Design matched against Component Testing. Furthermore the arrow direction goes from the development to the testing stage showing the connection and the order of precedence.
These arrows have more meaning as they show the legend “Dev Tests” which stands for Develop Tests. This means that the testing stage does not start when the Construct Component stage has ended. Instead when each development stage starts then the testing for that stage also starts. This is implied visually by the arrow coming out of the side of the development boxes and not the bottom.
Objections to the V-Model
V-Model
An objection sometimes raised is that it is impossible to create test scripts until development has got well ahead, as testers do not know the detail of the design of the system. This is both valid, but also misunderstands the process of developing a test. The test script is the least important part of the testing documentation, although it amounts to the vast bulk of it. The article on the Testing Process outlines the activities involved in developing tests, and shows that the early activities are Analyse Requirements, Develop Scenarios, Review Documents, and most importantly Derive Acceptance Criteria. Only when these activities have been performed can Test Cases and Test Scripts be created. Developing tests early is all about deriving the Acceptance Criteria which is the list of features you want to test.
Key Advantage of V-Model
V-Model feedback loop
Developing Acceptance Criteria early is the key advantage of the V-Model. Various studies have shown that between 60 and 70 percent of all faults are in the system before the Component Construction and Test stages start. These are requirement, specification and design faults. These include the very important fault of missing functionality: missing because it has not been specified. Developing Acceptance Criteria early means we decide what we want to do to test the system and this shows areas that are missing. Therefore at an early stage we can feed back to the relevant stage to catch a fault before it is built in to the system.
The missing functionality faults are the hardest to find in any system. The key problem with requirements is trying to think what is needed. It is like any activity when you are faced with a blank sheet of paper - the possibilities are endless for what to write down, but where do you start. The requirements analysis, developing scenarios and reviewing documents techniques combined catch many of these hard to find faults, along with many of the others.
Importance of Early Testing
The importance is illustrated a by a variety of studies which show that catching a fault early in requirements and design stages is more cost effective than catching it after a system has been released. The ratios vary between 5:1 and 100:1 difference in cost but all studies say it costs a lot more resource to fix a system after release. These costs for fixing the system do not take into account the reputation risks to the organisation and work around costs associated with faults and missing functionality, so the true cost is much higher.
The V-Model visually illustrates some of the points for successful system development. Its emphasis on starting testing early during the requirements, specification and design stages allows quality to be built in to a system. The V-Model diagram does not illustrate all the points necessary for good code as iteration back though the stages is only implied by the start of testing. However it does provide a firm but simple diagram to help iteration to take place early and effectively, making it a good development model to consider.
Waterfall and V-Models
- Types of Testing in the V-Model - the various types of testing that are applied throughout a SDLC.
- Waterfall Model the seven stages of a waterfall model and how they match the four phases of a SDLC.