Test plan: a one-page document people actually read

A test plan is not a formality; it exists so the team and the client share one understanding of what is checked, on what, when and by which criteria a release counts as ready. If the document does not fit on a page it will not be read — and that is worse than having none.

Seven sections that are enough

• Scope: which features, screens and flows are included and, more importantly, which are not. Boundaries prevent disputes after release.
• Environments and devices: stands, builds, a list of devices and browsers stating what is checked on real devices and what in an emulator.
• Types of testing: functional, regression, load, LQA — each with an answer to "why here".
• Entry and exit criteria: when testing can start (the build is stable, test data is ready) and when it can stop (all blockers closed, share of passed cases, open defects agreed).
• Risks and assumptions: what can derail the schedule — a late build, an unavailable payment stand, no test accounts — and what we do in that case.
• Schedule and roles: who runs what on which days, who makes the release decision.
• Deliverables: what the client receives — test cases, report, defect register, protocols.

What a test plan must not contain

Rewritten requirements — a link is enough. A list of every test case — the tracker is for that. Generic phrases about "ensuring quality" and "methodologies". A three-page document version history. All this inflates the plan to a size at which it is opened once — to sign.

Exit criteria are the most important part

Exit criteria are what turn a test plan from a description into an agreement. Without them "we tested it" can mean anything. A working wording looks like this: the regression suite passed in full on the main environments; no blockers or critical defects; the list of open defects below critical is agreed by the product owner; the report and defect register handed over. Any deviation from the criteria is a conscious business decision recorded in writing, not "well, it seems to work".

How the plan lives after it is written

1. Agreed with the product owner and the dev team before work starts — comments are fixed immediately.
2. Becomes an annex to the contract or the task: scope and criteria are fixed.
3. Updated when the scope changes — a new feature, a new environment, a moved deadline — as a separate line in the changes section.
4. Checked at acceptance: the test report refers to the exit criteria from the plan.

Example scope for a small release

A mobile app release with a new promo code mechanic. In scope: applying a promo code at every entry point, discount calculation, restrictions, notifications, cart and payment regression on iOS and Android, LQA in two languages. Out of scope: the account except order history; the web version. Environments: pre-production with live gateway settings in test mode. Devices: two iOS models, three Android, including a budget one. Exit criteria: regression passed, no blockers, open defects agreed. Timeline: three days of testing plus a day to re-check fixes.