Building a Test Plan

The payment team ships release 4.12 with saved-card checkout, a pricing-rule change, and a notifications refactor. The test plan you write now is the artifact the team will argue with for three weeks — so its structure should match how the arguments actually happen: what is in scope, what covers it, who does the work, when it runs, and what 'done' means in numbers.

1. Scope: features in, features out. Start with a table, not prose:

The out-of-scope column is the plan's most valuable line. Every unstated exclusion becomes an argument at exit-criteria time; a written exclusion becomes a decision product already accepted.

2. Feature-to-test-case mapping with ownership. The heart of the plan — one row per feature, per level:

Two disciplines make this table work. Every case has an ID and an owner — 'the team will test notifications' means nobody will. Effort estimates attach to rows, which is how the schedule in the next section is built and how you notice at planning time that the request exceeds the capacity (three feature areas, 4.7 days of QA work, one QA engineer, sprint contains other commitments — visible on day one, not day nine).

3. Environments and data. Name them concretely: Staging (schema-mirrored, Stripe test mode, seeded card fixtures: Visa, Mastercard, expired, declined) and Pre-prod (masked-data shape for the load run). State the test-data rule that prevents the classic incident: saved-card fixtures use sandbox tokens only; no production card data crosses into test, encrypted or otherwise.

4. Schedule and milestones. Map to the sprint, not to a Gantt fantasy: 'Day 1-2 API testing on build candidate; Day 3 E2E pass 1; Day 4 regression + load run; Day 5 buffer for defect retests and exit report.' Include the retest loop explicitly — plans that assume a single pass are the main reason test phases overrun, because fixes land mid-cycle and regression must re-run.

5. Entry/exit criteria and defect policy. Inherit the strategy's standards and add release-specific numbers (covered in the next chapter). 6. Risks. Top three with mitigation and owner (again next chapter). 7. Assumptions and dependencies. 'The pricing service freeze holds after Day 1; Stripe sandbox has no regional outage scheduled' — assumptions are where schedule risk hides, and writing them down converts surprises into checkable conditions.

Keep the whole plan to two or three pages. A plan's job is to be read before the sprint starts and consulted during it; a 15-page plan achieves neither. Put depth (case lists, data sets) in the test management tool and let the plan link to it.

Testing finished Friday. The suite is 97% green, two major defects are open, and the product owner wants to ship Monday because of a marketing event. If your plan says 'exit when testing is complete', you have already lost the argument — the phrase means whatever the loudest person needs it to mean. Measurable exit criteria replace interpretation with arithmetic, and writing them is the highest-leverage hour in plan authoring.

A release-grade exit section for release 4.12:

Exit criteria (all must hold; QA lead verifies, product owner accepts):
1. Requirement coverage: 100% of in-scope features have at least one executed, passing test at API level;
   saved-card and pricing also pass their E2E journeys.
2. Defects: zero open BLOCKER/CRITICAL; MAJOR defects each carry a documented fix-or-defer
   decision signed by product; MINOR count ≤ 10, all triaged.
3. Pass rate: ≥ 98% of planned test cases passed on the candidate build;
   every failure dispositioned as fixed-retested, deferred, or invalid-test.
4. Regression: full automated regression green on the final build; flaky failures re-run
   once, persistent flakes documented — not ignored.
5. Non-functional: load run holds 500 TPS for 30 minutes at p95 < 400 ms;
   accessibility scan has no critical violations.
6. Sign-off: exit report (summary, coverage, defect snapshot, risks) accepted by
   product owner and engineering lead before the release train departs.

Read it as a negotiator and notice the pressure points. Criterion 2 is where Friday's argument gets settled: with this text, 'two open majors' means product must sign a deferral naming the accepted user impact — a decision with a record, not a hallway shrug. Criterion 3 forces disposition of every failure, which kills the practice of leaving red tests unexamined. Criterion 4 names flaky handling explicitly, because 'the suite is flaky anyway' is where regression credibility dies.

Two writing rules keep criteria enforceable. Binary or numeric only: 'adequate coverage' is an argument; '100% of in-scope features covered at API level' is a check. Single verifier per criterion: 'QA lead verifies, product owner accepts' means no committee can wave a criterion through — and no single person can quietly fail one either. When a criterion cannot be met at release time (the load run fails at 380 TPS), the escalation path is defined by the plan: QA reports the failed criterion with data, product and engineering decide fix, descope, or accept-with-record — and that decision belongs in the exit report.

Interviewers probe this with 'what are your exit criteria?' The shape to deliver, from memory: coverage threshold, zero criticals with a disposition policy for majors, pass rate with failure dispositions, green regression, non-functional gates if applicable, signed exit report. Candidates who add the disposition mechanics — fix-or-defer signatures, flaky handling, single verifier — demonstrate they have closed a real release, not only read a template.

A final pattern from real cycles: the exit report itself. Fifteen minutes of writing after the criteria are evaluated — what was tested, the coverage achieved, the defect snapshot by severity with dispositions, the risks accepted with sign-off names, and the recommendation. Done every release, these reports compound: six months later you can answer 'is this release riskier than the last one?' with evidence instead of memory, and the exit conversation with product shrinks from an hour of debate to a review of recorded decisions. The report is also the natural artifact to bring to post-incident reviews, because it shows the quality state at the moment of the ship decision.

It is Wednesday of the sprint. Product descopes the notifications refactor from release 4.12. The pricing service owner announces a schema change that lands Friday. Your plan, written Monday, is now wrong in both directions — it contains work that no longer exists and misses work that was just invented. A plan treated as a founding document decays into fiction; a living plan is updated at defined moments, and the update itself is a small, repeatable procedure.

The procedure has four moves.

Move 1: reconcile the scope table. Remove the descoped feature row entirely and record the removal in the plan's change log ('Wed: notifications refactor descoped per product — saves 0.2 day regression, removes TC-API-140..176 from this cycle'). Removing rows without a log entry makes reviewers distrust the document; the log is what keeps the plan auditable.

Move 2: assess new work against capacity. The pricing schema change means the 9 contract tests need extension and a full re-run of the pricing integration suite — call it +0.75 day. Current load was 4.7 days; with the notifications saving, you are at 4.85 of a capacity the sprint set at 4.5. The plan now shows a 0.35-day deficit two days before it becomes a crisis, and the options can be priced: cut the third E2E journey (−0.25), borrow half a day from the release buffer, or negotiate scope with product again. Every option is discussable now and impossible on Friday afternoon.

Move 3: re-baseline the schedule and criteria. Shift the milestones ('Day 4: pricing re-test + load run; Day 5: final regression + exit') and check whether exit criteria still mean what they did: the 100% coverage criterion now covers a different feature set, which is fine as long as the rewritten row is visible. Never re-baseline silently — a plan whose dates changed without explanation trains everyone to distrust its dates.

Move 4: communicate the delta, not the document. Post the change-log entries to the team channel and raise any capacity decision at standup. Stakeholders do not re-read three-page plans mid-sprint; they act on deltas: 'pricing change adds 0.75 day; I propose dropping E2E journey 3 and starting the load run a day later — objections by noon.'

Cadence rules make this sustainable: formal review at sprint planning (the plan is part of the sprint's definition of ready), then event-driven updates at scope changes, with a hard rule that the plan is re-confirmed at the sprint review — three touchpoints, none of them heroic.

The interview scenario to expect: 'the scope changed mid-test-cycle — what do you do?' Answer with the four moves — reconcile scope with a change log, price the new work against remaining capacity, re-baseline schedule and criteria visibly, communicate deltas — and close with the principle: the plan's value is not its predictions, it is its continuous accuracy; a plan updated on Wednesday is worth more than a perfect plan written three weeks ago and never touched. How the plan's risk rows get scored and how test effort gets estimated are the next two topics, starting with Risk-Based Test Prioritization.