What is a test strategy?
If you work in software testing and quality — or even in building digital services — you’ve probably heard of a test strategy.
According to the ISTQB Glossary, a test strategy is a description of how testing is to be carried out to achieve the test objectives under given circumstances. This definition has evolved since 2019, when this article was published.
In practice, a test strategy is a document — defined at company level in ISTQB certifications, but most often at project or product level in many organisations — that describes (among other things, and not necessarily covering every item):
- Roles and responsibilities
- Types of testing to be performed
- Testing organisation and processes
- Test campaign planning and execution
- Bug management
- Test data and environment management
- Test automation
- Available tools
- Processes and methodologies
- Entry and exit criteria
On paper, it all seems pretty clear and firmly focused on testing, which explains the name. But in reality, things aren’t quite that simple.
The problem with the term “test strategy”
Throughout my career, I’ve often been asked to design or update test strategies.
Whether working in a Waterfall or Agile environment — although the issue is much more obvious in Agile — a test strategy is not a document written just for testers.
Nor is it exclusively about testing activities in the narrow sense of the word.
The good news is that I’ve rarely had to explain this to the organisations I’ve worked with. The people I collaborate with generally understand that a test strategy is a shared document that concerns everyone involved. In fact, some clients have explicitly pointed out that it must involve developers and business stakeholders, too.
So the term test strategy can be misleading, particularly for junior professionals.
A test strategy covers far more than the testing phases of the development lifecycle. It can address:
- Requirements definition: for example, Behaviour-Driven Development (BDD) helps challenge requirements and assess their value.
- Solution design: BDD can also help challenge proposed solutions to a given need.
- Development: including unit test coverage and the importance of code reviews.
- Test preparation: test design techniques, test data and environment management, test reviews, and more.
- Testing: which test campaigns should take place, and when.
- Cross-functional activities: such as test automation and CI/CD.
- Validation: including User Acceptance Testing (UAT) and exploratory testing sessions with business stakeholders.
- Deployment: for example, using canary releases.
As you can see, a test strategy concerns everyone involved.
That makes sense when we consider the two main goals of testing:
- To determine whether a digital service meets the required quality standards before it is released to users.
- To achieve that level of quality as cost-effectively as possible.
The real value of a test strategy
For me, the main purpose of a test strategy is very similar to that of BDD: to align everyone involved in delivering a digital service.
While BDD focuses on the features a team is about to develop, a test strategy provides a broader perspective.
It brings together more people: everyone contributing to the development and delivery of the service.
And it covers a wider range of activities, looking beyond what is about to be built and considering the service as a whole.
What makes a test strategy successful?
An effective, successful test strategy isn’t necessarily one that covers every aspect listed above.
For me, a successful test strategy is one that brings people together.
A strategy that everyone understands, embraces and takes ownership of. One that keeps quality at its core and evolves with the context.
There’s nothing wrong with starting small with an MVS — a Minimum Viable Strategy (or, as I like to call it, a Minimum Valuable Strategy 😄) — and refining it over time.
Just like a digital service, a test strategy must adapt as things change.
Conclusion
A “test” strategy isn’t just about testing. It’s about quality — and that means involving everyone who contributes to building and evolving a digital service.
Likewise, a test “strategy” shouldn’t be just a strategy on paper. It should be a shared vision: something that brings people together and evolves over time.
Perhaps the term test strategy isn’t perfect. But finding another name that captures all the roles, activities and shared responsibilities involved in a good test strategy is no easy task.
What does a test strategy mean in your organisation? Is it still seen as the testers’ responsibility, or is quality truly a shared responsibility?
Software Testing and Quality Advocate & Facilitator at K-LAGAN – Host of “La Taverne du Testeur”
