Test Strategy Template
A test strategy is the programme-level document that defines how testing works across all phases of a delivery. It is distinct from a test plan (which is release-specific). NZ government projects, especially those under DIA or GCDO procurement, require a formal strategy artefact before procurement gates close. This template gives you the complete structure, field guidance, a worked example, and a copy-paste block.
On this page
1 Strategy vs Plan
These two terms are used interchangeably in the wild — and that confusion costs projects time and money when a procurement reviewer rejects a test plan submitted as a strategy. Understand the distinction before writing either.
| Dimension | Test Strategy | Test Plan |
|---|---|---|
| Scope | Programme or product lifecycle — covers all releases and phases | One release, sprint cycle, or project phase |
| Audience | Steering group, client QA owner, procurement reviewers, audit | Test team, delivery manager, product owner |
| Authored by | Test Lead / QA Manager / Head of QA | Test Analyst / Test Lead |
| Change cadence | Updated at major programme milestones or when approach changes | Updated each sprint, release cycle, or when scope changes |
| Key content | Quality objectives, test levels, test types per level, environments, tooling, RACI, risk appetite, sign-off authority | In/out scope, approach for this release, schedule, resources, entry/exit criteria, defect status |
| ISTQB reference | CTAL-TM Ch. 2; ISO/IEC 29119-3 organisational test strategy | CTFL 5.1; ISO/IEC 29119-3 project test plan |
The strategy is the building code. The plan is the specific consent application.
New Zealand's Building Code sets the standards every building must meet — earthquake resistance, weathertightness, fire egress. A building consent then says "this specific house at this address will meet those standards in this way." The strategy sets the standards and approach for testing across the whole programme. Each test plan is the specific consent for a particular release — it describes how the strategy applies to this deliverable. You submit the consent, not the building code, to the council — just as you submit the test plan to sprint planning. But the procurement reviewer wants the code, not just one consent.
2 NZ Context — Government Projects
New Zealand government technology projects operate under two overlapping procurement and quality frameworks that directly affect what your strategy document must contain.
Department of Internal Affairs (DIA) — ICT Assurance: The DIA runs independent quality assurance reviews on government ICT investments above the mandatory assurance thresholds. Projects at the Enhanced or Intensive assurance tiers must provide a quality management plan and a test strategy as part of gateway review documentation. A test strategy submitted without a RACI, an environments section, or defined exit criteria per level will be flagged at review and can hold up gateway approval.
Government Chief Digital Officer (GCDO) — AoG Standards: The GCDO's All-of-Government (AoG) digital and ICT standards require that government agencies demonstrate how privacy, accessibility (WCAG 2.2 AA), and security obligations are addressed in their quality approach. Your strategy must explicitly reference these in the Test Types section and the Test Data Strategy section (Privacy Act 2020 compliance for test data handling).
Privacy Act 2020 — Test Data: Using production data in test environments without appropriate controls is a Privacy Act 2020 breach risk. Your strategy must describe how personal information is handled in testing — anonymisation, synthetic data generation, data retention limits, and access controls. This is not optional for any project handling personal information.
Even if your project is not subject to formal gateway reviews, following this structure signals professional maturity and builds stakeholder confidence. Many NZ government agencies now include "has a test strategy been produced?" as a standard milestone gate in their internal project governance.
3 Template — 16 Sections
Each section header is followed by a brief prompt in brackets explaining what to put there. Complete all 16 sections for a full strategy; note which are mandatory for DIA/GCDO review with GOV.
4 Field Guide for Key Sections
The sections most commonly written poorly — and what to actually put in them.
Quality Objectives
Quality objectives are not aspirations ("we aim to deliver quality software"). They are measurable targets that can be objectively verified at programme end. Each objective needs a metric, a target value, and an owner. A common failure is writing objectives you cannot measure: "we will deliver a high-quality system" tells a DIA reviewer nothing. "Zero P1 defects at system test exit for all components" is auditable.
Test Data Strategy — Privacy Act 2020
This section trips up most NZ government project teams because they treat it as a compliance checkbox rather than a live risk. The Privacy Act 2020 requires that personal information is only collected and used for the purpose it was collected for. Using a patient's real health record in a test environment to test a new UI feature is a breach — even if the data never leaves the organisation.
Your strategy must name the anonymisation method, the tool or script used, who is responsible for verifying anonymisation before test execution, and what the retention period is for non-production data. For health, justice, and welfare sector projects, name the specific categories of personal information covered (e.g. health information under Part 1 of the Privacy Act, or information about children).
RACI
The most common RACI failure: too many Rs. If six people are responsible for a single activity, nobody is actually responsible. Each row should have exactly one A (accountable) — the person who signs off. R (responsible) can be shared but should be as narrow as practical. The RACI is most useful when it surfaces the activities where nobody has claimed accountability — those are your programme risk items.
Entry & Exit Criteria Per Level
The default failure mode is writing vague criteria ("environment is ready", "tests pass") that cannot be objectively verified. Entry criteria must name the specific conditions that must be true before work starts — concrete enough that a third party could check them without asking you. Exit criteria must include numeric thresholds, not just "all tests passing."
For DIA gateway reviews, the criteria are examined carefully because they define when phases are complete and when money can be spent on the next phase. Vague criteria are a red flag that the team has not thought through what "done" means.
Risk Register Summary
The strategy risk register covers testing risks, not project risks. Confusing these is common. A project risk is "the vendor may not deliver the API on time." The corresponding testing risk is "if the API is not available in SIT, integration tests cannot execute, and we may reach UAT with untested integration points." Frame each risk from the testing perspective, describe its impact on testing coverage or quality, and give a concrete mitigation.
Sign-off Matrix
The sign-off block is where the strategy becomes a contract. Named individuals are committing to the quality objectives and approach. An unsigned strategy is a draft, not an approved framework. For DIA gateway reviews, the strategy must be approved before the review gate — a draft submitted at review is unlikely to satisfy the assurance requirement.
5 Worked Example — Health NZ Patient Portal Modernisation
A skeleton strategy showing how each section looks for a real NZ government programme. This is an illustrative skeleton, not a complete document — each section shows the kind of content, not an exhaustive fill-in.
1. Document Control
Document ID: TS-HNZ-PP-2025-001 · Status: Approved · Owner: QA Lead, Digital Services · Approved by: Director of Digital Transformation (Health NZ) and ICT Assurance Lead (DIA)
2. Executive Summary
Health NZ is replacing the legacy patient portal with a modern, accessible platform serving approximately 1.2 million registered patients across Te Whatu Ora districts. The programme carries significant risk: health information is among the most sensitive personal data under the Privacy Act 2020, and portal downtime directly affects patient access to prescriptions, appointments, and test results. The test strategy adopts a risk-based, shift-left approach with mandatory WCAG 2.2 AA accessibility testing and Privacy Act-compliant test data controls. Given the programme's ICT Assurance tier (Intensive), this strategy is submitted as a gateway deliverable.
3. Quality Objectives
- QO1: Zero P1 defects at system test exit; all P2 defects resolved or formally risk-accepted before UAT entry.
- QO2: WCAG 2.2 Level AA compliance verified for all public-facing pages before production release.
- QO3: All test environments handling any patient health information use anonymised or synthetic data only — verified before each test phase entry.
- QO4: Portal response time under load (500 concurrent users) ≤ 2 seconds for the appointment booking flow.
- QO5: ≥ 95% of OWASP Top 10 controls verified before each production deployment.
4. Scope & Boundaries
In scope: Patient authentication (MFA), appointment booking and cancellation, prescription request and status tracking, test result viewing, GP messaging, accessibility layer, Health NZ identity federation integration, HISO 10029 health identity standard compliance.
Out of scope (accepted by programme director): Legacy portal decommissioning (separate workstream), GP-side portal administration (Phase 2), mobile native apps (Phase 3), iwi health provider integrations (separate procurement).
8. Test Data Strategy — Privacy Act 2020
All test data handling complies with the Privacy Act 2020 and the Health Information Privacy Code 2020. Production patient data is strictly prohibited in all non-production environments. Anonymisation is performed using execution/anonymise_patient_data.py, which replaces NHI numbers with synthetic equivalents, replaces names with generated names, and removes birth dates, replacing them with age-band values. Anonymised data is retained in non-production environments for no more than 60 days. Access to the SIT and UAT environments is restricted to named project team members via MFA-protected VPN. Any data handling incident during testing is reported to the Health NZ Privacy Officer within 72 hours.
13. Entry & Exit Criteria — System Testing
Entry: Build deployed to SIT and smoke test suite passing; patient account test data seeded using anonymisation tool (verified by QA lead); all P1/P2 defects from integration testing resolved; WCAG axe-core scan integrated in CI with zero critical violations; test cases reviewed and approved by BA lead.
Exit: 100% of planned test cases executed; ≥ 95% pass rate overall, 100% of critical-path journeys (login → book appointment → confirm); 0 P1 defects open; P2 defects resolved or risk-accepted in writing; ≥ 98% of acceptance criteria covered by at least one passing test; WCAG 2.2 AA automated scan clean; security scan no high/critical findings; regression suite green; QA Lead sign-off.
Suspension: A P1 defect that blocks ≥ 25% of planned test cases triggers a test pause. Testing resumes only when the defect is resolved and verified, and the environment is confirmed stable.
14. Top Testing Risks
- TR-01 (Score 20): Health identity federation (WSO2) may not be available in SIT — mitigate with WireMock stubs and contract testing against federation API spec.
- TR-02 (Score 16): WCAG compliance may require significant remediation late in programme — mitigate with axe-core in CI from sprint 1; mandatory a11y review at each sprint demo.
- TR-03 (Score 15): Patient data anonymisation gaps in edge cases — mitigate with anonymisation script unit tests; QA lead verification before each environment refresh.
6 DIA/GCDO Reviewer Checklist
When a DIA ICT Assurance reviewer or a GCDO standards assessor reviews a test strategy, these are the questions they are asking. Use this as a pre-submission checklist before your strategy goes to a gateway review.
Document Basics
- Document control section with version, status, author, approver
- Revision history showing how the document has evolved
- Named distribution list
- Sign-off block with named individuals and dates
- Status is "Approved" (not "Draft" or "In Review")
Quality & Objectives
- Quality objectives are measurable (not aspirational)
- Each objective has a target value and a verification method
- Scope section lists explicit out-of-scope items
- Scope decisions are attributed to an approving stakeholder
- Assumptions and dependencies are listed
Privacy & Compliance
- Test data strategy explicitly addresses Privacy Act 2020
- Anonymisation method is named (not just "data will be anonymised")
- Retention period for non-production data is stated
- WCAG 2.2 AA accessibility testing is in the test types section
- Security testing references OWASP or NZ NCSC guidelines
Governance & Oversight
- RACI is present with single accountable owner per activity
- Entry and exit criteria are defined per test level
- Exit criteria include numeric thresholds (not "tests pass")
- Reporting cadence includes a steering group deliverable
- Risk register summary with mitigations and owners
Gateway review timing: DIA ICT Assurance gateway reviews typically occur at business case approval, design completion, and release readiness. The test strategy must be available and approved at the design gate — not just started. Teams that arrive at a gateway review with a draft strategy routinely receive a "not satisfied" finding on quality assurance, which delays gate passage.
7 Copy-Paste Block
A compact version of the complete strategy structure for pasting into Confluence, Word, or Google Docs. Replace all [bracketed] placeholders with project-specific content.
# [PROGRAMME NAME] TEST STRATEGY
Document ID: [TS-YYYY-NNN] | Version: [X.X] | Status: [Draft/Approved] | Date: [YYYY-MM-DD]
Author: [Name, Role] | Owner: [Test Lead] | Approved by: [Names]
---
## 1. DOCUMENT CONTROL
Version | Date | Author | Changes
[Fill revision history]
## 2. EXECUTIVE SUMMARY
[2-3 paragraphs: what is being delivered, testing approach/philosophy, key quality risks and response]
## 3. QUALITY OBJECTIVES
- QO1: [Measurable objective with target metric]
- QO2: [Measurable objective with target metric]
- QO3: All personal data anonymised/synthetic before test execution (Privacy Act 2020)
- QO4: WCAG 2.2 AA compliance verified for all public-facing interfaces
- QO5: [Add further objectives as required]
## 4. SCOPE & BOUNDARIES
In scope: [Systems, components, integrations, user journeys]
Out of scope: [Explicitly excluded items — accepted by: Name, Role, Date]
Assumptions: [What must be true for strategy to be viable]
Constraints: [Budget, timeline, resource, tooling constraints]
## 5. TEST LEVELS
| Level | Owner | Timing | Tooling |
| Unit/Component | Dev team | On commit | [Tool] |
| Integration | Dev + QA | On PR merge | [Tool] |
| System | QA team | Per sprint | [Tool] |
| Performance | QA + DevOps | Per release | [Tool] |
| UAT | Business + QA| Pre-release gate | Manual |
| OAT | DevOps + QA | Pre-prod deploy | Runbook |
## 6. TEST TYPES PER LEVEL
Functional: [Where, approach, coverage target]
Regression: [Where, automated suite, coverage target, trigger]
Performance: [Where, baseline/soak/spike, SLA thresholds]
Security: [Where, OWASP Top 10, SAST/DAST, pen test schedule]
Accessibility: [Where, WCAG 2.2 AA, tools, manual checks]
Usability: [Where, moderated sessions, participant plan]
Compatibility: [Where, browser/device matrix]
Exploratory: [Where, time-boxed charters, charter log]
## 7. TEST ENVIRONMENTS
| Env | Purpose | Owner | Refresh | Data Classification |
| DEV | Unit/smoke | Dev | Continuous | Synthetic only |
| TEST/SIT | System test | QA | Per sprint | Anonymised |
| UAT | User accept | QA + BA | Per release | Anonymised |
| PERF | Load test | QA+DevOps| On demand | Synthetic/cloned |
| PROD-MIRROR| Pre-prod OAT | DevOps | Per deploy | No personal data |
## 8. TEST DATA STRATEGY (Privacy Act 2020)
Personal data categories handled: [List types]
Controls:
- Production personal data NOT used in DEV/TEST/UAT environments
- Anonymisation method: [Tool/script name]
- Synthetic data used for: [Scenarios]
- Retention in non-production: [X days]
- Access restricted to: [Named team members via MFA]
- Privacy incident process: [Link]
## 9. DEFECT MANAGEMENT
Tool: [Jira/Azure DevOps — link to board]
Severity:
P1 Blocker: system unusable/data loss — fix same day
P2 Critical: major function broken, no workaround — fix within 2 days
P3 Major: significant issue, workaround exists — fix current sprint
P4 Minor: cosmetic — backlog
Release criteria: P1=0 open | P2=0 open OR risk-accepted in writing | P3=reviewed
## 10. METRICS & REPORTING
Key metrics:
- Test execution rate: 100% by exit gate
- Test pass rate: >=95% (100% critical path)
- Defect detection efficiency: >90% found pre-UAT
- Automation coverage: >=80% regression suite
- Requirements coverage: >=98% at system exit
Reporting: Weekly test status (delivery manager) | Fortnightly defect dashboard (steering) |
Per-release readiness report (release authority) | Monthly QA summary (client/audit)
## 11. TOOLING
Test management: [Tool]
Automation: [Tool]
API testing: [Tool]
Defect tracking: [Tool]
Performance: [Tool]
Accessibility: [Tool]
Test data: [Tool]
## 12. RACI
Activity | Test Lead | QA Analyst | Dev Lead | PO | Del Mgr | Client QA
Test strategy authorship | R/A | C | C | I | I | A
Test plan per release | A | R | C | C | I | I
Test case design | A | R | C | C | I | I
Environment setup | C | C | R/A | I | I | I
Test data management | A | R | C | I | I | I
Defect triage | A | R | R | C | I | I
Release readiness sign-off | R | C | C | A | A | C
UAT facilitation | C | C | I | R/A| I | A
Programme QA reporting | R | C | I | I | A | A
## 13. ENTRY & EXIT CRITERIA PER LEVEL
### Unit Testing
Entry: code merged; build passes; linting clean
Exit: pass rate >=95%; coverage >=agreed threshold
### Integration Testing
Entry: feature merged to integration branch; stubs/services available; test suite updated
Exit: all integration tests passing; no P1/P2 open; contract tests green
### System Testing
Entry: build deployed to SIT; smoke passing; test data seeded (anonymised); test cases approved
Exit: 100% executed; >=95% pass (100% critical); 0 P1; P2 resolved/risk-accepted;
>=98% AC covered; regression green; test lead sign-off
Suspension: P1 blocking >=25% of test cases — pause until resolved
### Performance Testing
Entry: stable SIT build; scripts reviewed; perf environment with representative data
Exit: SLA thresholds met at target load; error rate <0.5%; no memory leaks; perf lead sign-off
### UAT
Entry: system test exit signed off; UAT environment refreshed; participants briefed
Exit: all scenarios executed; 0 P1/P2 open; business owner sign-off in writing
### OAT
Entry: UAT exit signed off; runbooks reviewed; deployment scripts validated
Exit: deployment and rollback validated; ops team sign-off; release authority approval
## 14. RISK REGISTER SUMMARY
| Risk ID | Risk Description | L | I | Score | Mitigation | Owner |
| TR-01 | Environment instability delays execution | 3 | 4 | 12 | SLA agreed; parallel stub track | Test Lead|
| TR-02 | Late/incomplete requirements | 4 | 4 | 16 | Risk log; high-risk ACs prioritised| PO |
| TR-03 | Privacy Act breach via test data | 2 | 5 | 10 | Anonymisation enforced; access ctrl| Test Lead|
| TR-04 | Third-party API unavailable in SIT | 3 | 3 | 9 | WireMock stubs; contract tests | Dev Lead |
| TR-05 | Key QA resource unavailable | 2 | 4 | 8 | Cross-training; runbooks current | QA Mgr |
## 15. SIGN-OFF MATRIX
Role | Name | Signature | Date
Test Lead / QA Manager | | |
Delivery Manager | | |
Product Owner | | |
Client QA Representative| | |
---
End of [PROGRAMME NAME] Test Strategy v[X.X]
Related templates: Pair this strategy with a Test Plan template for release-level planning, a Test Case template for individual test coverage, and a Defect Report template for defect lifecycle management.