The 7 types of test strategy

I have been working in testing for nearly two decades and designed hundreds of testing strategies. These have been either for organisations I worked for, or clients of our software testing company. Recently I have been studying ISTQB’s Expert Level Test Manager syllabus, and came across seven types of testing strategy that I think are a very interesting way to think about designing a testing approach.

Getting a testing strategy wrong can have a very harmful effect on a product, project or team. You might find yourself spending all your time running tests that aren’t important, or lose the confidence of stakeholders - both of which effectively invalidate your results.

What do I mean by test strategy?

I don’t mean a document. When people say test strategy, that is what they normally mean. I instead mean the essence of how we decide what to test. There are many things that affect this including organisational factors, skills availability, risk, availability of a test oracle.

Let’s take the different test strategies one by one. It is important not to read these as single strategies that you select - it is much more likely that you will find a combination of them is appropriate for your context.

You might also mix test strategies by test level (unit testing, component testing, system testing, user acceptance testing etc…), or even by tester!

© Dragonfly 2022. Permission to reproduce electronically is granted if a link to this article is included as attribution.

Analytical Test Strategies

An analytical test strategy is the most common strategy, it might be based on requirements (in user acceptance testing, for example), specifications (in system or component testing), or risks (in a proper risk-based testing strategy). 

In a more agile approach, it might be based on none of those, but a common understanding of user stories, or even a mind-map.  The point is not the form of the test basis, but that there is a specific test basis for the release that is analysed to form a set of tests.

Model-based Test Strategies

An increasingly popular strategy is a model-based test strategy. This combines specification-based testing with structure-based testing to create some model of how the software should work. This might be a diagram that shows the user route taken through a website, or a diagram that shows how different technical components integrate, or both! 

This is a really interesting strategy because it allows for the best tool support. Creating a machine-readable model of the application, allows tools to generate manual or automated tests.

Methodical Test Strategies

A methodical test strategy is when you use a standard test basis for different applications. 

This might be for instance, because you test payments and the payment scheme provides a set of mandatory tests for a particular type of transaction in system testing. Or, it might be because you are doing application security testing and want to leverage the industry experience baked into the OWASP Application Security Testing framework. 

Standards Compliant Test Strategies

Standards compliant test strategies are where you use industry standards to decide what to test. 

This is most likely where you are in a specific regulated sector, like self-driving cars, or aviation, where there are specific standards you have to meet for testing. For example, code coverage in system testing might be a requirement, or testing specific scenarios in user acceptance testing.

Regression-averse Strategies

A regression-averse strategy is one where you just make sure nothing has broken since the last release and ignore the changes. I have only done this in limited scenarios, for example an infrastructure replacement where nothing is expected to change. 

Another example is in testing very complex systems where named experts need to test the changes, and the testing function just aims to verify there is no regression. Of course, in the latter scenario you could argue that is a regression-averse system testing strategy and the user acceptance testing strategy is different.

Consultative Test Strategies

Well this one is the worst for me, particularly as I work for a software testing company. Basically it means asking someone else what you should test and letting them decide. 

Sure, there’s scenarios where the functionality was too complex for me to understand and I had to ask other people about how to test, but I still applied test design techniques to what they said in my system testing…

Reactive Test Strategies

Reactive test strategies are where you decide what to test when you receive the software. This can happen in exploratory testing, where things you observe on your testing journey drive further tests. Another example is metamorphic testing of machine learning, which you could argue is reactive as one test depends on the next.

Reactive test strategies require a lot of skill and expertise, and don’t give me confidence in quality unless they are combined with other strategies.

In summary…

Hopefully you will find this use whether you are starting your testing journey, or are an experienced designer of testing strategies. As I said at the start, you probably aren’t going to pick one of these and stick to it religiously… I like to think of this as a mental model for testing that helps you think about it!

Adam Leon Smith, 24th January 2022