---
title: "Test strategy and planning | Skills We Assign For | Azendo"
description: "Test strategy and planning — deciding what to verify and where, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/test-strategy-and-planning/"
---

[Skills](https://azendo.co/skills/) Testing practice 

# Test strategy and planning.

Test strategy defines what gets tested, at which level, by whom, and what has to be true to release. It is the decision layer above tooling: the same frameworks produce very different results depending on the strategy directing them.

## Where Test strategy and planning fits on a long engagement.

Most testing problems are strategy problems wearing a tooling costume. A slow pipeline is usually too much coverage at the end-to-end level; poor defect detection is usually coverage at the wrong layer; a distrusted suite is usually the absence of an owner. Changing framework fixes none of these.

The decisions that matter are unglamorous: which layer verifies what, what gates a release, what is deliberately not tested, and who decides when those conflict. Written down, they make testing reviewable. Left implicit, every release becomes a negotiation conducted under time pressure.

## What an assigned team does with Test strategy and planning.

A strategy is only real if it survives a deadline. The test of it is what happens when a release is at risk — whether the stated gates hold or quietly become advisory — and that is decided by whether the reasoning behind them is understood or merely documented.

Direction and acceptance stay with you; what we answer for is that the assigned specialists hold the strategy consistently and tell you plainly when a gate has not been met. That division is the core of a [dedicated development team](https://azendo.co/services/dedicated-development-team/).

## What we use Test strategy and planning for.

* Coverage at the right layer Moving verification down the pyramid, which usually fixes both pipeline speed and detection rate.
* Release gates that are explicit Stated conditions for shipping, so the decision is not renegotiated under pressure each time.
* Scope that is deliberately bounded A written account of what is not tested, so the risk is accepted rather than unnoticed.

## How Test strategy and planning capacity is assigned.

Test strategy is assigned under [outsource qa testing](https://azendo.co/services/qa-engineering-and-test-automation/) as standing capacity, because a strategy nobody maintains stops describing the system within months.

## Roles we assign Test strategy and planning for

* [QA Engineer QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/qa-engineer/)

## Service lines it sits in

* [QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in testing practice

* [cross-device testing — skill we assign for](https://azendo.co/skills/cross-device-testing/)
* [exploratory testing — skill we assign for](https://azendo.co/skills/exploratory-testing/)
* [risk-based testing — skill we assign for](https://azendo.co/skills/risk-based-testing/)
* [acceptance criteria validation — skill we assign for](https://azendo.co/skills/acceptance-criteria-validation/)
* [bug reporting with reproduction steps — skill we assign for](https://azendo.co/skills/bug-reporting-with-reproduction-steps/)

## Tell us what your roadmap needs Test strategy and planning for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)