Test Policy & Strategy
Stepping up from Lead to Manager. Defining the organisational quality North Star and securing executive buy-in.
1 The Hook
A fast-growing NZ SaaS company had 5 agile squads. When a major production outage occurred, the CTO asked the Test Lead, "How did this happen?" The Lead replied, "My squad didn't test that API, we assumed Squad B did it."
A Test Lead tries to test harder within their silo. A Test Manager fixes the system across all silos. Because the company lacked a unified Test Policy and Test Strategy, they had no common language for risk, boundaries, or standards. A Manager without these documents is just a busy person in a chaotic room.
2 The Mindset Shift: Lead vs. Manager
To succeed as a Test Manager, you must stop thinking about execution and start thinking about governance and scaling.
⚔️ The Test Lead (Tactical)
- Focus: "How do we test this specific feature in Sprint 12?"
- Output: Test Plans, Test Cases, Defect Reports.
- Scope: Single project or single agile squad.
- Success: Finding bugs before release.
🏛️ The Test Manager (Strategic)
- Focus: "How does our entire organization define, measure, and achieve quality?"
- Output: Test Policies, Test Strategies, ROI Models, Capability Roadmaps.
- Scope: Portfolio level (all squads, all projects).
- Success: Preventing defects through process improvement and risk management.
3 The Rule
The Policy is the Constitution. The Strategy is the Playbook. The Plan is the Game.
You cannot build a strategy without a policy, and you cannot write a plan without a strategy. They must cascade from the Boardroom to the Jira ticket.
Senior engineer insight
The day I stopped writing strategy documents and started writing strategy conversations was the day our quality programmes actually landed. I had spent three weeks crafting a 40-page Test Strategy for a Wellington health-tech firm — well-structured, ISO/IEC 29119-compliant, the lot — and it died in a drawer because no Dev Manager felt ownership of it. The shift was treating the document as a record of decisions already made in the room, not a decree handed down from QA.
The most common mistake Test Managers make here is writing a policy that reflects their personal quality beliefs rather than the organisation's actual risk appetite and commercial constraints.
From the field
On an TransitNZ digital services programme, the team assumed a single Test Strategy inherited from a previous agency contract would cover a new microservices rebuild — different architecture, different risk profile, same document. Six months in, three squads were operating to completely different defect severity classifications: what Squad A called a P2 blocker, Squad C was releasing as a known issue. When the programme went through a TMMi Level 2 assessment, the absence of a living, version-controlled strategy document was the single biggest finding. The organisation had to retrofit alignment across eight backlogs mid-flight, which cost more than writing it right at discovery would have. The lesson that generalises: a Test Strategy has an expiry date tied to your architecture's rate of change — treat it like code, not like policy wallpaper.
4 Anatomy of the Documents
A Test Manager doesn't just write these documents; they negotiate them with the business. Here is what they actually contain:
The Test Policy (The "What" and "Why")
A short, high-level document signed off by the Executive team (CTO/CIO). It answers: What does quality mean to us?
- Objectives: Are we prioritizing speed-to-market (startup) or zero-defects (banking)?
- Responsibility: Is quality owned only by QA, or is it a shared engineering responsibility?
- Compliance: Strict rules (e.g., "No PII in test environments").
The Test Strategy (The "How")
A portfolio-level document detailing how the Policy will be executed across all projects.
- Test Levels & Types: Mandating Unit Testing (Devs), API Testing (SDETs), and Exploratory (QAs).
- Environment & Data: How environments are provisioned and how synthetic data is generated.
- Automation Approach: The target ratio of automated vs. manual testing and the approved tech stack (e.g., Playwright + TypeScript).
- Defect Management: The standardized workflow for triage and severity mapping.
5 Watch Me Do It: The Hierarchy in Action
Observe how a Test Manager builds a quality framework that aligns the CTO's desires with the Developer's daily work.
Step 1: The Test Policy (Board Level)
The CTO signs this.
"We prioritize data security and user trust above speed-to-market. Quality is a shared engineering responsibility. No code reaches production without automated verification."
Step 2: The Test Strategy (Portfolio Level)
The Test Manager enforces this across all Dev Managers.
"All microservices must maintain 80% unit test coverage via SonarQube. The core checkout API must be covered by automated Playwright tests running in the CI/CD pipeline on every pull request."
Step 3: The Test Plan (Squad Level)
The Test Lead executes this for Sprint 24.
"For Sprint 24's new payment gateway feature, Sarah will write 15 API automated tests, and John will spend 4 hours doing manual exploratory testing on mobile devices."
6 Strategy Lab: Draft the North Star
In this lab, you must step into the Test Manager role and create a one-sentence **Test Policy** for a fictional Fintech that is currently suffering from chaotic releases.
Your Task: The Executive Buy-in
The CEO is angry about production hotfixes. The Devs are angry about QA slowing them down. You need a policy that establishes boundaries.
CONSIDER THESE COMPETING VALUES:
- Risk Tolerance: Is this a banking app (Zero tolerance) or a social media app (High tolerance)?
- Velocity vs. Stability: Does testing happen after dev (slower, safer) or during dev (shift-left)?
- Ownership: Is quality the "Tester's problem" or a "Shared team responsibility"?
Draft your Policy statement. It must be under 30 words and speak to the "Why."
Example of a bad policy: "We will test all Jira tickets."
Example of a good policy: "We protect customer financial data through mandatory, automated shift-left testing owned by the entire engineering team."
7 Common Mistakes
⚠ Writing it in a Vacuum
Why it fails: A Test Manager who writes a 50-page strategy alone in their office will find that no one follows it. A strategy must be negotiated with Dev Managers and Product Owners to ensure buy-in. It is a social contract, not just a document.
⚠ Mistaking "Automation" for "Strategy"
Why it fails: Automation is a tool, not a strategy. If your strategy just says "We will automate everything using Cypress," you have failed. Your strategy must dictate **how** you manage risk, environments, and people.
Why teams fail here
- The Test Policy is written once at programme kick-off and never touched again — by the time the product pivots, the policy no longer reflects the actual risk appetite the business is operating under.
- Strategy is scoped to a single project rather than the portfolio, so every new project reinvents tooling, severity scales, and environment conventions from scratch.
- The documents skip executive sign-off to save time — without a named CTO or CIO endorsement, the strategy has no authority to override the conflicting preferences of individual Dev Managers.
- TMMi or ISO/IEC 29119 compliance is treated as the goal rather than a by-product — teams produce audit-ready artefacts that look right on paper but are disconnected from how squads actually make testing decisions day-to-day.
Key takeaway
A Test Policy sets the organisation's quality contract with its stakeholders; a Test Strategy is how you keep it — and neither document does anything until the people who have to live by it have had a hand in writing it.
8 Self-Check
Q1. A Test Lead asks you (the Manager) to review their Test Plan for a new feature. They haven't referenced the Test Strategy. Why is this a problem?
Without referencing the Strategy, the Lead might choose an approach (e.g., 100% manual testing) that violates the organisational standard (e.g., mandatory automated regression). The Strategy ensures consistency across all squads.
Q2. Who is the primary audience for a Test Policy?
The Executive Stakeholders (CTO, Board, CEO). It defines the quality values and risk appetite they are willing to pay for.