In the article about the lifecycle we covered which stages a product goes through: requirements, design, development, testing, release. But you can move through those stages in different ways: strictly one after another, with checks at every step, or in small repeating cycles. The way you move through them is called a development model, and for a tester this is not abstract theory: the model determines when you join the work, and what and how you check.
There is no ideal model. There is the one that fits a specific project, team, and circumstances better. Let's look at three approaches worth knowing: you'll meet them in real life, and everything else is built on them.
Waterfall: strictly one after another
The waterfall model — stages follow one another like water down a cascade: first all the requirements, then all the design, then all the development, and only then — testing. You can't go back up a level (more precisely, it's very expensive).
For a tester this is the worst option: testing appears explicitly only in the second half of the project and peaks at the very end — when changing anything is already costly. A mistake made in the requirements lives unnoticed until the finale. That very pain gave birth to all the models that followed.
It's too early to bury waterfall, though: for small tasks with stable, well-understood requirements it's still applied intuitively, and in industries where requirements are rigidly fixed up front (aviation, medical software), its refined variants are alive and official.
V-model: every stage gets its own check
The V-model is a logical evolution of waterfall, and it matters to testers in particular: the concept of test levels grew out of it.
Picture the letter V. Down the left branch, the project "descends" from general to specific: user requirements → system requirements → architecture → detailed design → code. Up the right branch, it "climbs" back through checks. The trick is that each stage on the left has its own level of verification on the right:
- user requirements ↔ acceptance testing ("did the user get what they asked for?");
- system requirements ↔ system testing ("does the system as a whole work as described?");
- architecture ↔ integration testing ("do the parts fit together?");
- detailed design ↔ unit testing ("does each piece work?").
The key idea: while descending the left branch, the team is already thinking about how it will verify that stage on the climb. Writing requirements — immediately planning acceptance checks. Designing the architecture — already thinking about integration ones. Testing enters at the earliest stages of the project — not as executing checks, but as planning them. Requirement mistakes get caught while they are still cheap.
Iterations and increments: building the product piece by piece
Almost all modern development is built on the iterative incremental idea. Two words — two sides of the same model:
- iterative — because the "requirements → design → code → testing" cycle repeats many times, in short passes;
- incremental — because each pass adds a piece of useful functionality (an increment) to the product, and the product grows from iteration to iteration.
The result of an iteration is usually a build — an assembled intermediate version of the product that can be installed and tested. Testing works from the very start and continuously: every iteration has something to test, and the feedback from checks goes into the next iteration's plan, not into an "after everything" report.
Agile is a development of this same idea with a minimum of bureaucracy: short sprints, working product over comprehensive documentation, responding to change over following a plan. What this looks like in a tester's day-to-day work is a separate article — QA in Agile and Scrum.
How the model changes a tester's work
Let's sum up the essentials:
| Model | When testing happens | What it means for you |
|---|---|---|
| Waterfall | At the end of the project | You receive the "finished" product and find problems when they're most expensive to fix |
| V-model | Planned from the first stage, executed on the "climb" | You read the requirements and already design checks for each level |
| Iterative / Agile | In every iteration, continuously | You work in the team's rhythm: small portions, fast feedback |
The table shows the common vector of the whole history of models: testing keeps moving left — from the final stage toward the very beginning. The earlier checks enter the game, the cheaper mistakes are; we already did that math in the article about the cost of a bug.
Where this applies
Understanding models isn't for an exam — it's so you can see the whole picture from day one: why on this project you join at the requirements stage, while on that one you get a build every two weeks. When you join a new project, it's worth figuring out first which model the team lives by — your entry points depend on it.
Where beginners stumble:
- They treat the model as dogma. Pure models are rare in real life: teams mix approaches to fit their circumstances. A model is a language for talking about the process, not a statute.
- They hear "we're Agile" and expect no rules. Flexibility is not chaos: sprints, definition of done, and the order of checks don't go away — they just repeat more often.
- They miss the V-model's main lesson. You should be thinking "how will I check this" while reading the requirements, not when the build arrives. That habit separates the tester who gets invited to task discussions from the one who is handed a finished product.
What to learn next. The test levels that grew out of the V-model are covered in the levels article; how testing's own inner cycle works — in the SDLC and STLC article; how checks are organized within an iteration — in the test plan article.