So lässt sich Software-Testing erfolgreich automatisieren

Consistent testing: better once too much than too little. Due to the Corona crisis, this is currently everyday life for many of us. And such a self-test or quick test is done immediately. The effort is usually in a good ratio to the benefit.

This is not necessarily the case with enterprise software. A lot of testing is also done here, but these tests are often time-consuming and complex. Especially companies with software structures that have grown over decades and have been adapted again and again often have to spend a lot of time on constant quality control. Not everyone has the luxury, like so many start-ups, of being able to think from the ground up.

Wouldn’t it be great if you could automate and simplify inspection processes? However, complex IT structures often stand in the way of integrating continuous testing into the DevOps pipeline. With the following strategies, consistent, automated testing can still work.

Automating is only useful if it makes it easier

Traditionally, automated tests run via scripts. An automation framework is created as the basis of this method. Scripts are then added to this framework structure. As the application under test evolves, the framework and scripts also need to be reconsidered and possibly adjusted. This can lead to testers having to be retrained. Even experienced staff can have trouble keeping track of the constant changes.

If we remind ourselves that automation is supposed to speed things up, this approach is counterproductive. If you want to automate quality control, you should adapt the technology to the application. An app developer, for example, has different requirements than a backend developer. Nevertheless, the cooperation should not be neglected. If you already have different approaches in your arsenal, everyone should know them and be able to understand what another team did. A “Swiss Army knife solution” probably does not work with different technologies. Rather, it is important to implement a solution that can be used to automate test cases across the entire technology stack and thus simplify cooperation between the development teams.

The tool must match the craft

Software is plentiful. Whether open source or for a fee, there is also a large selection for tests. So think carefully about what your requirements are. A small business with fewer individual requirements can get by with a free test kit. The larger and more complex the structure becomes, for example through SAP and Salesforce applications, the more the tool has to be able to do.

Before purchasing a test tool, you should know exactly what it is supposed to be able to do and what it is used for. The tool is only part of the process. If it’s not right for the job or the operator, it won’t serve its purpose.

When maintenance is difficult, automation suffers greatly

It will take a while for the automation to be fully implemented. But this can save time in the long run. At least if maintenance doesn’t become a resource hog.

It doesn’t work without proper maintenance. When testing, you have to be able to rely on the correct results. Two main problem areas are: unstable test methods and methods that are difficult to update.

The solution to both problems begins even before testing. To avoid unstable processes, more stable identifiers can help. The clearer the criteria can be assigned and identified, the better. In addition, attention should be paid to how the test tool reacts to variations and how easily it can be adapted to changes in the software. But beware, even the best test can be compromised by incomplete or incorrect data sets.

To keep the test application up to date, it should be modular. If a process changes, the entire application does not necessarily have to be adapted, just a part of it. The modules must be integrated into the overall software in such a way that they still function in the infrastructure despite the update.

A modular structure may invite you to add something here and there. Nonetheless, you should measure it up.

More focus on the interfaces 

Many automated tests deal with the user interface (UI). After all, the user should be able to work with the software later. Interface (API) tests are more suitable for the development process and will become increasingly important in the future. According to a study by Tricentis, the construction, maintenance and runtime of API checks are much easier and faster to manage (by a factor of more than 100 at runtime). Also, interface testing can be done earlier than UI testing. It may be possible to see earlier the effects of new versions on certain areas.

Not all strategies suit every company

Whether automated testing works in your company cannot be determined solely by strategies. The four mentioned here are recommendations based on experience. However, the best plan is of little use if the workforce is not ready for it or if the infrastructure is not in place. So check your needs, check your options, talk to colleagues. Make your own plan.