Many projects have test cases, test tools and sometimes even a detailed test plan – but no shared understanding of how testing should work in principle. Each team then decides for itself what “sufficiently tested” means. A test strategy creates that common framework. This article explains what a test strategy is, what belongs in it and how to develop one in five steps.
A test strategy describes the general test approach for an organisation, a programme or a product: which quality goals are pursued, which test levels and test types are standard, how testing is prioritised by risk, which degree of automation is targeted and who is responsible for what. In other words, it answers the question of how testing is done – not which test case is run by whom and when.
A good test strategy is short enough to be read and concrete enough to guide decisions. A sentence like “We test thoroughly” is not a strategy. “Every change to payment processing goes through automated API tests and a business acceptance test” is.
The terms are often mixed up. A simple division of labour helps:
In smaller projects, test strategy and test plan often merge into a single document. That is fine, as long as it remains clear which statements apply in general and which only apply to this one project.
Start with what the strategy applies to and which quality characteristics matter most. For an internal administration tool, functional correctness and usability may come first; for a customer portal, security, availability and response times are added. This weighting shapes everything that follows.
The strategy defines which test levels are planned – for example component, integration, system and acceptance testing – and who owns them. Then come the test types: functional tests, non-functional tests such as load testing or security testing, regression testing and confirmation tests. It is just as important to state what is deliberately not tested.
No team can test everything with equal depth. The strategy therefore describes how risks are assessed and how this affects test depth and order. The approach is explained in detail in our article Risk-based testing.
This part defines which tests are automated, at which level and for what purpose. A proven guiding principle is the test pyramid: many fast tests at component and API level, fewer tests through the user interface. The strategy should also clarify how automated tests are integrated into the CI/CD pipeline. How to get started is described in Introducing test automation.
Which environments exist, how close are they to production, and where does the test data come from? Especially with personal data, the strategy must specify whether anonymised production data or synthetic data is used.
The framework includes clear responsibilities (development, testing, business, test management), a consistent way of handling defects including severity classes, and reporting that supports decisions. The tools in use, for example for test management and defect tracking, belong here as well.
The ISTQB syllabus distinguishes several basic approaches, which in practice are almost always combined:
A common combination is an analytical, risk-based core, complemented by regression-averse automation and reactive, exploratory tests for new features.
Talk to the business, development, operations and, where relevant, compliance: which quality characteristics matter most, which requirements apply, how often do you release? An honest look at the current state also helps – where did defects recently reach production, and where does testing cost the most time today?
Derive the most important product risks from the quality goals. This shows which areas and quality characteristics need particularly thorough testing.
Decide which test level covers which risks, which test types are mandatory and what is automated. Make sure the same checks do not run on several levels without need.
Describe test environments, test data, tools, roles, defect classes and reporting. Also formulate overarching quality gates, for example: a release only goes live if all tests for high risks have passed and no critical defects are open.
A test strategy only works if the people involved support it. Align the draft, store it where it is easy to find and plan a regular review, for example once a year or when architecture, team or release cadence change significantly.
For a web application with regular releases, a test strategy can fit on a few pages:
The specific test plan for a release then refers to this strategy and only describes what differs or is added for that release.
Scrum teams need a test strategy too – it just looks different. Instead of an extensive document, a short page in the wiki maintained by the team is often enough. Key parts of the strategy end up directly in the team’s working agreements: in the Definition of Done, in standards for acceptance criteria and in the pipeline that runs the automated tests on every change. When several teams work on the same product, a shared strategy ensures that “done” means the same everywhere. How testing works in the sprint is shown in our article Agile testing in Scrum teams.
A test strategy defines how your software project is tested in principle: with which quality goals, test levels, test types, priorities and degree of automation. It is not an end in itself but the shared foundation for test plans, test cases and release decisions. Kept short, concrete and regularly reviewed, it ensures that testing time goes where it delivers the greatest benefit.
Usually test management or an experienced test lead. The content, however, is created together with development, the business, operations and project management, because only then are quality goals and risks assessed realistically and the rules actually followed later.
There is no fixed rule. A review about once a year has proven useful, as well as whenever architecture, team structure, release cadence or regulatory requirements change significantly.
Not necessarily. If there is an overarching test strategy in the company, a single project often only needs a test plan that refers to it and describes the deviations. If there is no such strategy, its core statements should be part of the project’s test plan.
30-minute initial consultation — free and without obligation. Together we look at your project and show how a lean test strategy makes your quality assurance more effective.
Book a Free Initial ConsultationMore about our service: Software Quality Assurance in Hamburg →
Related: IT Project Management in Hamburg →