The V-Model: A Test Level for Every Phase
Chapter Fifteen
Syllabus topic Module 1, "Software Development Life Cycle (SDLC): phases and their relationship to testing"
Pages 82 to 85 of 622
In one line
The V-model is the waterfall bent into a V: the development phases run down the left side, the test levels run up the right side, and each test level checks the work product of the phase opposite it.
In the wording a student can write in an examination: the V-model is a sequential SDLC model in which each development phase is paired with a corresponding test level: user requirements with acceptance testing, the system specification with system testing, the architectural design with integration testing, and the detailed design with component (unit) testing. Unlike the waterfall model, it "integrates the test process throughout the development process, implementing the principle of early testing" (ISTQB, 2018 syllabus), because the tests for each level are designed while the matching development phase is under way.
Why bend the waterfall
The last chapter ended on Royce's warning: when testing is a single phase at the end, real problems are met too late. The V-model answers it without giving up the sequence. It keeps the phases of the waterfall, but it recognises that "testing" is not one activity: checking a component, checking that components work together, checking the whole system and checking that users can accept it are four different jobs, each with its own test basis. And each of them can be prepared as soon as its test basis exists.
The ISTQB Foundation syllabus of 2018 describes it in exactly those terms: "Unlike the Waterfall model, the V-model integrates the test process throughout the development process, implementing the principle of early testing. Further, the V-model includes test levels associated with each corresponding development phase, which further supports early testing". The current syllabus (2024) still lists it among the sequential models, with the waterfall.
The shape of the V
Figure 15.1 The V-model: each test level checks the work product of the development phase opposite it
Read the figure in three directions.
Down the left arm is development, as in the waterfall: user requirements, then the system specification, then the architectural design, then the detailed design, and coding at the point of the V.
Up the right arm is test execution, in the order the pieces exist: components are tested first, then their integration, then the whole system, then acceptance.
Across the V, the dashed arrows, is what makes the model useful. The test level on the right is designed from the work product on the left, and it is designed when that work product is written, not when the code arrives. The acceptance tests are written while the user requirements are being agreed; the system tests while the specification is written; and so on down.
The V-Model: A Test Level for Every Phase
Each phase and its test level
| Development phase (left) | Its work product, which is the test basis | Test level (right) | What that level checks |
|---|---|---|---|
| User requirements | Business needs, user requirements, acceptance criteria | Acceptance testing | That the system fulfils the users' business needs and is ready to deploy |
| System specification | System requirements: functional and non-functional | System testing | The behaviour and capabilities of the whole system, end to end |
| Architectural design | The architecture: components and their interfaces | Integration testing | The interfaces and interactions between components |
| Detailed design | The design of each component | Component (unit) testing | Each component in isolation |
The right-hand column comes from the current ISTQB syllabus's own descriptions of the levels: component testing "focuses on testing components in isolation"; component integration testing "focuses on testing the interfaces and interactions between components"; system testing "focuses on the overall behavior and capabilities of an entire system or product"; and acceptance testing "focuses on validation and on demonstrating readiness for deployment, which means that the system fulfills the user's business needs." The syllabus adds a fifth level, system integration testing, which tests "the interfaces of the system under test and other systems and external services"; in a V it sits beside system testing. Test levels have their own chapter (Chapter Thirty-Two).
The relationship between phases and testing
This is the part of the syllabus MU words as "phases and their relationship to testing", and the V states the relationship in four rules, all of which the current ISTQB syllabus lists as good practice whatever model is used:
- Every development activity has a matching test activity. "For every software development activity, there is a corresponding test activity, so that all development activities are subject to quality control."
- Each test level has its own objectives. Different levels "have specific and different test objectives, which allows for testing to be appropriately comprehensive while avoiding redundancy". Unit tests do not re-test what system tests cover, and system tests do not repeat unit tests.
- Test design starts in the matching phase. "Test analysis and design for a given test level begins during the corresponding development phase of the SDLC, so that testing can adhere to the principle of early testing".
- Testers review drafts early. "Testers are involved in reviewing work products as soon as drafts of these work products are available".
The third rule is the one that pays. Writing an acceptance test forces the question how will we know this requirement is met? while the requirement can still be changed at the cost of a sentence. A requirement nobody can write a test for is usually a requirement nobody can build to either.
Worked example: ExamReg release 2.0 on a V
| Left arm: when it is written | Tests designed at that moment | Right arm: when they run |
|---|---|---|
| Week 2, user requirements: a student who submits on or before the last date pays no late fee | Acceptance test: an exam cell clerk submits a form for a real student on the last date and checks the receipt | Week 15, acceptance testing by the exam cell |
| Week 3, system specification: the fee table, the 500-user load target, the three browsers | System tests: every row of the fee table through the web interface; a 500-user load test; each page on each browser | Week 13 and 14, system testing by the test team |
| Week 5, architectural design: the fee service is called by the form module and calls the gateway adapter | Integration tests: the form passes days late and backlog papers to the fee service; the fee service passes the amount in rupees, not paise, to the adapter | Week 12, integration testing |
| Week 6, detailed design: the late-fee function's signature and rules | Unit tests: the late-fee cases of Chapter Seven, on test cases | Weeks 8 to 11, as each function is coded |
The V-Model: A Test Level for Every Phase
Look at the integration row. The paise-for-rupees interface defect of Chapter Two, on errors, faults and failures, could be caught by an integration test designed in week 5, from the architecture document, before either module was coded. In a pure waterfall nobody would have written that test until week 13.
Strengths and weaknesses
| Strengths | Weaknesses |
|---|---|
| Testing is planned and designed from the start, so defects in requirements and designs are found early | Still sequential: working software appears late, and changes to requirements are expensive |
| Each test level has a clear test basis and objective, so nothing is tested twice and nothing is missed | Assumes requirements can be fixed early, which suits some projects and not others |
| Traceability from each requirement to its test is built in, which regulators and auditors value | Test execution is still late; the early work is design, not running code |
| Simple to explain and manage | Heavy documentation if applied rigidly |
The V-model is common in safety-critical and regulated industries, such as vehicles, medical devices and aviation, where every requirement must be shown to have been verified. There it often sits inside a larger iterative plan: a V for each increment.
The W-model, briefly
Some writers add a second V inside the first, drawn as a W: alongside each development phase on the left is a review of that phase's work product. The idea is already in rule 4 above: static testing of the requirements, the specification and the designs, as soon as drafts exist, before any dynamic test runs. The W is the V with static testing drawn in.
What it does not mean
The V-model is not the waterfall with testing at the end. Its test execution is at the end, but its test design is at the start, phase by phase.
The V-Model: A Test Level for Every Phase
The V does not mean each level is tested only once. Defects found at a level are fixed and retested, and regression testing follows every change.
Unit testing does not check the requirements. Each level checks the work product opposite it; only acceptance testing checks the users' needs directly.
The V-model is not obsolete. The current ISTQB syllabus still lists it, and regulated industries use it, often within iterative development.
Quick revision
- V-model: a sequential model pairing each development phase with a test level; test design starts in the matching phase, so it "integrates the test process throughout the development process" (ISTQB 2018).
- Pairs: user requirements with acceptance testing; system specification with system testing; architectural design with integration testing; detailed design with component (unit) testing; coding at the point.
- Left arm down, right arm up; the arrows across are tests designed early from each work product.
- Good practice for any model (ISTQB v4.0.1): a test activity for every development activity; distinct objectives per level; test design during the matching phase; early review of drafts.
- Strengths: early test design, clear levels, traceability. Weaknesses: still sequential, late working software, costly change.
- W-model: a review beside every development phase.
Test yourself
1. Explain the V-model with a diagram. Draw development phases down the left (user requirements, system specification, architectural design, detailed design), coding at the point, and test levels up the right (component, integration, system, acceptance testing), with each level opposite the phase whose work product is its test basis. Tests for each level are designed during the matching phase and executed on the way up.
2. Which test level is paired with the architectural design, and why? Integration testing, because the architecture defines the components and their interfaces, and integration testing checks exactly those interfaces and interactions.
3. How does the V-model improve on the waterfall model? It integrates testing throughout development: tests for each level are designed as soon as the matching work product exists, so defects in requirements and designs are found early instead of in a single late test phase.
4. State two strengths and two weaknesses of the V-model. Strengths: testing planned and designed from the start; clear objectives and traceability for each level. Weaknesses: still sequential, so working software comes late; assumes stable early requirements, so changes are costly.
5. What does "phases and their relationship to testing" mean in the V-model? That every development phase has a corresponding test level whose test basis is that phase's work product, and whose test design begins during that phase.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself, or the past papers, for the same subject.