Hi everyone! This article is the first in a series of AUTO1 testing-related posts, I hope you’ll find the content interesting enough to return for the rest in the series :) To start off, let’s ask one of the most important questions:

What is a Test Strategy?

In AUTO1 the test strategy is a high level, short and concise document which defines:

• Scope of the testing

• Risks - areas that potentially can be broken

• Automation strategy

• Required test data

• Security

Why do we create a Test Strategy?

In agile and fast changing environments we usually do not spend that much time on test documentation as in waterfall. However, even in such cases we cannot underestimate the importance of a test strategy. When you are creating a strategy it becomes your guide, a channel for your thoughts - you have a space to stop for a moment to try to understand what should be verified and do it at a very early stage. It is much easier to go back to the feature if you already wrote down your thoughts and you have some kind of summary.

How do we create a Test Strategy?

Let’s go through our thinking process, step by step.

Scope of the testing

Start with defining what exactly has to be tested. You can ask yourself a few questions:

• Who is going to use the feature?

• What apps will be changed/created?

• On what devices will it be used?

• What types of testing will be needed?

It allows you to better understand the product you are going to test and the environment setup you’ll need.

Risks

Now think about all the things that can go wrong. Here the questions will be:

• What apps/areas can be impacted by our change?

• Are we modifying dependencies of another system?

• Is my domain knowledge enough to understand a feature?

• Are there any missing prerequisites which can block testing?

• Are changes going to be compatible with existing solutions?

Answering these questions will help us create a plan in order to mitigate all risks. It can be planning an onboarding session with someone who has knowledge we need, investigating regression testing possibilities for apps or areas in danger or setting up a plan on how to get blockers done.

Automation strategy

Automation is an important part of our testing process. We think about the approach on the test strategy stage. We create our tests on an UI and API level. When we’ll have the technical specifications, which include details of implementation, then it is time to plan what and when will be automated. We ask questions such as:

• Where is the specific logic placed? Is it frontend or backend?

• Do we have existing automation in this area? If yes, do we have to adjust it?

• Do we have all prerequisites needed to start writing automation?

Required test data

At AUTO1 we have a lot of connections between several areas. It created dependencies which have to be covered in test data preparation. We have to be sure we know the preconditions and steps required to arrange the system before starting testing. Here we can specify if we need additional onboarding or support from other teams.

Having answers to the above questions means we are prepared to plan more detailed test cases and we can use our strategy as some kind of a cheatsheet. However, do not blindly follow what you’ve planned - requirements can change. Review your strategy from time to time, to ensure that it is not outdated.

Summary

Test strategy shouldn’t take much time but it is important for the next step - creating a test plan. It can be a great guide which will help you to structure your initial ideas and be prepared for upcoming changes faster.