QA
Lead / ArchitectStrategy & ArchitectureFree question

How do you create a test strategy for a product or organisation?

60-second answer

A test strategy describes how we achieve quality across the organisation, not for one release. I start with business goals, risk appetite and compliance needs, then map the product architecture and delivery model. I define quality objectives and measurable targets, such as escaped defect rate, lead time and reliability. I set the testing approach per level: ownership of unit, component, contract, API, UI, performance, security, accessibility and production monitoring; the tooling and environments; data and privacy rules; quality gates in the pipeline; metrics and reporting; and roles and skills. Then I make it a living document reviewed quarterly with results.

Explanation

Sections of a strategy document:

  1. Context and goals (business, regulatory, user expectations).
  2. Quality principles (whole-team ownership, shift-left and shift-right, risk-based).
  3. Test levels and ownership (the pyramid for this organisation).
  4. Non-functional strategy (performance, security, accessibility, resilience).
  5. Environments, data, tooling and infrastructure.
  6. Pipeline quality gates and release criteria.
  7. Metrics and feedback loops.
  8. Skills, roles and enablement.
  9. Roadmap and risks.

Key senior skill: tailoring it to the context (startup vs bank) and getting buy-in from engineering and product leaders.

Example

For a payments company: contract tests mandatory for every service, performance budgets in CI, quarterly chaos game days, PCI-driven security scans, and a "no escaped P1 for two releases" target that gated expansion to new markets.

Sample code

Goal       : Release daily with < 2 escaped P1/P2 per quarter
Ownership  : Devs: unit+component+contract | SDETs: API/E2E/perf/platform | Everyone: exploratory
Gates      : PR: unit+lint+API smoke < 10 min | Main: regression + perf check | Release: can-i-deploy + security scan
NFRs       : p95 < 800 ms, 99.9% availability, WCAG 2.1 AA, OWASP ASVS L2
Metrics    : escaped defects, flaky rate, lead time, MTTR, suite duration
Review     : quarterly with engineering leads