QA in Waterfall Development: Problems and Test Techniques

In waterfall development, QA has the most leverage during requirements and design—not during the test phase. Most defects found in testing originate in upstream ambiguity, and by the time you find them there, they are expensive to fix.

Waterfall runs in one direction, so defect discovery is structurally late. There are only two ways to close that gap: use the V-model idea to design tests alongside each upstream deliverable, and use test techniques as review tools rather than only as execution tools.

This article covers five problems that actually occur on waterfall projects and what to do about each, including how to apply specific test techniques upstream.

Why QA ends up last in waterfall

Waterfall proceeds in order: requirements, high-level design, detailed design, implementation, testing, release. Because there is exactly one phase called “testing” and it sits near the end, people assume QA work belongs there.

In practice, most defects found during testing are not coding mistakes. They are misread requirements and gaps in the specification—built upstream, discovered downstream. The later they surface, the more expensive they are, because the impact has spread through design, implementation, and adjacent features.

Thinking in the V-model

Fold waterfall in half and you get the V-model, which makes it clear that every upstream deliverable has a corresponding test level.

Upstream phase	Corresponding test	What QA does here
Requirements	Acceptance testing	Write acceptance criteria alongside the requirements
High-level design	System testing	Build a test-condition list; surface gaps in the spec
Detailed design	Integration testing	Identify boundaries in interface specifications
Implementation	Unit testing	Agree with developers on what unit tests cover

The point is to shift test design left, not test execution. The act of trying to write test cases forces specification ambiguity to the surface. Removing it before implementation is QA’s largest contribution.

Problem 1: expensive rework

Symptom: a difference in interpretation surfaces during testing, and the design has to be redone.

What to do: attend design reviews already carrying test conditions. Simply “being in the review” achieves nothing; bring specific questions.

“Where is the behaviour documented when this field is left empty?”
“At exactly the upper limit—error, or allowed?”
“If this process times out midway, what state is the data left in?”
“When this runs at the same time as the existing feature, which one wins?”

These questions are test techniques repurposed for design review. Every unanswerable question you find upstream is one less defect in the test phase.

Problem 2: specification changes are hard to absorb

Symptom: a change lands late, and nobody knows which test cases need updating.

What to do: maintain a traceability matrix linking requirements to test cases from the start. With requirement IDs mapped to test case IDs, you can derive the impacted set mechanically from the changed requirement.

Also, write test cases in terms of the decision being tested rather than the steps to take, so UI changes do not invalidate them. “Submit a request one over the limit” survives a screen redesign; “click button A” does not. I have written about this in more detail in Should test cases include steps?

Problem 3: communication gaps between phases

Symptom: design intent does not travel, so implementation and testing are working from different assumptions.

What to do: turn the interpretation into a table. Confirming in prose leaves room for divergent readings; a table of conditions and outcomes makes the disagreement visible immediately. Decision tables, covered below, are ideal for this.

Changing the shape of the artefact beats adding more meetings. Whatever was verbally confirmed in a meeting is gone from everyone’s memory by the following week.

Problem 4: testing is compressed at the end

Symptom: implementation slips, and the slip comes straight out of the test window.

What to do: this is a scheduling problem QA cannot solve alone. What is achievable is agreeing on priority in advance.

Using risk-based testing, rank test targets by likelihood × impact before the pressure arrives. When the window shrinks, you can decide what to drop by prior agreement rather than by instinct.

Impact \ Likelihood	High	Low
High (payment, data loss)	Top priority; cover thoroughly	Always run; representative values
Low (layout glitches)	If there is capacity	Candidate to drop

“We can’t cut anything” is not a negotiating position. “Here is what I will cut” is.

Problem 5: inconsistent test case granularity

Symptom: different people write at different levels of detail, producing gaps and duplication at the same time.

What to do: use test techniques explicitly. A technique is a written-down coverage criterion, so agreeing on the technique makes the granularity consistent.

Four test techniques to use in design review

These are not only for execution. Upstream, they are instruments for finding gaps in the specification.

1. Equivalence partitioning and boundary value analysis

Use: stop vague numeric, date, and length rules from reaching implementation.

Given “values from 1 to 100 are accepted,” lay out the boundaries:

Value	Expected	In the spec?
0	Error	Not stated
1	OK	Yes
100	OK	“Up to 100” — inclusive or not?
101	Error	Not stated
Empty	?	Missing
Full-width numerals	?	Missing

“Up to 100” does not settle whether 100 is included. Confirming that one point before implementation removes one defect later. See equivalence partitioning and boundary value analysis.

2. Decision table testing

Use: find missing combinations in business logic with multiple conditions.

Take shipping cost that depends on membership tier and order value:

Condition	1	2	3	4
Paid member	Y	Y	N	N
Order ≥ 5,000 yen	Y	N	Y	N
Shipping	Free	Free	Free	?

Listing every combination mechanically makes the undocumented cell visible. Is it 550 yen, or has nobody decided? Catching that is the whole point. See effective use of decision table testing.

3. State transition testing

Use: in workflows and approval flows, identify the transitions that must never happen.

For submitted → approved → completed, check the arrows nobody drew, not just the happy path:

Can something go from “completed” back to “submitted”?
What happens if two approvers approve simultaneously?
What if the submitter’s account is deleted while approval is pending?
What if someone acts on a stale screen after using the browser back button?

The empty cells in a state transition table are where the most painful production defects live. See practical state transition testing.

4. Pairwise testing

Use: reduce an unmanageable combination space to a realistic number of cases.

Three operating systems × three browsers × two membership tiers × two currencies is 36 combinations, but selecting cases so that every pair of factors appears at least once brings it to around ten. It rests on the empirical observation that most defects arise from two interacting factors.

It is a practical lever when the schedule gets cut. See the basics and practice of pairwise testing.

The mindset that makes QA effective in waterfall

Define QA as “the person who finds defects” and you will always be late in waterfall. Define it as “the person who checks whether the specification has actually been decided” and the phases you can act in expand enormously.

Concretely, three habits help:

Report what has not been decided, with the same weight as a defect report
Record the reasoning—why you tested this and not that. It becomes your material when the schedule is cut
Feed production incidents back upstream: classify which phase each defect was introduced in, and turn that into review conditions for the next project

QA works differently under agile; I have covered that separately in QA in agile development.

Summary

Waterfall discovers defects late by construction. Only shifting test design left closes the gap
Use the V-model: design the corresponding test alongside each upstream deliverable
Bring specific questions to design review: “What happens when it is empty?” “What about exactly the limit?”
Build a requirement-to-test-case traceability matrix from day one
Resolve misalignment with tables, not meetings
Agree on risk-based priority before the schedule is cut
Use test techniques as tools for finding design gaps, upstream

You do not have to accept that QA comes last because the process is waterfall. Writing test cases is the single most effective way to detect ambiguity in a specification—do it before implementation starts and the end of the project gets considerably less painful.