Test plan

A test plan describes how testing will be done for a specific release, project or feature: what is in and out of scope, which types of testing apply, who does what, where it runs, when it happens and how the team will know it is done. It is the agreement between QA, development and product about testing, written down before execution starts. The IEEE 829 standard (now superseded by ISO/IEC/IEEE 29119-3) is the classic template.

What a useful test plan contains

• Scope: features in scope and, just as important, explicitly out of scope.
• Approach: test levels and types (unit, API, UI, performance, security, accessibility), what is automated versus manual.
• Environments and data: which environments, how test data is created or masked, third-party sandboxes.
• Entry criteria: what must be true before testing starts, such as “build deployed to staging and smoke tests green”.
• Exit criteria: what “done” means, such as “no open critical or major defects, all P1 scenarios passed, regression suite green”.
• Risks and mitigations: for example, “payment sandbox is unstable, so we will stub it for functional tests and run one daily end-to-end check against the real sandbox”.
• Roles, schedule and deliverables: who tests what, key dates, and which reports are produced.

Test plan vs test strategy

A test strategy is the high-level, longer-lived approach for a product or organization: the testing principles, levels, tools and standards. A test plan applies that strategy to one release or project with concrete scope, dates and people. Many agile teams keep a lightweight strategy page and a short plan per release or epic.

Common mistakes

• Writing a 40-page document nobody reads. In agile teams, a one-page plan that is kept current beats an exhaustive one that is out of date by sprint two.
• Vague exit criteria. “Testing complete” is not measurable. State the conditions.
• No out-of-scope section. Unstated exclusions turn into arguments after release.