Defining a DevOps Test Strategy
This domain tests whether you can define an organisation-level test strategy that aligns testing with DevOps goals, rather than writing a test plan or copying a template.
Core rules and concepts
- Strategy versus plan: a test strategy is long-lived and organisation-wide; it states principles, approach, scope, governance and how testing supports business and DevOps objectives. A test plan applies the strategy to a specific release or project.
- Strategy components: context and goals; scope and risks; test levels and types; shift-left and shift-right approach; automation and tooling; environments and test data; quality gates and metrics; roles and skills; governance and compliance; roadmap and improvement measures.
- Align with the value stream: reduce feedback time, increase release confidence, and make risk visible. Define how testing enables faster delivery rather than slowing it.
- Tailor to context: regulated industries need auditability, evidence and segregation of duties; startups may prioritise speed and experimentation. A strategy that ignores context fails.
- Make it actionable: a roadmap, pilots, adoption measures and executive sponsorship.
- Measure outcomes: feedback time, defect leakage, automation stability, release frequency and mean time to restore.
Worked example
A bank adopts DevOps. Its test strategy sets risk-based testing with mandatory evidence for high-risk changes, an automation pyramid with contract testing for services, test data masking for privacy, pipeline quality gates mapped to regulatory controls, exploratory testing for business rules, and production verification through canaries and synthetic checks. Reasoning: the strategy keeps the speed benefits of continuous testing while satisfying auditability. Copying a lightweight startup strategy would fail compliance; copying a traditional waterfall strategy would fail delivery speed.
Traps that cost marks
- Presenting a project test plan as an organisational strategy.
- Copying a template without tailoring to risk, regulation and technology.
- Writing the strategy as a document with no roadmap, ownership or measures.
- Ignoring culture, skills and executive sponsorship.
- Focusing only on tools and automation while omitting environments, data and governance.
- Treating the strategy as a one-off project rather than a living guide.