Test automation
More speed and quality through test automation
Guaranteeing high quality of applications in times of rapidly accelerating release cycles requires ever shorter periods of time between tests. At the same time, additional application features come with additional code that needs to be tested. In this context, manual testing approaches quickly reach their limits. The solution: test automation. And while test automation has many advantages, it also comes with a variety of challenges. All of this makes a carefully planned test strategy all the more important.
The market: test automation
Software development over recent years has been characterised by multiple developments across a wide variety of fields. One key aspect has been the rising speed at which new releases are made available. To achieve such shorter release cycles required concepts such as CI/CD. The automation of processes in this, of course, has played a central role. These trends accelerate the competitive need to modernise existing applications and introduce modern concepts and technologies. Often, regulatory changes and new laws that accompany current digitalisation processes also necessitate adaptations to existing applications. In short, there are many reasons to make considerable changes to applications. These changes make testing even more important, so that organisations can assure applications’ proper ongoing functionality. Obviously, the use of modern concepts like CI/CD means that traditional approaches to testing are no longer enough – testing, too, must evolve. In other words: testing must be be automated.
The challenges: test automation
It is useful to consider the problems that can occur when using traditional testing approaches. This helps to understand the added value of test automation and the ways in which testing can be strengthened. The list below provides a few examples of typical problems when testing older applications.
- During test implementation – manual testing:
Often, tests are conducted manually. Not only does this tie up resources that could be used more effectively elsewhere, manual testing is also highly prone to errors because of the need for a tester to repeat the same steps over and over. Furthermore, manual testing can by definition only happen during testers’ normal working hours – considerably limiting the extent of possible test coverage. In the end, organisations must realise that testing is an essential part of development cycles. This also means that manual testing becomes a bottleneck if all other processes are successfully automated (->CI/CD). - When defining test cases – linear scripting:
Where testing is not conducted manually only but with the use of test scripts, the chosen test approach influences the efficiency and future ability to manage test designs. Often, testers intuitively choose so-called linear scripting. In this approach, every test case has its own test script even where test cases resemble each other closely. Linear scripting ignores similarities between cases. In turn, this increases the time needed to make changes to test scripts because each script has to be adapted individually. - Test environment – bad design:
Testing large applications is a complex process that regularly needs to integrate multiple systems and tools. As a rule, test processes consist of numerous smaller test cases. Both of these facts influence how testing should be organised. If the resulting requirements are ignored – for instance because each tester creates their own test cases without following a common structure – then the result is often a severely limited ability to manage test cases in future. In the long run, unmanageable test systems become incomprehensible – and thus unusable. In a worst case scenario that means that entire test systems have to be re-developed from scratch. - Test organisation – late testing:
Testing often takes place right at the end. This regularly makes fixing errors more difficult and resource-intensive compared to a more timely identification and removal of errors.
- During test implementation – manual testing:
Solution and approach
Modernising testing approaches toward test automation avoids the problems discussed above. The modernisation process described below has proven to be effective:
- Analysis: this step gathers all information needed to implement the test automation, including information about the application and current testing approaches. Each application is unique and this fact influences how the application is tested. Analysis therefore must identify customer-specific testing characteristics to anticipate potential challenges in the roll-out of test automation. It is important to consider the entirety of the testing context: not just technical facets, but also non-technical ones such as the optimal use of available testers. The goal of analysis is to formulate a testing strategy which provides a roadmap for the remainder of the test automation.
- Test design/test modification: It goes without saying that the availability of test scripts is essential for test automation. The approach chosen in this step is therefore directly influenced by the availability of scripts. Where customers have no test scripts, for instance because testing to date was done completely manually, such scripts are developed now. Where scripts already exist, this step aims to improve them. Chosing the right test approach for each customer is crucial. One approach is key-word driven testing. EasiRun supports this process with both its know-how and with a series of tools, such as a record-and-play tool for testing of surfaces.
- Test automation: Step 2 involved the development of test scripts to execute individual test cases which laid the necessary foundation for test automation. This does not, however, represent a fully implemented test automation because test scripts still need to be started and evaluated manually. This step therefore involves automating start and evaluation processes. EasiRun provides a test framework that does so automatically. Two aspects are key:
- Automating the test process: test automation should automate both the execution and the evaluation of test cases. The result should be that all test cases are run from start to finish automatically at a chosen time. It also makes sense that test automation seamlessly integrates with the automation of other development processes as part of CI/CD.
- Managing test cases: automating test processes is only one side of the coin. Test results are, on the flip side, just the start of further work: identifying and fixing code errors. To make this step straightforward in the long run the test framework should also present the results of tests and their evaluation in a structured format that users can easily navigate. This is fundamental because full tests can involve a hundred ore more test cases, and it is likely that this number will increase because test automation extends the scope of testing processes.
By adding test scripts into a pipeline, the test framework reflects the first point. This allows users to choose the point in time when test processes start. It also allows for integrating the test pipeline into the entirety of CI/CD development processes. The second point is addresses through the test framework’s transparent design, which provides an overview of all test results and enables swift error identification for every test case. Finally, the test framework offers a library of all previous tests enabling users to review the results of older tests – for instance, the test of a previous release.
Why EasiRun
At EasiRun, we draw on many years experience of developing and implementing efficient test strategies to support our customers with tailored solutions across the entire test automation process. From analysis, over test development, through to the full automation of testing processes we ensure that technical and organisational requirements are optimally reflected. By using our tools and frameworks in a targetet manner, we enable the seamless integration of tests into existing development processes and offer our customers sustainable added value.
