Test plan

A test plan states the testing intent for a piece of work before the testing starts. The version that earns its keep is short and decisive: what is in scope, what is explicitly excluded, which environments and data are required, who is doing the work, and the conditions under which the team would recommend not shipping. Everything else people traditionally put in one — templates, tool inventories, restatements of the requirements — is either available elsewhere or was never read by anybody.

Its real function is to force decisions into the open while they can still be changed cheaply. Writing down that a payment integration will be tested only against the sandbox, or that no load testing is planned, converts an assumption into something a stakeholder can object to in week one rather than discover in week six. Most of the value is extracted during the argument the draft provokes, which is why a plan produced after testing has begun is documentation rather than planning.

What belongs in one, and what does not

• The exclusions, stated plainly. A scope section listing only what is included leaves every reader to assume their own concern is covered, and they will each assume differently.
• Entry and exit conditions expressed as observations rather than aspirations, so "ready to test" and "done" are checkable claims instead of judgements made under pressure.
• Dependencies with owners and dates — the third-party sandbox, the anonymised dataset, the staging environment — since these are what actually delay testing.
• Not a list of test cases. Cases live in the tool that runs them, and copying them into a document guarantees two versions that disagree within a fortnight.

If nobody disagreed with any part of the draft, the plan was probably too vague to be useful: an uncontroversial plan usually means the hard scope questions were left implicit.