On this page
science
Test Plan
What will be tested, how, by whom, and what we are consciously not testing.
Last updated
A test plan is a scoping document, not a list of tests. Its most valuable sections are the ones that say what will not be covered and what conditions stop testing — those are the statements that get renegotiated under deadline pressure, and having them written down is what makes that renegotiation visible.
When to use it
- Releases with an acceptance gate, external users, or regulatory exposure.
- Any test effort involving more than one team or a shared environment.
- Not for a single story; its acceptance criteria are its test plan.
What it must answer
- What is in scope, and at which level is each thing tested?
- What environments and data are needed, and who provides them?
- What are the entry and exit criteria, in numbers?
- What risks are we accepting by not testing something?
Template
Test Plan: <Release or system>
| Field | Value |
|---|---|
| Version / date | |
| Test lead | |
| Approvers | |
| Related | SRS v_, RTM v_ |
1. Scope
In scope / out of scope, by feature and by quality attribute.
2. Test levels and responsibility
| Level | What it proves | Owner | Automation |
|---|
3. Approach per quality attribute
Functional, performance, security, resilience, accessibility, data migration.
4. Environments
| Environment | Purpose | Data | Refresh | Owner |
|---|
5. Test data
Source, anonymisation, volume, and how personal data is handled.
6. Entry criteria
7. Exit criteria
Numbers, not adjectives.
8. Suspension and resumption criteria
When testing stops, and what must happen before it restarts.
9. Defect management
Severity definitions, triage cadence, who decides on deferral.
10. Risks to the test effort
| Risk | Impact | Mitigation |
|---|
11. Schedule and resources
12. Deliverables
# Test Plan: <Release or system>
| Field | Value |
|---|---|
| Version / date | |
| Test lead | |
| Approvers | |
| Related | SRS v_, RTM v_ |
## 1. Scope
In scope / out of scope, by feature and by quality attribute.
## 2. Test levels and responsibility
| Level | What it proves | Owner | Automation |
|---|---|---|---|
## 3. Approach per quality attribute
Functional, performance, security, resilience, accessibility, data migration.
## 4. Environments
| Environment | Purpose | Data | Refresh | Owner |
|---|---|---|---|---|
## 5. Test data
Source, anonymisation, volume, and how personal data is handled.
## 6. Entry criteria
## 7. Exit criteria
Numbers, not adjectives.
## 8. Suspension and resumption criteria
When testing stops, and what must happen before it restarts.
## 9. Defect management
Severity definitions, triage cadence, who decides on deferral.
## 10. Risks to the test effort
| Risk | Impact | Mitigation |
|---|---|---|
## 11. Schedule and resources
## 12. Deliverables
Worked example
Test Plan: Access Provisioning Service, release 1.0
| Field | Value |
|---|---|
| Version / date | 2.0 / 2026-09-08 |
| Test lead | H. Ito |
| Approvers | A. Vogel (engineering), K. Ferreira (business), L. Haddad (audit) |
1. Scope
In scope: all Must and Should requirements in SRS v2.0; the eleven target
system adapters; the joiner, mover and leaver flows; audit log completeness;
performance at graduate-intake volume; DR recovery.
Out of scope: the admin UI’s visual design (accessibility is in scope, look
and feel is not); the HR system itself; contractor identities (not built).
2. Test levels and responsibility
| Level | What it proves | Owner | Automation |
|---|---|---|---|
| Unit | State transitions, bundle resolution, validation | Developers | 100% automated, runs per commit |
| Contract | Adapter behaviour against recorded provider responses | Developers | Automated, nightly refresh check |
| Integration | End-to-end through real sandbox targets | QA | Automated, nightly |
| UAT | People Ops and managers can complete real tasks | Business | Manual, scripted |
| Performance | Intake volumes, p95 latency | QA | Automated, per release candidate |
| Security | Authorisation, secrets handling, injection | External pen test | Manual, once per release |
| DR | RPO/RTO under a simulated region loss | Platform | Manual exercise, once |
3. Approach per quality attribute
| Attribute | Approach | Evidence produced |
|---|---|---|
| Functional | Automated integration against sandbox targets, nightly, plus scripted UAT for the business flows | Suite results, UAT scenario sign-off |
| Performance | Load test at 40 events/h sustained and a 500-event intake burst, on the perf environment | p95/p99 latency, throughput |
| Resilience | Chaos runs killing one adapter, the poller leader, and the database primary in turn | Observed behaviour vs the failure-modes table in the design |
| Security | External penetration test on the release candidate; secret scanning and dependency gates in CI | Pen test report, CI evidence |
| Data migration | Not applicable — no legacy data is migrated. The 14-month backfill is validated by reconciliation against service desk tickets | Reconciliation report |
| Accessibility | Automated axe scan plus keyboard-only walkthrough of the admin UI, against WCAG 2.1 AA | Scan output, walkthrough notes |
| Auditability | 1,000-grant sample checked for a matching audit record; one auditor-led question answered end to end | Sample result, UAT scenario 7 |
4. Environments
| Environment | Purpose | Data | Refresh | Owner |
|---|---|---|---|---|
| dev | Developer testing | Synthetic, 50 employees | On demand | Platform |
| int | Automated integration | Synthetic, 4,000 employees | Nightly rebuild | QA |
| uat | Business acceptance | Anonymised production copy | Weekly | QA |
| perf | Load and soak | Synthetic, 6,000 employees | Per test | QA |
Only int and uat are connected to real vendor sandboxes. There is one uat
environment shared with the Finance reconciliation project — a scheduling
conflict risk, see section 10.
5. Test data
UAT data is a production copy with names, emails and free-text justifications
replaced by generated values; employee IDs are pseudonymised consistently so
relationships survive. No production personal data reaches dev, int or perf.
The anonymisation script is itself tested (TC-240) because a failure there
would be a personal data breach, not a test failure.
6. Entry criteria
- All Must requirements implemented and unit tested.
- Contract tests green against current sandbox recordings.
- Zero open Sev-1 defects; no more than 3 open Sev-2.
- uat refreshed within the last 7 days.
7. Exit criteria
- 100% of Must requirements have at least one passing test (per the RTM).
- >= 95% of Should requirements passing.
- Zero open Sev-1; zero open Sev-2 without a written, approved deferral.
- p95 provisioning latency <= 30 minutes at 40 events/hour, and the 500-event
intake completes within one working day. - DR exercise achieves RTO <= 4h and RPO <= 15 min.
- Pen test has no unresolved High or Critical finding.
- Audit log completeness check: 100% of grants in a 1,000-grant sample have a
matching audit record.
8. Suspension and resumption criteria
Testing is suspended if the int environment is unavailable for more than four
hours, if a Sev-1 defect blocks more than 30% of planned cases, or if a
sandbox provider changes behaviour mid-cycle. Resumption requires the blocking
condition cleared and a re-run of the affected suite from a clean state.
9. Defect management
| Severity | Definition | Response |
|---|---|---|
| Sev-1 | Wrong access granted or revocation fails; data loss; audit record missing | Stop the line, fix immediately |
| Sev-2 | Core flow blocked, no workaround | Fix before release |
| Sev-3 | Workaround exists | Fix or defer with approval |
| Sev-4 | Cosmetic | Backlog |
Triage daily at 09:30 during the cycle. Only the test lead plus the business
approver may defer a Sev-2, and only in writing.
10. Risks to the test effort
| Risk | Impact | Mitigation |
|---|---|---|
| uat shared with the Finance project | Cycle delayed by contention | Booked slots agreed 2026-09-01; escalation to M. Duarte |
| Vendor sandbox behaviour diverges from production | False confidence — assumption A-03 | 5% live ramp before full cutover; treat the ramp as a test phase |
| Anonymisation script defect | Personal data in a lower environment | TC-240 verifies it; uat refresh blocked if it fails |
11. Schedule and resources
| Phase | Dates | Who |
|---|---|---|
| Test design and case authoring | 2026-09-14 to 2026-10-02 | H. Ito, plus 2 days of A. Vogel’s time for the failure-mode cases |
| System test cycle 1 | 2026-10-05 to 2026-10-30 | H. Ito full time, developers on defect turnaround |
| System test cycle 2 (regression) | 2026-11-02 to 2026-11-14 | H. Ito full time |
| Penetration test | 2026-11-03 to 2026-11-07 | External supplier, A. Berg coordinating |
| DR exercise | 2026-10-22, one day | Platform team, H. Ito observing |
| UAT | 2026-11-17 to 2026-11-28 | Business participants, H. Ito coordinating |
| Reporting and exit review | 2026-12-01 to 2026-12-04 | H. Ito |
One tester for the whole cycle is the constraint. If cycle 1 finds more than
about 25 defects the regression cycle cannot also be completed by 2026-11-14,
and UAT moves rather than being shortened — see risk 1 in section 10.
12. Deliverables
Test plan (this), test cases in the tracker, defect reports, weekly progress
summary, RTM coverage extract, and the test summary report at exit.
# Test Plan: Access Provisioning Service, release 1.0
| Field | Value |
|---|---|
| Version / date | 2.0 / 2026-09-08 |
| Test lead | H. Ito |
| Approvers | A. Vogel (engineering), K. Ferreira (business), L. Haddad (audit) |
## 1. Scope
**In scope:** all Must and Should requirements in SRS v2.0; the eleven target
system adapters; the joiner, mover and leaver flows; audit log completeness;
performance at graduate-intake volume; DR recovery.
**Out of scope:** the admin UI's visual design (accessibility is in scope, look
and feel is not); the HR system itself; contractor identities (not built).
## 2. Test levels and responsibility
| Level | What it proves | Owner | Automation |
|---|---|---|---|
| Unit | State transitions, bundle resolution, validation | Developers | 100% automated, runs per commit |
| Contract | Adapter behaviour against recorded provider responses | Developers | Automated, nightly refresh check |
| Integration | End-to-end through real sandbox targets | QA | Automated, nightly |
| UAT | People Ops and managers can complete real tasks | Business | Manual, scripted |
| Performance | Intake volumes, p95 latency | QA | Automated, per release candidate |
| Security | Authorisation, secrets handling, injection | External pen test | Manual, once per release |
| DR | RPO/RTO under a simulated region loss | Platform | Manual exercise, once |
## 3. Approach per quality attribute
| Attribute | Approach | Evidence produced |
|---|---|---|
| Functional | Automated integration against sandbox targets, nightly, plus scripted UAT for the business flows | Suite results, UAT scenario sign-off |
| Performance | Load test at 40 events/h sustained and a 500-event intake burst, on the perf environment | p95/p99 latency, throughput |
| Resilience | Chaos runs killing one adapter, the poller leader, and the database primary in turn | Observed behaviour vs the failure-modes table in the design |
| Security | External penetration test on the release candidate; secret scanning and dependency gates in CI | Pen test report, CI evidence |
| Data migration | Not applicable — no legacy data is migrated. The 14-month backfill is validated by reconciliation against service desk tickets | Reconciliation report |
| Accessibility | Automated axe scan plus keyboard-only walkthrough of the admin UI, against WCAG 2.1 AA | Scan output, walkthrough notes |
| Auditability | 1,000-grant sample checked for a matching audit record; one auditor-led question answered end to end | Sample result, UAT scenario 7 |
## 4. Environments
| Environment | Purpose | Data | Refresh | Owner |
|---|---|---|---|---|
| dev | Developer testing | Synthetic, 50 employees | On demand | Platform |
| int | Automated integration | Synthetic, 4,000 employees | Nightly rebuild | QA |
| uat | Business acceptance | Anonymised production copy | Weekly | QA |
| perf | Load and soak | Synthetic, 6,000 employees | Per test | QA |
Only int and uat are connected to real vendor sandboxes. There is one uat
environment shared with the Finance reconciliation project — a scheduling
conflict risk, see section 10.
## 5. Test data
UAT data is a production copy with names, emails and free-text justifications
replaced by generated values; employee IDs are pseudonymised consistently so
relationships survive. No production personal data reaches dev, int or perf.
The anonymisation script is itself tested (TC-240) because a failure there
would be a personal data breach, not a test failure.
## 6. Entry criteria
- All Must requirements implemented and unit tested.
- Contract tests green against current sandbox recordings.
- Zero open Sev-1 defects; no more than 3 open Sev-2.
- uat refreshed within the last 7 days.
## 7. Exit criteria
- 100% of Must requirements have at least one passing test (per the RTM).
- >= 95% of Should requirements passing.
- Zero open Sev-1; zero open Sev-2 without a written, approved deferral.
- p95 provisioning latency <= 30 minutes at 40 events/hour, and the 500-event
intake completes within one working day.
- DR exercise achieves RTO <= 4h and RPO <= 15 min.
- Pen test has no unresolved High or Critical finding.
- Audit log completeness check: 100% of grants in a 1,000-grant sample have a
matching audit record.
## 8. Suspension and resumption criteria
Testing is suspended if the int environment is unavailable for more than four
hours, if a Sev-1 defect blocks more than 30% of planned cases, or if a
sandbox provider changes behaviour mid-cycle. Resumption requires the blocking
condition cleared and a re-run of the affected suite from a clean state.
## 9. Defect management
| Severity | Definition | Response |
|---|---|---|
| Sev-1 | Wrong access granted or revocation fails; data loss; audit record missing | Stop the line, fix immediately |
| Sev-2 | Core flow blocked, no workaround | Fix before release |
| Sev-3 | Workaround exists | Fix or defer with approval |
| Sev-4 | Cosmetic | Backlog |
Triage daily at 09:30 during the cycle. Only the test lead plus the business
approver may defer a Sev-2, and only in writing.
## 10. Risks to the test effort
| Risk | Impact | Mitigation |
|---|---|---|
| uat shared with the Finance project | Cycle delayed by contention | Booked slots agreed 2026-09-01; escalation to M. Duarte |
| Vendor sandbox behaviour diverges from production | False confidence — assumption A-03 | 5% live ramp before full cutover; treat the ramp as a test phase |
| Anonymisation script defect | Personal data in a lower environment | TC-240 verifies it; uat refresh blocked if it fails |
## 11. Schedule and resources
| Phase | Dates | Who |
|---|---|---|
| Test design and case authoring | 2026-09-14 to 2026-10-02 | H. Ito, plus 2 days of A. Vogel's time for the failure-mode cases |
| System test cycle 1 | 2026-10-05 to 2026-10-30 | H. Ito full time, developers on defect turnaround |
| System test cycle 2 (regression) | 2026-11-02 to 2026-11-14 | H. Ito full time |
| Penetration test | 2026-11-03 to 2026-11-07 | External supplier, A. Berg coordinating |
| DR exercise | 2026-10-22, one day | Platform team, H. Ito observing |
| UAT | 2026-11-17 to 2026-11-28 | Business participants, H. Ito coordinating |
| Reporting and exit review | 2026-12-01 to 2026-12-04 | H. Ito |
One tester for the whole cycle is the constraint. If cycle 1 finds more than
about 25 defects the regression cycle cannot also be completed by 2026-11-14,
and UAT moves rather than being shortened — see risk 1 in section 10.
## 12. Deliverables
Test plan (this), test cases in the tracker, defect reports, weekly progress
summary, RTM coverage extract, and the test summary report at exit.
Common mistakes
- Exit criteria written as adjectives. “Quality is acceptable” cannot be argued with data. Numbers can.
- No suspension criteria. Teams grind on against a broken environment, producing results nobody trusts.
- Out-of-scope section missing. Everyone then assumes their concern is covered, and discovers otherwise after release.
- Test data handling unstated. Copying production data into a test environment is one of the most common sources of real breaches.
- A plan that duplicates the test cases. Keep cases in the tracker; the plan says what kinds exist and why.
Related templates
- Test Case Specification — the level of detail this plan deliberately omits.
- UAT Plan — the business acceptance slice.
- Test Summary Report — reports against these exit criteria.
- Requirements Traceability Matrix — where coverage is proven.
- Testing & QA — the other four testing and QA templates.
Linked from
- API Specification — The contract between two teams: resources, errors, versioning and what happens when it breaks.
- Defect Report — Enough information for someone else to reproduce the problem without asking you a single question.
- Requirements Traceability Matrix — One table proving every requirement reached design, code and test — and that nothing untraceable was built.
- Software Requirements Specification — System-level functional and non-functional requirements, each one testable.
- Test Case Specification — Cases precise enough that two testers get the same result, and a failure is unambiguous.
- Test Summary Report — What was tested, what was found, and what is being shipped with known problems.
- UAT Plan — How business users will decide whether to accept the system — and what happens when they do not.
Last updated 23 Aug 2026, 17:59 -0500.