3 scenarios for successful test automation

Do you also know this from your previous projects: Your manual tests take a lot of time and your testers groan under the load of the tests? Do you want to do it better now? Automation can provide a remedy here. But when is it really worth it?

The advantages of test automation are that it reduces the number of tests that have to be carried out manually, thus saving resources, time and money. In addition, a higher quality is achieved through higher test coverage.

But what does this mean in practice? The following scenarios shed light on the use cases in which test automation is helpful.

Scenario 1: Test-Driven Development Approach

A classic scenario in which test automation not only suggests itself but imposes itself is an implementation project with test driven development. This work mode dictates that the tests must already be determined (and written) before the actual implementation is started. Then the implementation is started and after each iteration the predefined tests are run. This can lead to many iterations, especially in the case of complex problems. In order not to let the test efforts explode, an automation framework is needed.

Scenario 2: Regression test

Regression testing is the term used for test cases that must be carried out when a change has been made to the software in order to ensure that the already existing functions have not been damaged. This is particularly important when processes are interwoven and/or build on each other. Here, automation makes sense when the basic functionalities of the software are no longer changed, so that the regression test cases do not have to be rewritten each time. Predefined functional tests in particular can significantly relieve the workload of the specialist department.

In order for test automation to be worthwhile, it also depends on the number of regression test cases and how often they have to be repeated. It is worthwhile to make a cost-benefit calculation here. However, as long as there is no basic outline of the software, automation does not make sense because the adaptation effort for the test cases is too high.

Scenario 3: Building technical infrastructure

If technical resources are already available at the beginning of a project, but at the same time no implementations are planned (because, for example, the requirements are not yet known), it can be worthwhile to use the resources to create a technical infrastructure. This includes test automation. From our own experience, a simple test automation at unit level can be written in as little as one month and can considerably relieve the upcoming test efforts.

Besides the availability aspect, it is also helpful if the system structure has a clearly defined input and output layer that can be targeted by the automation framework.

Complex system

One case where test automation becomes a waste of time and resources is in a complex system with many data stores that still change from time to time. Thus, the input and output layers cannot be clearly defined and the framework would have to be constantly adapted. This ultimately leads to a loss of time, as the framework itself must also be tested when changes are made.

If the system is not accessible from the outside, test automation is usually out of the question, as it should be separated in order to avoid external influences.


As you can see, test automation is recommended in many scenarios. It not only increases the quality of your product, but also the satisfaction of your testers.

However, test automation is not a panacea that solves all testing problems. Likewise, not every test automation tool fits every infrastructure and every project. We recommend analysing and defining exactly which of the scenarios or whether a mix of them applies at the start of each project.

ADWEKO's experts will be happy to support you in deciding whether automation makes sense and whether you should automate completely or partially, as well as in selecting a suitable test automation framework and setting up the test automation project.

> Learn more about our Managed Testing Services

Sonja Müller