Test Plan
A test plan with real entry and exit criteria, risk-based prioritisation, and an environment section — the three things most test plans skip.
No sign-up. No email. Markdown — edit it in anything.
When to use it
Once requirements are baselined, before build completes.
Who fills it in
Test lead or QA lead.
Works alongside: BRD · QA Checklist · Release Checklist
The template
Instruction lines are marked with > — delete them
once the document is filled in.
Project: _______________ Release: _______________ Version: 0.1 Test lead: _______________ Date: _______________
1. What we are testing#
Scope:
Explicitly NOT tested (and why):
Untested areas are a decision, not an oversight. Name them so the risk is owned.
2. Test basis#
The documents against which correctness is judged. If these are ambiguous, testing will be too.
| Document | Version | Owner |
|---|---|---|
| BRD | ||
| Functional spec | ||
| Acceptance criteria |
3. Approach by risk#
Not everything deserves equal effort. Rank by (likelihood of failure) x (cost of failure).
| Area | Risk | Depth of testing | Rationale |
|---|---|---|---|
| H/M/L | Exhaustive / Standard / Smoke |
4. Test types in scope#
| Type | In scope? | Owner | Notes |
|---|---|---|---|
| Functional | |||
| Regression | |||
| Integration | |||
| Performance | |||
| Security | |||
| Accessibility | |||
| Usability | |||
| Data migration | |||
| Disaster recovery |
5. Entry criteria#
Testing does not start until ALL of these are true. Starting early produces noise that discredits the whole effort.
- [ ] Requirements baselined
- [ ] Build deployed to the test environment and smoke-passes
- [ ] Test data available and representative
- [ ] Known open defects from the previous cycle documented
- [ ] Environment matches production in the ways that matter
6. Exit criteria#
Agree these BEFORE testing, or "are we done?" becomes a negotiation.
- [ ] 100% of planned test cases executed
- [ ] Zero open Critical or High defects
- [ ] Medium defects triaged and accepted by the sponsor
- [ ] Requirements traceability complete — every requirement has a result
- [ ] Performance thresholds met
- [ ] Sign-off obtained from: _______________
7. Environments#
| Environment | Purpose | Data | Refreshed | Owner |
|---|---|---|---|---|
| Real / Masked / Synthetic |
If test data differs from production in shape or volume, say how. Most "worked in test" failures trace to this row.
8. Test data#
Source: Personal data handling: How it is refreshed:
9. Defect management#
| Severity | Definition | Response |
|---|---|---|
| Critical | Blocks core business function, no workaround | Fix immediately, stop the release |
| High | Major function impaired, workaround painful | Fix before release |
| Medium | Function impaired, workaround acceptable | Fix or accept explicitly |
| Low | Cosmetic or minor | Backlog |
Triage: who, how often.
10. Traceability#
| Requirement | Test case(s) | Result | Evidence |
|---|---|---|---|
| BR-001 | Pass / Fail / Blocked |
11. Schedule#
| Phase | Start | End | Owner |
|---|---|---|---|
| Test preparation | |||
| Execution cycle 1 | |||
| Regression | |||
| UAT |
12. Risks to testing itself#
| Risk | Mitigation |
|---|---|
| Environment unavailable | |
| Test data not ready | |
| Requirements still changing |
13. Approval#
| Name | Role | Date |
|---|---|---|