Picture two first days on two projects. On one you are handed an eighty-page document describing an entire future online store: "Read it, you'll start testing in March." On the other, day two brings a build with one new "Pay by card" button: check it by Friday.
The job has the same name and looks nothing alike, because teams walk the same development stages — requirements, design, code, checks, release — in different orders and portion sizes. That is what people call a development model; there is no perfect one, only the one that fits the project and the contract. We'll look at three through one requirement: "a customer pays for an order by card; press the button twice and the money must not be taken twice."
A model does not change how many mistakes a team makes. It changes how long a mistake goes unnoticed — and that is what sets the price.
Waterfall: describe everything first, build everything after
The customer wants the price and the deadline before a single line of code exists, which means agreeing up front on what is being built and writing it down. Everything then runs in sequence: all the design, then all the code, then the checks, because there is nothing to check before. The stages fall one into the next like water down a cascade: hence waterfall.
The requirement was written in January, and you see no product until March: you read the document, learn the domain, and write test cases against paper. The build arrives in March — and only then does it turn out that "the money must not be taken twice" meant three different things: the analyst pictured a button that locks, the developer assumed the bank would reject the second payment, and in reality two requests leave a second apart and both go through. In January that question would have cost a fifteen-minute conversation; in March it costs a requirement rewrite, a code change, rewritten test cases and a re-check of everything near payment.
Changing your mind mid-project is expensive too: the change goes through formal approval — requirement, design, code, test cases, schedule, budget — deliberately slow, because the scope was fixed in advance. It is too early to bury waterfall: in aviation, medical devices and banking a regulator or a contract demands a document showing, next to every requirement, the check that proved it. That link is called traceability, and the next model grew out of it.
The V-model: every stage gets its own check
Reading the requirement "a customer can pay for an order by card", ask one question straight away: how would I check this? No clear answer means the requirement is badly written, and that shows long before any code. The V-model makes the question mandatory at every stage.
Down the left branch of the letter V the project descends from general to specific: user requirements → system → architecture → detailed design → code. Up the right branch it climbs back through checks, and every stage on the left has a check on the right designed at the same moment, not six months later.
The top pair: the requirement "a customer pays by card and receives a confirmation" is matched by an acceptance check — a person walks the path from cart to email. While you phrase it in January, the questions come out by themselves: what if the card is declined? what if the button is pressed twice? how long do we wait for the bank? Three holes in the requirement, before the first line of code. Below, the scale is smaller: system requirements ↔ system check, architecture ↔ integration, detailed design ↔ unit — those four pairs are where the test levels come from.
Your project almost certainly doesn't run on a V, but "how would I check this?" works in any model — how to ask it systematically is covered in testing against requirements.
Iterations and increments: the product piece by piece
Both previous models rest on the assumption that the requirements are known up front and won't change — real life rarely obliges: the customer sees the first working version and reinvents half of it. So products are more often built in passes of two or three weeks, each going through the whole cycle from requirement to a working piece.
Incremental means the passes add pieces: in the first the store learns to take card payments, in the second refunds appear, in the third subscriptions; such a usable piece is an increment. Iterative is about something else: half the shoppers don't understand the confirmation screen and abandon the order, so in the next pass the team adds nothing and reworks that same screen for the third time. An iteration isn't obliged to deliver new functionality: sometimes its result is "the same thing, only now people understand it".
A pass ends in a build: a version of the product at a particular moment, stamped with a number such as 1.4.17. The number is not decoration: "reproduces on 1.4.17 and no longer on 1.4.18" tells the developer which changes to search. That is why the build number is a mandatory field in a bug report.
Agile is the same iterative idea: instead of volumes of documentation a requirement is discussed by three people (analyst, developer, tester), and the tester sits inside the team rather than in a department that receives finished work; what that looks like from inside a sprint is covered in a separate article.
The regression that keeps growing
In the first pass you checked one card payment and finished in a week. By the fourth there is again one new feature — subscriptions — but their code touches the same payment module, so you must also make sure yesterday's payments and refunds still work, while the pass is still two weeks long.
Checking that what used to work still works is called regression: its volume grows with every increment while the length of an iteration never does — the product gets bigger, the calendar doesn't. Hence two answers: the checks are split into sets — a fast fifteen-minute smoke set answers "is this build alive enough to test?", the full regression set is run before a release (a separate article) — and repetitive checks get automated. In most teams the conversation about automated tests starts with growing regression, not with a love of code.
How the model changes your work
The differences you actually feel come down to three things.
| Model | When you join | What you get as input | Where a found bug goes |
|---|---|---|---|
| Waterfall | In the second half, once the first version is assembled | A requirements document, no product yet | Into a general defect list, fixed with an eye on the deadline |
| V-model | From the first stage, at first as planning of checks | A requirement and the question of what will verify it | Many findings are requirement fixes before any code; the rest as in waterfall |
| Iterations and Agile | In every pass, continuously | A numbered build and a task for two or three weeks | Onto the pass's board, usually fixed before it ends |
Testing keeps moving left, toward the start of the project: what moves is not the execution of test cases — running a check still needs finished code — but the requirement discussion and the design of checks.
The name says less than the rhythm: a release once a year or so is waterfall, whatever it is called; every two weeks means iterations; once a quarter means a hybrid. The hybrid is the most common reality: two-week sprints, but a release once a quarter with two weeks of solid regression before it. Not "Agile done wrong" but a trade-off: shipping has its own cost — regulations, training the operators, sign-off with the customer.
In short
- A model doesn't change how many mistakes a team makes — it changes how long a mistake lives unnoticed. In practice the difference is three things: when you are brought in, what you get as input, and where a found bug goes.
- Waterfall assumes the requirements are known in advance; a mid-project change drags the whole chain of documents along and goes through formal approval.
- The V-model's lesson carries into any model: ask "how would I check this?" while reading the requirement, not when the build shows up.
- In iterations regression grows with every increment while the pass stays the same length; smoke sets, regression sets and automation all grow out of that.
- The build number is not a formality: without it a bug report loses half its meaning, and sprints plus a quarterly release with regression at the end is the most common reality — a deliberate trade-off.
What to read next
- Test levels — the four levels that grew out of the V-model's right branch.
- QA in Agile and Scrum — an iteration from the inside: the sprint, the board, the tester's place.
- Automation basics — where growing regression runs out of road and what gets automated first.
- What testing is — the cost of a bug stage by stage, once it is found after release.