What Is a Test Plan? The Page That Says What You Are Not Testing

A test plan is a short document saying what will be tested, what will not, by whom, in which environments, and what has to be true before anybody starts or stops. It is written before the testing, and its main value is the second item on that list.

Anybody can list what they intend to check. Writing down what you are deliberately leaving alone is the part that prevents the conversation three weeks later where somebody assumed a thing was covered because nobody said it was not.

What goes in one

Six sections carry nearly all the value, and they can each be a few lines.

• Scope. What this round of testing covers: which features, which releases, which platforms.
• Out of scope. What it deliberately does not, and why. The most useful section and the one most often missing.
• Approach. Manual, automated, or the split between them, and at which level.
• Environments and data. Where it runs and what it runs against, which decides what can be found. A plan that says “staging” without saying which build and which data is not saying much.
• Entry and exit criteria. What must be true before testing starts, and what must be true before it is called finished.
• Risks. What could stop this plan working, named while it is cheap to say.

Some plans add roles, a schedule and a defect process. Those matter more the more people are involved and matter very little when it is two of you.

Exit criteria are where the arguments happen

“Finished” is not obvious, and a plan that does not define it produces a release argued about on the day rather than agreed in advance.

Weak

All major bugs fixed and testing complete

Better

Every case in the checkout suite passes, no open defects at severity 1 or 2, and the three known severity 3 defects are recorded with workarounds in the release notes

The second one can be checked by somebody who was not in the room. The first is a mood.

The same applies to entry criteria: agreeing that testing starts when the build passes its smoke test saves a tester an afternoon spent proving a broken build is broken in forty ways.

How long it should be

Shorter than you think, and proportional to how many people need to agree.

Two people testing a feature they both understand need a paragraph, and writing more is theatre. A regulated release with an external auditor needs the formal document, because somebody outside the team has to be able to read what was decided. Most work sits between, and one page is usually right.

The test to apply: would anybody’s behaviour change if this section did not exist? If not, delete it. A plan nobody reads is worse than none, because it creates the belief that testing was planned.

Where it sits among the other documents

A plan is the level above the checks themselves.

• The plan says the checkout flow will be tested manually on Chrome and Safari, and that mobile is out of scope this round.
• The test cases say exactly what to do and what should happen.
• The regression suite says what gets re-checked because it used to work.
• Acceptance criteria say what the feature had to do in the first place, and they were written before any of it.

Confusing the plan with the cases is the common mistake: a document listing two hundred steps is not a plan, it is a suite with a title page.

The defect process belongs in it

One line most plans skip, and it costs more than it looks. Say how a defect gets reported, where it goes, and who decides whether it stops the release.

Without that, findings arrive in three chat threads and a spreadsheet, the person collecting them spends the last day of the round chasing detail, and something real gets lost in the noise. Name the destination and the shape of what goes into it, and link the guidance rather than restating it - our bug report guide exists to be the thing you link.

If testers are people whose job is not software, the shape matters more, not less. Ask them for what happened and what they expected, and let the tooling carry the technical part.

The short version

One page: what is covered, what is not, how, where, what has to be true to start and to stop, and what could go wrong. Written before the testing, agreed by the people it affects, and short enough that they read it. The section everybody skips - out of scope - is the one that prevents the argument.