Waterfall and the V-Model

Why it matters

Many projects still run this way, especially when a contract fixes the scope, when a regulator or customer expects documented evidence for every phase, or when software is part of a hardware or infrastructure project. On such a project you need to know which documents are your test basis, when to review them, which test levels you own and what the entry and exit criteria of your phase are.

The models also explain risks every tester meets. In a strict waterfall, dynamic testing comes last, so a requirement misunderstood in month one may surface as a failure months later, when the fix touches documents, design and code. And when development runs late but the release date stays, the test phase shrinks. Knowing this lets you ask for counter-measures at the start.

Waterfall phases and where testing sits

Phase names vary between organisations, but a typical waterfall project looks like the list below. Each phase produces a work product, usually a document, that is reviewed, approved and then used as the fixed input of the next phase; later changes go through formal change control.

Testing has two places here. Dynamic testing runs the software, so it waits for the test phase near the end. Static testing examines work products without running them, so it can start in the first phase: CTFL v4.0 notes that in sequential models testers typically take part in requirement reviews, test analysis and test design early on.

• Requirements: the specification is written and signed off; the tester reviews it for ambiguity, gaps and testability and starts the test plan.
• Design: architecture and detailed design are produced; the tester reviews them and identifies test conditions and environment needs.
• Implementation: developers code and test their components; the tester designs test cases and prepares test data and the environment.
• Testing: the test team executes the tests on the integrated system, reports defects and runs confirmation and regression tests on the fixes.
• Deployment and maintenance: the release goes live, often after formal acceptance by the customer, and every later change needs its own testing.

The V-model: each development level has a test level

CTFL v4.0 lists both waterfall and the V-model as sequential development models. What the V-model adds is a one-to-one pairing: each specification on the way down has a test level on the way up that checks the built software against it.

Two timings matter. Test analysis and design for a level begin during the matching development phase, while its specification is being written, and testers review each draft as soon as it exists; CTFL v4.0 lists both as good practices in any lifecycle. Execution runs the other way, bottom-up after coding: component tests first, acceptance tests last. Early test design is the model’s main gift to QA, because turning a specification into concrete tests quickly exposes its vague or contradictory sentences.

In the terms of the lesson on verification and validation, testing the build against each specification is verification, and acceptance testing against real user needs is validation. CTFL v4.0 also splits integration into component integration and system integration testing, which the lesson on test levels covers.

• Business and user requirements ↔ acceptance testing: can the intended users do their work with the system?
• System requirements specification ↔ system testing: does the whole system behave as specified, including non-functional requirements such as performance?
• Architectural design ↔ integration testing: do components, services and external systems work together through their interfaces?
• Detailed design ↔ component testing (often called unit testing): does each component do what its design says, in isolation?

Worked example: an outpatient booking system

A group of clinics contracts a supplier to build an outpatient booking system at a fixed price, with a signed-off document for every phase. The project follows the V-model, and the tester joins in the requirements phase, not after coding.

As each document is approved, the tester derives tests for the paired level and records the links, so every requirement has a test and every test traces back to a requirement. Two of the four items below exposed a gap before any code existed.

• BR-2 "Patients can book online and receive a reminder" → acceptance test AT-2: pilot patients book real slots on their phones, and receptionists see the bookings in their daily list. Writing it raised an open question: when a patient books for a family member, whose phone receives the reminder?
• SR-14 "A slot can be booked by only one patient" → system test ST-14: two sessions book the same slot at the same moment; one succeeds and the other sees "Slot no longer available".
• AD-3 "Reminders go through an external SMS gateway" → integration test IT-3: with the gateway down, the booking must still be saved. The design did not say what happens to the reminder, so the tester raised a design defect before coding.
• DD-9 "canCancel() returns true only while the start is more than 24 hours away" → component tests CT-9, written by the developer: 24 hours 1 minute, exactly 24 hours and 23 hours 59 minutes before the start, expecting true, false and false.

Traceability: outpatient booking system (V-model)

Left arm (approved first)          Right arm (executed later)   Tests
BR-2   business requirement   <->  acceptance testing           AT-2
SR-14  system requirement     <->  system testing               ST-14.1  ST-14.2
AD-3   architectural design   <->  integration testing          IT-3.1   IT-3.2
DD-9   detailed design        <->  component testing            CT-9.1 .. CT-9.3

Designed:  AT -> ST -> IT -> CT   (as each document is approved)
Executed:  CT -> IT -> ST -> AT   (after coding, bottom-up)

Try it: Requirements → Test Cases Try it: Requirements → Test Scenarios

Strengths and risks for QA

Neither model is good or bad in itself: each fits some contexts and brings predictable risks for testing.

• Strength: a stable, approved test basis. Tests trace cleanly to requirements, and coverage is easy to show to a customer or an auditor.
• Strength: clear gates. Entry and exit criteria, a formal test plan and a test completion report fit the phases naturally; CTFL v4.0 notes that in sequential models the exit criteria of one test level are often part of the entry criteria of the next.
• Strength of the V-model: early test design finds ambiguities and gaps in each specification before it is built.
• Risk: late feedback. Defects missed by the reviews surface late, when a fix touches documents, design and code. Counter: thorough reviews and early test design.
• Risk: a squeezed test phase. If coding overruns and the date is fixed, testing time shrinks. Counter: agreed entry criteria for the test phase and tests prioritised by risk.
• Risk: late validation and big-bang integration. Users may first see the software at acceptance testing, and integrating everything at once hides where failures come from. Counter: prototypes, user walkthroughs and incremental integration.

Try it: Risk-Based Test Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.