Test plan vs test strategy

A test strategy is the organisation's standing approach: levels, types, tools, severity scale, sign-off rules, written once. A test plan is the document for one release: scope, people, schedule, environments, risks and the entry and exit criteria for each phase. The strategy is inherited by every plan; the plan applies it to one piece of work.

The strategy, because the plan applies it. In practice many teams write their first plan before any strategy exists and extract the strategy afterwards, by moving the paragraphs that would be identical in the next plan into a separate document. Either order works as long as the release-specific content ends up in the plan.

The strategy is written by whoever leads quality across the organisation, a QA manager or head of engineering, and reviewed rarely. The plan is written by the test lead for that release, agreed with the development lead and the product owner, and it is the document a project manager reads to know what testing will take and when it ends.

Rarely, and on a trigger rather than a schedule: a new test level is introduced, the tooling changes, the severity scale is revised, or a release reveals that two teams have been testing differently. A strategy edited every release has plan content in it. A plan is revised whenever its release changes scope, people or dates, which is often.

A small team needs the content of both and can keep it in one document, provided the standing sections and the release-specific sections are kept apart. The standing part, levels, tools, severity scale and sign-off rules, is written once and left alone; the per-release part, scope, people, dates and risks, is rewritten each time. Splitting the file becomes worthwhile when a second team starts copying it.