Setting Up Automation Testing From Scratch

Automating manual tests for a software application helps reduce significant costs of a test cycle where a lot of the test steps involve repetition of the same actions. The prime candidate tests in a test cycle for automation are regression tests and smoke tests. By automating these you save a lot of resources and mainly the test cycle duration.

This time, a colleague from the German office, Prasanth Sivakumar, who works as a Software Test Automation Engineer, shared his experience and stories of software test automation projects where he reviewed the processes and steps he followed to set up automated test suites from scratch. Our diligent colleague Prasanth has been in our team since October last year, and he has had an extraordinary experience in software development and testing for about five years, with digitalization and automation as an objective across different industries in various projects. This is an excerpt from his previous experiences and works in System Verification, where he will surely explain his point of view and work to you in the best way. When we had a quality conversation with him about what advice he would give to all of you and what his experience was in setting up automation testing from scratch, he said:

''As always, we start with strategizing the test automation process. We need to define the scope of the automation. All of you need to remember that hundred percent automation may not be an ideal goal. Identify from the manual tests the potential candidate steps that can be automated. Start with small test steps for example steps that are monotonous, run frequently, repetitive, iterative over a dataset, and have well-defined “Pass” or “Fail” results and are some of the candidate tests for automation. 

By following my last project, we categorized the manual tests into fully automatable, semi-automatable, and manual tests based on the analysis. We broke down the smoke tests into a set of sub-tests and sequenced them in the test suite. 

Among the tests, some steps cannot be automated as they involve manual interference due to factors including but not limited to hardware interrupts, manual steps involving hardware calibration/ recalibration, and system-level actions that cannot be programmed. In such situations, we can find two possible solutions: The steps can be simulated by using drivers or tools, and the steps have to be performed manually by manual interruptions between the automation execution. Here you have to make a decision if it is worth automating these steps, i.e. either simulate the manual interrupts or avoid automating the whole test step. 

Test automation depends immensely on the automation tools used. Some of the factors to be considered for choosing the right tools are: 

• The features provided, frameworks supported by the tools.
•  The learning curve required for the team to learn/relearn the tools. 
•  The support from the automation application developers and the community forums for the tools.
•  Budget constraints for licensing and/or purchasing tools/plug-ins
•  The programming language is supported by the automation tool to write the test scripts, and 
•  The team’s experience and expertise with the tools and the language.

We considered these factors and decided to work with TestComplete from SmartBear and programmed the automated tests in Python3, with Jira and Bitbucket for the test project management. The team had some pre-built tools to simulate some manual states and input conditions.

Remember my first piece of advice – “Start small”.  Automate the sub-tasks involving actions like menu navigation, file handling, and setting manipulation options. These functions are commonly performed over many tests and hence can be written into a driver module that can be referenced or used whenever needed in automated tests. This avoids redundant lines of code across multiple test scripts. 

We created a toolbox for such commonly performed actions across different wizards, menus, and modes of the software. It was maintained by a limited number of members of the team and updated as we discovered further such actions in the test cases. We could write a test case with a sequence of toolbox functions with test-specific parameters. Here we implemented a style of pair-programming, pairing the automation programmers with the manual testers as the reviewers for the automation code. The manual testers’ expertise in the application’s domain and the cruciality of the test steps are essential from the planning stage throughout to execution. ''

At the end of this valuable blog story, Prasanth wants to explain that maintenance of the automated tests involves modifying the test scripts as the software UI changes. A slight change in the UI component hierarchy can break an unmaintained automated test suite. New updates from the automation tools could also invoke the need to modify the automated tests. With the interval between software deliveries reducing, automation testing has become indispensable in the software test cycle.

We want to share Prasanth's experience to show you that you may find the appropriate fit for you straight away and that, with a great team and a commitment to your work, success is inevitable. Thanks to System Verification, where everyone's career path is carefully managed and monitored, Prasanth's professional career path will certainly go even further and provide new solutions and gains to the IT industry! If you have any questions on a given blog topic or are just starting out and want to plan your professional path, we recommend contacting Prasanth because we are confident he will be able to help you.