A testing strategy in an agile project is the written decision about what gets checked, when and at which level, before a change reaches production. What is changing is not that definition but the ownership of the suite: it is maintained by the whole team alongside the code, not by a phase before release. That shift has no single date.
Quick Overview
What you’ll learn:
- What a testing strategy must settle in order to decide anything at all
- How to spread test levels and types without duplicating the same coverage
- What shifting testing left means once you write it down
- Why test data management decides whether any of it survives
Who this article is for:
- Team leads and test managers organising testing inside iterative delivery
- Testers moving from a phase model into a product team
- Delivery managers accountable for quality rather than for executed test cases
Reading time: 7 minutes
What a Testing Strategy Actually Settles
A strategy answers the questions that cannot be re-argued on every change: which test levels are mandatory, what blocks a release, who owns a risk decision, and which data the tests run against. That is what separates it from a test plan, which is temporary and covers one scope or release. A document that instead lists tools and environment names is neither — it is an inventory.
The first ruling is the mandatory scope. In an agile team the natural home for it is the definition of done: a change is ready when it carries unit tests, passes integration tests and has its main user flow checked. Everything beyond that is a risk decision, taken deliberately and with a name attached, rather than by omission.
The second ruling is language. The Foundation Level certification described on istqb.org organises testing terminology: test levels — component, component integration, system, system integration and acceptance testing — and test types (functional, non-functional, black-box and white-box), with change-related testing — confirmation and regression — as a category of its own. This is not formalism. Teams without a shared vocabulary argue about whether something counts as “an integration test” instead of talking about risk coverage.
Levels and Types: Not Duplicating the Same Coverage
The test pyramid is a model of distribution rather than a prescription: many fast checks at the bottom, fewer at the integration level, fewest of the expensive checks through the user interface. The model says nothing about how many tests to write — it says that execution time and maintenance cost rise towards the top, so only what cannot be verified lower down moves up.
The common failure is covering the same business rule in parallel at every level at once. It feels safe and costs double: any change to the rule forces a fix in each layer, so the team starts routing around the tests, because the tests are what slows the change. The workable rule is simpler — verify the rule at unit level, verify the seam at integration level, verify the main flows through the interface.
Shifting Left, and Automation as a Capability
The learn.microsoft.com guidance on shifting left describes running tests earlier and more often, close to the moment a change is made, instead of accumulating them into a pre-release phase. For a team that translates into something concrete: a fast suite on every change, a fuller suite on the main branch, and no single large campaign before a deadline.
The dora.dev material on test automation supplies the other half of the same subject: automation is a team capability, maintained alongside the code, rather than a project that closes when a tool is installed. The uncomfortable corollary is that a suite nobody repairs after a red run stops being a gate within weeks and becomes noise.
The shift at stake here carries no date and no document announcing it — what shows it is what the dora.dev and learn.microsoft.com material cited above now requires. A suite treated as a team capability needs test data and environments reproducible on demand, which is where the next section goes.
Test Data Is the Part That Quietly Decides
The dora.dev material on test data management treats the availability of adequate data as its own capability: teams need data that is sufficient to run the suite, available on demand, and not a barrier to running tests early. This is the constraint that most often sends a team back to manual testing — the automated check exists, but the data set it needs is irreproducible, so somebody prepares it by hand and the suite runs when that person has time.
A strategy can settle it briefly: where the data comes from, how it is anonymised, who refreshes it, and whether an environment can be created on demand. Written down, those sentences are what makes shifting left possible. Left unwritten, shifting left produces fast tests with nothing to run against.
What Remains of the Test Manager’s Role
The test manager’s role does not disappear in an agile team; it stops being the role of campaign planner. What remains is accountability for the strategy as a whole: choosing the mandatory levels, analysing product risk, owning the quality of test data, and keeping the automated suite a gate rather than a decoration.
The harder half of the role is less easily written down — maintaining the shared vocabulary and settling disputes about coverage. Where nobody does that, each product team grows its own terminology, and after a few iterations reports from neighbouring teams stop being comparable.
The shortest test of a strategy’s usefulness: take the last production incident and identify the level at which it should have been caught. If the answer is “none, because we have no tests there”, that is the next line to write.
Read Also
- ISTQB certification: how to prepare for the exam — the certification path for anyone organising testing terminology
- API testing: tools and best practices — the integration level in practice, below the interface tests
- From tester to QA engineer: career path — how the role changes when testing becomes a whole-team activity
Build Your Skills
This topic is developed in the Test automation - Selenium WebDriver and Java and Test automation - Selenium WebDriver and RobotFramework courses. The first builds a test framework from the ground up; the second works on the keyword-driven approach and suite readability. Contact us to match the scope to your team’s stack.
Frequently Asked Questions (FAQ)
What does test automation in DevOps change about the strategy?
It moves the point of decision from a pre-release phase to the moment a change is made. The strategy then has to name which suite runs on every change, which runs on the main branch, and what happens after a red run. Without that last rule the suite stops being a gate and the team learns to route around it.
Do you need ISTQB certification to write a testing strategy?
It is not a precondition, but it supplies what most often breaks strategies: a shared vocabulary of test levels and types. The Foundation Level programme organises that terminology, so that “integration tests are mandatory” means the same thing to a tester, a developer and a delivery manager.
Where does API testing belong in an agile strategy?
At the integration level, before interface tests, with the contract as the object under test: response structure, error codes, handling of missing fields. Interface tests are then reserved for the main user flows, where they are the most expensive to maintain.
How do you test a web application when the team has no tester?
By writing the minimum into the definition of done and automating that minimum: unit tests for the rules, a check of the main browser flow, and a fast run on every change. Having no tester does not remove the need for a strategy — it moves accountability for it onto the team lead, who has to write it down before the first incident writes it for them.