A test plan turns the test strategy into executable work for a specific project, release or milestone. It states what will be tested, how, by whom, in which environment and what evidence is needed to finish.
On this practical guide
What a test plan is
A test plan coordinates testing for a defined delivery scope. It should answer:
- What is included and excluded?
- Which risks and requirements need evidence?
- Which test activities will be performed?
- Who is responsible and when will the work happen?
- Which environments, accounts, devices and data are required?
- What conditions must be met to start, pause and finish testing?
- How will results and remaining risk be communicated?
A test plan is not a test-case list: link to detailed cases, charters and automation instead of copying all of them into the plan.
When to use a test plan
| Situation | Suitable plan |
|---|---|
| Large project or new product | Project test plan covering phases, teams and major milestones. |
| Important release | Release test plan focused on changed features and regression. |
| Migration | Plan covering data validation, compatibility, cutover and rollback. |
| Non-functional campaign | Focused performance, security or accessibility plan. |
| Normal Scrum sprint | Often a lightweight page or ticket-linked checklist is enough. |
| Small low-risk change | Test notes inside the story may be sufficient. |
Scale the plan to the risk. Do not create a long document for a change that can be explained clearly in a few lines.
How to create the plan
- Confirm the objective. State what decision the testing must support.
- Define the test basis. Link requirements, designs, contracts, risks and changes.
- Set scope. List included features, affected systems and explicit exclusions.
- Analyse risk. Prioritise critical journeys and areas likely to fail.
- Select activities. Apply the test strategy to this delivery.
- Estimate work. Include preparation, execution, defect investigation, retesting and reporting.
- Confirm resources. People, environments, data, accounts, devices, tools and specialist support.
- Set criteria. Define when testing can start, pause, resume and finish.
- Agree schedule and dependencies. Connect testing to builds and deployment dates.
- Review and maintain. Update the plan when scope or risk changes.
Define scope and coverage
In scope
- Changed features and fixes.
- Directly affected existing behaviour.
- Critical journeys requiring regression.
- Relevant browsers, devices, roles and configurations.
- Required functional and non-functional testing.
Out of scope
Every exclusion should include a reason, risk owner and any alternative control.
Out of scope: Safari 15
Reason: Minimum supported version is Safari 17
Risk owner: Product Owner
Evidence: Supported-browser policy v3
Trace scope to evidence
| Requirement or risk | Test coverage | Evidence |
|---|---|---|
| Order retry must not duplicate payment | API idempotency, UI retry and focused regression. | Pipeline report and payment test record. |
| Viewer cannot edit an order | Role matrix at API and UI levels. | Automated report plus exploratory notes. |
| Checkout p95 below 800 ms | Staging load test with production-like workload. | Performance report and dashboard. |
Estimate and schedule testing
Include more than execution time. Typical effort contains:
- Requirement and risk analysis.
- Test design and review.
- Environment and data preparation.
- Automation implementation and maintenance.
- Manual and exploratory execution.
- Defect reporting, investigation and retesting.
- Regression and cross-browser execution.
- Result analysis and release reporting.
- Contingency for failed builds and unavailable dependencies.
Plan around builds, not only calendar dates: testing cannot start meaningfully if the required feature, environment or data is unavailable.
Entry, suspension and exit criteria
| Criteria | Practical examples |
|---|---|
| Entry | Scope agreed, build deployed, unit checks pass, environment healthy and data ready. |
| Suspension | Environment unavailable, build unusable or blocker prevents most planned testing. |
| Resumption | Blocking condition fixed, new build identified and affected setup revalidated. |
| Exit | Planned risk coverage complete, required suites pass and open defects are accepted. |
Use measurable criteria. “Testing complete” is not measurable. “All critical journeys executed with no open critical or high defect” is clearer.
Roles and communication
| Role | Typical responsibility in the plan |
|---|---|
| QA engineer | Risk analysis, test design, execution, automation, defect evidence and reporting. |
| Developer | Unit/component checks, testability, fixes, technical investigation and review. |
| Product Owner | Scope, acceptance criteria, business priority and acceptance of residual risk. |
| DevOps / operations | Pipeline, environments, deployment, monitoring and rollback support. |
| Specialists | Security, accessibility, performance or compliance assessment. |
Define the communication rhythm: daily blocker updates, defect triage, pipeline notifications and the final release-quality summary.
Copy-ready test plan template
Replace the text in square brackets and keep only sections that support the delivery.
# Test Plan — [Project / Release / Milestone]
Plan owner: [Name / role]
Version: [1.0]
Status: [Draft / Approved / Complete]
Created: [Date]
Last updated: [Date]
Related test strategy: [Link]
Release / build: [Version]
## 1. Objective
This plan defines the testing needed to support the decision to
[release / migrate / accept] [scope].
## 2. Test basis
- Requirements / stories: [Links]
- Designs: [Links]
- API contracts: [Links]
- Architecture / change set: [Links]
- Product risks: [Links]
- Definition of Done and acceptance policy: [Links]
## 3. Scope
In scope:
- [Feature, service or journey]
- [Supported role, platform and configuration]
- [Relevant non-functional characteristics]
Out of scope:
- [Excluded item]
Reason: [Reason]
Risk owner: [Owner]
Alternative control: [Control or none]
## 4. Test objectives
- Verify [business outcome]
- Confirm [risk is controlled]
- Provide evidence for [release decision]
## 5. Risk assessment
| Risk | Likelihood | Impact | Priority | Planned coverage |
|------|------------|--------|----------|------------------|
| [Risk] | [L/M/H] | [L/M/H] | [P1–P3] | [Tests] |
## 6. Test approach
Functional:
- [Acceptance, negative, boundary and exploratory testing]
Test levels:
- Unit/component: [Scope and owner]
- Contract/API: [Scope and owner]
- Integration: [Scope and dependencies]
- End-to-end: [Critical journeys]
Non-functional:
- Accessibility: [Scope and standard]
- Security: [Scope]
- Performance: [Workload and thresholds]
- Compatibility: [Browsers and devices]
- Visual: [Components/pages and baseline process]
Regression:
- Smoke suite: [Scope]
- Focused regression: [Affected areas]
- Full regression: [Need, schedule and exclusions]
Automation:
- Existing tests: [Suites]
- New automation: [Tests and owner]
- Manual-only scope: [Reason]
## 7. Test environment
Environment: [URL / name]
Build deployment process: [Process]
Configuration and feature flags: [Values]
Browsers/devices: [Matrix]
Dependencies: [Services and versions]
Environment limitations: [Differences from production]
## 8. Test data and accounts
Accounts and roles: [Details without secrets]
Data creation: [Method]
Data reset / cleanup: [Method]
Privacy: [Synthetic, masked or approved data]
External-system test data: [Details]
## 9. Entry criteria
- [Required build is deployed and identified]
- [Blocking unit and integration checks pass]
- [Environment and dependencies are healthy]
- [Required data, accounts and access are ready]
## 10. Suspension and resumption
Suspend when:
- [Blocking condition]
Resume when:
- [Condition is resolved and setup revalidated]
## 11. Exit criteria
- [Required tests executed]
- [Critical suites pass]
- [No open defect above agreed severity]
- [Known risks reviewed and accepted]
- [Evidence and report published]
## 12. Deliverables and evidence
- [Test cases / exploratory charters]
- [Automated reports]
- [Screenshots, traces or performance results]
- [Defect list]
- [Final test summary and release recommendation]
## 13. Roles and responsibilities
| Activity | Owner | Support |
|----------|-------|---------|
| [Activity] | [Role] | [Role] |
## 14. Schedule and milestones
| Milestone | Planned date | Dependency | Owner |
|-----------|--------------|------------|-------|
| [Build ready] | [Date] | [Dependency] | [Role] |
| [Execution] | [Date] | [Dependency] | [Role] |
| [Release decision] | [Date] | [Dependency] | [Role] |
## 15. Defect management
Tool / board: [Link]
Severity definitions: [Link]
Triage cadence: [When]
Evidence required: [Details]
Retest process: [Process]
## 16. CI/CD execution
Merge request checks: [Jobs]
Post-deployment smoke: [Jobs]
Scheduled regression: [Jobs]
Reports and artefacts: [Locations]
Quality gates: [Blocking rules]
## 17. Assumptions and dependencies
- [Assumption, owner and validation date]
- [Dependency, owner and required date]
## 18. Risks to the test plan
| Planning risk | Mitigation | Contingency | Owner |
|---------------|------------|-------------|-------|
| [Late build] | [Action] | [Fallback] | [Role] |
## 19. Communication
Daily status: [Channel / audience]
Defect triage: [Schedule]
Escalation: [Path]
Final report: [Audience and date]
## 20. Approval
Prepared by: [Name / date]
Reviewed by: [Names / dates]
Approved by: [Decision owner / date]
Short example: checkout release
Objective:
Verify the new payment retry flow and support release 2.8.0.
In scope:
- Card payment, timeout, retry and order confirmation
- Customer and support-agent roles
- Chromium, Firefox and mobile Chrome
- Payment API contract and duplicate-payment protection
Out of scope:
- PayPal redesign, scheduled for release 2.9.0
Main risks:
1. Retry creates two charges — Critical
2. Successful payment leaves order pending — High
3. Mobile keyboard hides Retry button — Medium
Approach:
- API idempotency and error-response tests
- Playwright critical E2E flow
- Network interruption exploration
- Focused checkout and order-history regression
- Mobile responsive and accessibility checks
Entry:
Build deployed to staging, payment sandbox available and API tests pass.
Exit:
All critical scenarios pass, no open Critical/High defect and
remaining risks accepted by the Product Owner.
Monitor and update the plan
A plan is a living coordination tool. Update it when:
- Scope, architecture or release date changes.
- A dependency or environment becomes unavailable.
- New information changes a risk priority.
- A build arrives late or with unexpected defects.
- Planned coverage is removed, added or moved after release.
Record important decisions and the person accepting the risk. Do not silently reduce scope.
Final test summary
At the end, report the outcome against the plan rather than only saying “QA passed”.
Release: [Version]
Build and environment: [Details]
Planned scope completed: [Yes / No — exceptions]
Results: [Passed, failed, blocked and not run]
Automation: [Suites and result links]
Open defects: [By severity with links]
Uncovered or deferred scope: [Items and reasons]
Residual risks: [Risk, impact and owner]
Recommendation: [Ready / Not ready / Ready with accepted risk]
Evidence: [Links]
Review checklist
- The objective and release decision are clear.
- Scope is specific and exclusions have risk owners.
- High risks receive the strongest coverage.
- Activities match the existing test strategy.
- Environment, data, dependencies and limitations are explicit.
- Entry, suspension and exit criteria are measurable.
- Schedule includes defect retesting and contingency.
- CI/CD execution and evidence locations are listed.
- Responsibilities and escalation paths are clear.
- The plan has an owner and is updated when conditions change.
Common mistakes
| Mistake | Better approach |
|---|---|
| Scope says “test the application” | Name features, risks, platforms and exclusions. |
| Dates ignore build readiness | Link milestones to clear dependencies and entry criteria. |
| Exit means every test passes | Use risk-based criteria and an explicit residual-risk decision. |
| Only manual execution is estimated | Include preparation, automation, defects, retest and reporting. |
| Plan is never updated | Record material scope, risk and scheduling changes. |
Useful links
- ISTQB Foundation Level ↗ — test planning, monitoring, risk and completion.
- ISTQB Test Management ↗ — project test planning and control.
- ISO/IEC/IEEE 29119-3 ↗ — test documentation templates.
- The Scrum Guide ↗ — iterative planning and Definition of Done.
- GitLab CI/CD testing ↗ — automated execution and test evidence.