When embarking on any testing project, you would usually ponder on questions such as “what to test?, why, how, and when to test?”

These questions are sometimes answered with the help of a Test Strategy, or a Test Plan in some context. However, to get value from these test artifacts, you must understand how they serve you.

In this article, I address 7 key questions testers often ask about test strategy, whilst I share some lessons learned in the past from creating and working with test strategies.

1. What is a test strategy?

A Test Strategy consists the set of ideas that guides your test design, development, selection, and prioritization of tests to execute in a test project.

A Test Strategy is a like a map, or guide that helps testers achieve their test mission.

If you consider your test mission or test project as a destination, then, your test strategy is like a map that tells you how to get to that destination. It informs your test design choices and direct every step you take to fulfill your test plan and objectives.”

2. What does a test strategy look like?

A test strategy can come in different shape and form, depending on the team, the project, the audience, and what its expected value is. In a nutshell, it can be for example:  

• A high-level documentation on how testing is understood, approached, and effected in an organisation or team.
  • The test strategy document should not be static. They must be constantly reviewed and adjusted according to the context.
• A shared understanding between team members on how the team intend to meet its testing needs.
  • A test strategy may not necessarily have to be documented. It can be an implicit knowledge in the team. More on this in a while.

3. Why do you need a test strategy?

I would normally say that, when setting off on any journey, it always help to have a map, or at least some idea on how to get to your destination.

Take for example, you intend to travel from London to New York, you will save yourself a lot of worries, if you have some ideas of the best routes and best mode of travel to reach your destination.

Such ideas becomes even more important if it is a journey you have been set up on by someone else.

Therefore, if you consider your test mission as a journey, then the above analogy would apply when you are for example, tasked to test an application or work on a project where your knowledge is maybe limited.It will be invaluable if you are provided with some sort of guide that can give you a head start.

For this reason, having a test strategy for your project can help enhance your effectiveness.

4. When do you need a test strategy?

You need a test strategy whenever you embark on any test project. The caveat being, the kind of strategy you need, or use may differ according to the context of your project.

Sometimes your strategy may be explicit in the sense that it is documented or clearly communicated between you and other team members.

Other times, it can be implicit in the sense that you have internalized your strategy into your test process in a way that it becomes your default way of approaching testing in the team.

This can be the case when you are a tester in a team or in a project where extensive documentation of your testing is not demanded by higher management.

I work in an Agile team, and we are constantly iterating our processes. Do I need a test strategy in such a team?

You most likely do. It is a common misconception that working with Agile means not planning much, but the reverse is mostly the case.

No matter how fast pace, or how much your testing is integrated into the development process, you always need to have a good idea of how you test in the project.

For example, you will normally have to make decisions on whether to focus on automating your tests? focus solely on exploratory testing? or perhaps both?

Moreover, what exactly can, and should be automated? And what can or should be explored? Likewise, what test technique is most appropriate for your context?

Any decision you make to answer these types of questions becomes part of your test strategy for that project. So yes, working in Agile software development team should not stop you from having a test strategy.

5. How can you implement a test strategy?

To successfully implement a test strategy, you need to understand the context of its usage.

As already mentioned, a test strategy concerns itself mostly with the “how” of your test mission. However, to understand the how, you should first understand the ‘why’.

It will be difficult to implement any strategy if you do not know why you are doing so, or why you need it. As Nietzsche once said:

“They who have a why, can bear almost any how”.

– Nietzsche

Broadly speaking, to implement a test strategy, you need to collaborate with other stakeholders in your team to understand the broader context and what is important to them. Then, jointly decide on the appropriate direction that serves your need.

6. Should a test strategy be documented?

Whatever your approach is, a test strategy should not be a document that you create for the sake of it. The most important thing is to understand the ideas embedded in the strategy.

You always need to ask the question, why are you creating this? What do you hope to gain from it?

If you can’t find support for why creating a documentation contribute to the effectiveness and efficiency of your testing, then you probably do not need to spend the extra time on the document.

That said, there is always value in documenting strategic decisions so that you can refer back and signpost others to it when needed.

Moreover, documenting your strategy can make it easier for everyone in the team to access and contribute to it when needed.

7. Should you create an organisation-wide or project based test strategy?

On this, I would say it depends.

Sometimes, an organisation-wide strategy can be useful. But it depends on the nature and size of the organisation. Other times, it may not be necessary.

Often times, what people call a test strategy is usually a ‘test policy’ or ‘mission statement’ for a test team or organization.

In this sense, a test policy can be an organisation-wide document that details the vision and mission for testing and quality in that organization.

Meanwhile, what I now consider a test strategy is usually project focused. And it is often specific to the testing of a particular service, product, or feature. For example, the scope of testing for an e-commerce application etc.

A blast from the past:

Once upon a time, I worked in an organisation where we had testers working in different product teams. Everyone basically had the liberty to design their test process within their respective teams according to the need of the product they were responsible for.

However, as part of our vision to elevate the test department, I started an initiative with my then Manager to develop a test strategy that the test department can use as a guide for testing across the organisation.

We wanted to align the testing process across teams so that it was streamlined and easier to visualize what we do and how we work to higher management.

Did this work? Well, not as much as we hoped.

It turned out that what we created at the time was more of a test policy for the organization and not really a test strategy.

At best, it became a wonderful document to introduce newly employed testers into what we were doing in the test department, and how we approached testing. Because, we managed to define the vision for test, and the strategy for how the test department would provide relevance and help the organisation meet its quality goals.

There were also aspects of the documents that seemed to have inspired the individual testers on how they should think, and approach testing regardless of the project or team they were assigned to.

Despite those gains, it didn’t take long for us to notice a sense in the team that the main purpose of the document was not really achieved. Hence, we had to go back to the drawing board.

A strategic pathway forward:

In response to the above situation, we started creating, for the different teams, specific strategies for testing individual services, products, and features. This approach yielded better results, and it is one I have taken with me to subsequent projects.

The approach was nothing more than, to think specifically about the particular product or service I am responsible for testing. Then designing what I need to achieve my testing objectives.

The project specific approach include having a checklist that reminds me to, for example:

1. Learn about the product through i.e. available resources, experimentation, exploration etc.
   
2. List preconditions for testing the product i.e. environment settings, versions, devices etc.
   
3. Explore the basic functionalities and run through previously reported bugs in live application.
   • If it is a new product – run through the major objectives the product is expected fulfill for a user.
     
4. Identify general risks and issues that may occur within the product based on your knowledge of similar products.
   
5. Make a list of integration points, and identify possible risks.
   
6. Make a list of the most critical aspects of the products. i.e. those critical to business, those more prone to failure, and those prone to security vulnerabilities.
   
7. Determine test techniques and execution method.
   • Evaluate how much unit test, integration test, and user interface test currently exists, or is needed for a satisfactory test coverage.
   • Create a list of test scenarios/ charters/ checklist (depending on how you work) that will help you gain information about how the application behaves under various conditions.
   • Determine what techniques and methods you need to fulfill your list in (point 2) above.
     • This could include identifying areas to be automated.
   • Carry out the tests and document your findings.
     
8. Review your findings and verify discrepancies with the requirements.
   • This can also include discussing and communicating your findings with stakeholders.

This approach has yielded better results for me, as it helps me plan my testing according to the specific need of the product in question. Moreover, whilst it is valuable to me, it also proves useful to anyone in the team who is interested in taking on the mission to test the given product or service.

Final thoughts:

There is value in creating a test strategy for any given test project. However, it has to be targeted to the needs of the project, and its purpose has to be clear to all concerned.

When a test strategy defines testing objectives, identify potential risks, and outline the appropriate testing methods and approach, it helps teams focus their efforts effectively and efficiently. It can also facilitates communication and collaboration among stakeholders, ensuring everyone is on the same page regarding testing expectations and outcomes.

Ultimately, a robust test strategy can help reduce defects, improve product quality, and increase confidence in the final product, saving time and resources in the long run.