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 better now? Automation can help here.
But when is it really worth it?


Advantages of test automation are the reduction of the amount of tests to be executed manually, thus saving resources, time and therefore money. In addition, 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.


A classic scenario in which test automation not only makes sense, but is also an obvious choice, 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 begins. Then the implementation is started and after each iteration the predefined tests are executed. Many iterations can occur here, especially with complex problems. In order not to let the test efforts explode it needs an automation framework.


Regression testing is the term used to describe test cases that must be performed when a change has been made to the software to ensure that existing functionality has not been corrupted. This is particularly important when processes are interwoven and/or build on each other. Here, automation makes sense if the basic functionalities of the software are no longer changed, so that the regression test cases do not have to be rewritten each time. In particular, predefined functional tests can significantly reduce the workload of the specialist department.

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



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

In addition to 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.


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 not recommended in most cases, as it should be separated 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. Similarly, not every test automation tool fits every infrastructure and every project. At the start of each project, we recommend that you analyse and define exactly which of the scenarios or whether a mix of them applies. ADWEKO’s experts are 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 (link missing)

Talk to

sonja müller!