Test Plan Template
A lightweight sprint/feature test plan for NZ Agile teams. Covers scope, objectives, approach, environments, risks, and sign-off in one page — without the ceremony of a programme-level master plan.
1 Plan vs Strategy
These terms are used interchangeably on many NZ projects — wrongly. They operate at completely different levels. A test strategy is organisation-wide or programme-wide: it describes the overall testing philosophy, standards, and approach that applies across all projects. A test plan is specific to one release, sprint, or feature: it describes what will be tested, how, by whom, and when, for this delivery.
| Dimension | Test Strategy | Test Plan (this template) |
|---|---|---|
| Scope | Programme, product line, or organisation | Single sprint, release, or feature |
| Owner | Test Manager / Head of QA | QA Lead or tester assigned to the sprint |
| Lifespan | Months to years — updated rarely | One sprint or release cycle |
| Contents | Standards, tools, metrics framework, risk appetite, test levels, automation policy | In-scope stories, test types for this sprint, environments, test data, entry/exit criteria, risks, schedule |
| Audience | QA guild, architecture, governance | Delivery team, Product Owner, Scrum Master |
| Example in NZ context | "All Westpac NZ digital products will use BDD at the API layer and maintain 80% branch coverage." | "Sprint 14 — Change Address feature: functional, API, and regression tests. No performance testing this sprint." |
2 When to Write One
Not every change needs a formal test plan. Use this heuristic:
| Situation | Write a test plan? | Why |
|---|---|---|
| Two-week sprint, 3–5 stories, stable team | Yes — one page | Forces scope agreement before dev starts; sprint retro reveals if entry/exit criteria were met |
| Major feature touching payments, auth, or personal data | Yes — full plan | Auditors (PCI DSS, Privacy Act) may ask for evidence of test coverage; a plan is that evidence |
| Single-story hotfix on a live NZ banking system | Minimal — checklist only | Speed matters; scope is already defined by the single bug; attach checklist to the ticket instead |
| New integration with IRD, MSD, or ACC API | Yes — full plan | Government integrations have compliance requirements; test approach must be documented for sign-off |
| Pure infrastructure change (server upgrade, DB migration) | Yes — focus on regression | Scope is "nothing broke"; plan documents the regression baseline and environment validation steps |
| Bug fix for a UI typo | No | One assertion; just test it and close the ticket |
Agile reality: Many NZ teams write the test plan during sprint planning and store it as a Confluence page or a Jira epic description. The format is less important than the conversation it forces — who decides what is in scope, what "done" looks like, and what risks are being accepted.
3 The Template
Copy this block and fill in each section. Fields marked required must be completed before testing begins. Fields marked optional can be skipped for low-risk sprints.
# TEST PLAN
Project / Feature : [feature or sprint name]
Version : [v1.0]
Author : [your name]
Date : [YYYY-MM-DD]
Reviewers : [names]
Status : Draft | In Review | Approved
─────────────────────────────────────────────
1. SCOPE
─────────────────────────────────────────────
In scope:
- [list features, user stories, or acceptance criteria being tested]
Out of scope:
- [explicitly name what is NOT being tested this sprint]
- [e.g. "Performance testing — deferred to Sprint 16"]
─────────────────────────────────────────────
2. OBJECTIVES
─────────────────────────────────────────────
- [What does "good enough" look like at the end of testing?]
- [e.g. "All P1/P2 stories meet acceptance criteria with no open Sev1/Sev2 defects"]
- [e.g. "Regression suite passes with <2% failure rate"]
─────────────────────────────────────────────
3. TEST APPROACH
─────────────────────────────────────────────
Overall strategy:
[Describe how you will test: exploratory + scripted? risk-based prioritisation?
Manual only, or automation included? Shift-left activities?]
─────────────────────────────────────────────
4. TEST TYPES
─────────────────────────────────────────────
[ ] Functional / acceptance testing
[ ] API / integration testing
[ ] Regression testing
[ ] Security testing
[ ] Accessibility testing (WCAG 2.2 AA)
[ ] Performance / load testing
[ ] Exploratory testing
[ ] User Acceptance Testing (UAT)
[ ] Other: ___________________
─────────────────────────────────────────────
5. ENVIRONMENTS
─────────────────────────────────────────────
Testing env : [e.g. QA / Staging / UAT]
Browser/OS : [e.g. Chrome latest, Safari iOS 17, Edge]
Mobile : [e.g. iPhone 14 / Samsung Galaxy S23]
Third-party : [e.g. IRD sandbox, Stripe test mode]
Not available : [e.g. Production access — use staging only]
─────────────────────────────────────────────
6. TEST DATA REQUIREMENTS
─────────────────────────────────────────────
- [Describe what data is needed and how it will be obtained or generated]
- [e.g. "Synthetic customer accounts — do not use production PII"]
- [e.g. "IRD numbers in 12x format for KiwiSaver scenarios"]
─────────────────────────────────────────────
7. ENTRY CRITERIA
─────────────────────────────────────────────
Testing will not start until:
- [ ] [e.g. Dev build deployed to QA environment]
- [ ] [e.g. Smoke test passes — login and core navigation]
- [ ] [e.g. Test data seeded and verified]
- [ ] [e.g. API mocks / stubs available for third-party dependencies]
─────────────────────────────────────────────
8. EXIT CRITERIA
─────────────────────────────────────────────
Testing is complete when:
- [ ] [e.g. 100% of planned test cases executed]
- [ ] [e.g. All Sev1 and Sev2 defects resolved or deferred with PO sign-off]
- [ ] [e.g. Regression suite passes at agreed threshold]
- [ ] [e.g. Sign-off received from Product Owner]
─────────────────────────────────────────────
9. RISKS & MITIGATIONS
─────────────────────────────────────────────
Risk 1: [describe risk]
Likelihood : Low | Medium | High
Impact : Low | Medium | High
Mitigation : [what will you do to reduce or manage this risk?]
Risk 2: [describe risk]
Likelihood : ...
Impact : ...
Mitigation : ...
─────────────────────────────────────────────
10. SCHEDULE
─────────────────────────────────────────────
Test design : [date range or sprint day]
Test execution : [date range or sprint days]
Defect fix : [expected resolution window]
Sign-off by : [date]
─────────────────────────────────────────────
11. SIGN-OFF
─────────────────────────────────────────────
QA Lead : ________________ Date: ________
Product Owner : ________________ Date: ________
Dev Lead : ________________ Date: ________
[Other] : ________________ Date: ________
4 Field Guide
Every section explained — with NZ examples so you know what good looks like in practice.
1. Scope required
The most important section. "In scope" defines what you are responsible for testing. "Out of scope" is equally critical — it prevents scope creep and makes explicit what risks are being accepted.
Be specific. "The Change Address feature" is too vague. "Address validation for residential NZ addresses using the NZ Post address lookup API (AU addresses out of scope)" is testable.
2. Objectives required
What does passing look like? Frame objectives in terms of what the team will be confident about at the end of testing, not a list of test types you plan to run.
3. Test Approach required
Describe your testing philosophy for this sprint. Are you doing risk-based testing? Exploratory first, then scripted? Automation from day one or manual this sprint with automation to follow? Who tests what?
4. Test Types required
Tick the test types you will actually run. Leave the rest unticked — the point is to be explicit about what is and isn't covered, not to tick everything. Unticked items are out of scope by implication.
5. Environments required
List exactly where testing will happen, including which third-party environments. NZ-specific: many government agency APIs (IRD, MSD, ACC) have separate sandbox environments that must be coordinated separately from the main QA environment.
6. Test Data Requirements required
Describe what data is needed and how it will be created. In NZ, the Privacy Act 2020 prohibits using production customer data in test environments without explicit consent. Use synthetic data or an anonymisation script.
7. Entry Criteria required
The conditions that must be met before testing starts. Not suggestions — blockers. If entry criteria aren't met, testing doesn't start. This protects the team from wasting time testing a broken build.
8. Exit Criteria required
The conditions that must be met before the sprint closes. Usually agreed with the Product Owner at planning. When criteria aren't met, the team makes an explicit decision to defer — not an implicit one to ship anyway.
9. Risks & Mitigations required
List the things that could go wrong and what you will do about them. Three to five risks is typical. Zero risks is a red flag — it means nobody thought about it.
10. Schedule optional
In a fixed two-week sprint the schedule is usually implicit. Make it explicit if: the sprint is longer, there are dependencies on other teams, or a formal UAT window is required (common for insurance, banking, and government projects in NZ).
11. Sign-off optional
Formal sign-off is expected on any feature that affects payments, personal data, or regulated activities (e.g. KiwiSaver, insurance, ACC claims). For vanilla Agile sprints, a Jira comment from the PO is sufficient. Escalate when in doubt.
5 Worked Example — Change Address (Insurance Portal)
A real sprint plan for a "Change Address" feature on an NZ insurance portal. Slightly simplified, but represents what a working plan looks like in practice.
Test Plan — Change Address Feature
Project: InsureNZ Customer Portal | Sprint: 14 | Author: Aroha Tane (QA Lead) | Date: 2026-06-16 | Status: Approved
1. Scope
In scope:
- US-142: Address search via NZ Post AddressRight API
- US-143: Save updated address to customer profile (residential NZ addresses only)
- US-145: Send address change confirmation email via SendGrid
Out of scope:
- PO Box and private bag addresses (deferred Sprint 18)
- Address change for business customers (separate stream)
- Correspondence history audit log (backlog item BE-299)
2. Objectives
- All three user stories meet acceptance criteria with no open Sev1/Sev2 defects at sprint close
- NZ Post API integration handles lookup success, timeout, and invalid address gracefully
- Existing policy renewal correspondence continues to use correct address (regression)
3. Test Approach
Risk-based: the NZ Post API contract (US-142) carries the highest risk — external dependency with a known sandbox availability issue. Scripted API tests cover contract and error handling; exploratory session covers the address picker UI. Regression is automated (Playwright, existing suite). Junior tester owns functional UI; senior owns API layer and regression.
4. Test Types
- Functional acceptance testing (manual)
- API / integration testing — NZ Post AddressRight contract
- Regression — Playwright suite (policy renewal, correspondence module)
- Accessibility — WCAG 2.2 AA check on address picker (screen reader, keyboard nav)
Not this sprint: Performance, security, UAT (no regulatory trigger).
5. Environments
- QA3 (https://qa3.insurenz.co.nz) — stable, refreshed nightly
- Chrome 125 (Windows 11), Safari 17 (iOS 17 — iPhone 14)
- NZ Post AddressRight sandbox (credentials in 1Password vault "QA-Shared")
- SendGrid sandbox mode (emails logged, not delivered)
6. Test Data Requirements
- 15 synthetic customer accounts — run
scripts/seed_qa_customers.py --count 15 - NZ addresses: Auckland (Ponsonby), Wellington (Karori), Christchurch (Ilam), Whanganui, PO Box (should fail)
- IRD numbers in 12x format (e.g. 123-456-789) for KiwiSaver-linked policies
- No production data — Privacy Act 2020 compliance enforced by QA lead
7. Entry Criteria
- Dev build deployed to QA3 and tagged Sprint14-RC1
- NZ Post sandbox credentials valid — confirm with
curltest in QA wiki - Smoke test passes: login → My Account → Change Address form renders without errors
- Synthetic customer data seeded and verified (senior tester spot-checks 5 accounts)
8. Exit Criteria
- 100% of 42 planned test cases executed
- Zero Sev1 defects; any Sev2 defects resolved or explicitly deferred with PO comment in Jira
- Playwright regression suite passes ≥98% (2 known-flaky tests excluded per TEST-992 agreement)
- WCAG 2.2 AA: no critical or serious Axe violations on address picker
- Product Owner (Ben Parata) confirms Sprint 14 ready for release in Jira epic INS-220
9. Risks & Mitigations
- NZ Post sandbox outage (Medium / High) — Occurred Sprint 11. Mitigation: WireMock stub pre-configured in
test/mocks/nzpost/; escalate to delivery lead if outage >4 hrs - Macron encoding in Maori place names (Low / Medium) — Whanganui, Rotorua, Papatoetoe. Mitigation: 2 macron addresses in test set; raise as Sev2 if encoding fails
- Sprint capacity reduced (Low / Low) — Aroha on annual leave Day 8. Mitigation: Regression automated; junior tester completes functional by Day 7
10. Schedule
- Test design: Sprint Day 1–2 (alongside dev)
- Test execution: Sprint Day 7–9
- Defect fix window: Sprint Day 9–11
- Sign-off: Sprint Day 12 (Sprint Review day)
11. Sign-off
- QA Lead: Aroha Tane — 2026-06-27
- Product Owner: Ben Parata — pending
6 One-Page Agile Adaptation
For fast-moving Agile teams, a full 11-section document can feel heavy. This condensed table format covers the essential decisions in a single Confluence table or Jira description field. Trade completeness for adoption — a one-pager the team actually reads beats a full plan nobody opens.
| Field | Fill in |
|---|---|
| Sprint / Feature | [name] |
| In scope | [user story IDs or feature names] |
| Out of scope | [explicitly excluded items] |
| Test types | [e.g. Functional, API, Regression, A11y] |
| NOT testing | [e.g. Performance, Security — no new attack surface] |
| Environment | [QA env URL + third-party sandboxes] |
| Test data | [how data will be created; confirm no prod PII] |
| Start condition | [single blocker: "Build deployed to QA + smoke passes"] |
| Done condition | [single condition: "All ACs met, zero Sev1/2 open, PO sign-off"] |
| Top risk | [one sentence: what could go wrong + what you'll do] |
| Who owns testing | [name(s) and responsibilities] |
Definition of Done connection: Your exit criteria should mirror the team's Definition of Done. If the DoD says "all acceptance criteria verified by QA", your exit criteria are the specific checks that fulfil that. Keeping them aligned means the test plan and the DoD tell the same story. See the Definition of Done technique for how to write one.
7 Copy-Paste Block
Plain-text version ready to paste into Confluence, Notion, or a Markdown file. Click Copy to grab it.
# TEST PLAN
Project / Feature :
Version : v1.0
Author :
Date :
Reviewers :
Status : Draft
## 1. SCOPE
In scope:
-
Out of scope:
-
## 2. OBJECTIVES
- All [feature] user stories meet acceptance criteria
- No Sev1/Sev2 defects open at sprint close
-
## 3. TEST APPROACH
## 4. TEST TYPES
[ ] Functional / acceptance testing
[ ] API / integration testing
[ ] Regression testing
[ ] Security testing
[ ] Accessibility testing (WCAG 2.2 AA)
[ ] Performance / load testing
[ ] Exploratory testing
[ ] UAT
[ ] Other:
## 5. ENVIRONMENTS
Testing env :
Browser/OS :
Mobile :
Third-party :
Not available :
## 6. TEST DATA REQUIREMENTS
-
- No production PII (Privacy Act 2020 compliance)
## 7. ENTRY CRITERIA
Testing will not start until:
- [ ] Build deployed to test environment
- [ ] Smoke test passes (login + core navigation)
- [ ] Test data seeded and verified
- [ ]
## 8. EXIT CRITERIA
Testing is complete when:
- [ ] 100% of planned test cases executed
- [ ] All Sev1/Sev2 defects resolved or deferred with PO approval
- [ ]
- [ ] Product Owner sign-off received
## 9. RISKS & MITIGATIONS
Risk 1:
Likelihood :
Impact :
Mitigation :
Risk 2:
Likelihood :
Impact :
Mitigation :
## 10. SCHEDULE
Test design :
Test execution :
Defect fix :
Sign-off by :
## 11. SIGN-OFF
QA Lead : Date:
Product Owner : Date:
Dev Lead : Date:
Storage tip: Store test plans alongside the sprint artifacts, not in a separate test management folder. When a plan lives next to the sprint board, teams are more likely to update it during the sprint — and it becomes a useful retrospective artifact showing what was planned vs what actually happened.
Self-Check
Click each question to reveal the answer.
Q1: What is the key difference between a test strategy and a test plan?
A test strategy is programme-wide or organisation-wide, defining the overall testing philosophy and standards across all projects. A test plan is specific to a single sprint, release, or feature, describing exactly what will be tested, how, by whom, and when for that delivery. One is a standing document; the other is created per delivery cycle.
Q2: Why is "Out of scope" as important as "In scope"?
Out of scope makes explicit what risks the team is accepting by not testing something. Without it, stakeholders assume everything is tested, which can lead to blame when an untested area breaks. Writing "PO Box addresses — deferred to Sprint 18" creates a shared record of a deliberate decision, not a gap discovered in production.
Q3: Why does the template require NZ-specific test data guidance (IRD numbers, no production PII)?
The NZ Privacy Act 2020 requires that personal data not be used without purpose, and using production customer data in a test environment — where security controls may be weaker — creates real privacy risk. Synthetic data seeded to specific NZ formats (e.g. IRD numbers in 12x format) provides realistic tests without exposing customers. Auditors and regulators may ask to see evidence that test data was handled appropriately.
Q4: What is the purpose of entry criteria, and what happens if they are not met?
Entry criteria are the preconditions that must be true before testing begins. If they are not met, testing should not start — testing a broken or incomplete build wastes QA time, generates noise defects, and obscures real issues. The entry criteria in the plan give the QA lead a formal basis to pause testing and escalate rather than silently continue on a failing build.
Q5: When should you write a full 11-section test plan vs a one-page agile adaptation?
Use the full plan when: the feature touches payments, authentication, personal data, or regulated activities (insurance, KiwiSaver, government API integrations); a compliance audit may ask for documented test evidence; or formal sign-off from a compliance, legal, or external stakeholder is required. Use the one-pager for standard Agile sprints where the risks are low and the team is experienced together. The one-pager builds a habit; the full plan creates an audit trail.