Test Manager ISO/IEC 29119

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.

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.

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.