Waterfall and the V-Model

Imagine Basketly built the old way: six months of writing requirements, then design, then coding, and finally a month of testing. In week one of testing you discover that nobody defined what happens when a delivery slot is full. Every other phase is finished, so the fix is slow and costly. Where testing sits in the plan decides when you find problems like that.

The rule

Waterfall tests at the end; the V-Model plans each test beside its build step.

Waterfall runs phases in a strict line, each finishing before the next begins:

Requirements → Design → Build → Test → Release → Maintain

It is simple to manage and suits projects whose requirements truly will not change, such as software written to a fixed regulation. Its weakness for testers is plain: testing is one late phase, so a misunderstanding made in month one is found in month five.

The V-Model keeps the same sequence down the left side, but gives every build phase a partner test level on the right side, planned at the same time:

Tests are still run after coding, climbing back up the right side, but they were designed early. Writing an acceptance test while requirements are being written is itself a review: vague requirements cannot be tested, so they get fixed.

The shortcut

Picture the letter V and read straight across it. Whatever phase you are in on the left, the test level directly opposite is the one you should be planning now.

The trap is thinking the V-Model means "test earlier". Most tests still run after coding; what moves earlier is the thinking about them.

Drills

Answer fast — trust the rule.

Remember

• Waterfall tests at the end; the V-Model plans each test beside its build step.
• Read straight across the V to know which test to plan now.
• Early test design is a review: requirements you cannot test are not finished.