DEV Community


How NOT to do Automation Testing

Hemanth Yamjala
I'm passionate in knowing new things related to software testing industry.
・3 min read

Automation Testing
When the quality of software application has become the sole determinant in delivering a great user experience, quality assurance assumes an increased salience. The traditional way of software development may cause many glitches to go unreported. This is where automation testing becomes a critical factor. It facilitates execution of a slew of testing processes like regression, smoke, functionality, etc.

Furthermore, in the Agile and DevOps driven Software Development Life Cycle, deriving quality outcome in the shortest possible time is underpinned on the success of automation testing. However, test automation is not a be-all and end-all process, for it needs to be applied only where it is needed. This is due to the fact that automated testing can be a costly proposition to begin with. It requires the right tools, qualified testers, and considerable time and effort to develop the right test infrastructure including the test scripts. Each test script needs to be designed, coded, and tested before implementing. Since so much is at stake when it comes to planning and implementing QA automation testing, one needs to consider certain things that should not be pursued while planning a test automation strategy.

Things to avoid during planning an automation testing strategy

Using the wrong tool and layer: Today’s web applications have both frontend and backend to facilitate seamless functioning. The backend, on its part, comprises many REST APIs that are easily accessible. However, a large number of test engineers use a cumbersome method of validating the application’s functionality at the UI level. API testing can be simplified using tools like Rest-Assured and Karate. Since the number of new bugs is more than what could be found during regression testing, one should not wait for an added feature to become stable and fully developed. Let us understand there is a higher chance of finding a bug as and when a feature is added. Also, it is better to conduct testing in parallel with the development process for better coordination.

  • Automating every test: Just because the trend is towards automation and manual testing is supposedly passé (or is it?), it is not necessary to seek an automation testing approach for every test. Try to look for scenarios that have higher chances of failing and their potential impact on the user experience and functionality. Should such scenarios be dime-a-dozen, then they should be automated. Many times, the test engineers often forget to integrate the automated sprint with other features. This leads to poor integration of features and consequent poor performance of the software application. Remember, executing automated testing does not necessarily mean to test everything in a sprint but finding out if the component is working as per the accepted criteria.

  • Running the testing process through user interface: Generally, test engineers want to run automation tests through the user interface. This entails connecting a mobile simulator to a backend server. This process makes the entire exercise considerably slower even though the initial stages may seem to be faster. If any error is encountered during the early phases, the entire workflow can get corrupted. To make matters worse, the testers continue to work on the system that generates false results thereby making the whole exercise futile and cost-intensive.

  • Don’t overdo things: There is a propensity among automated testers to create loads of tests, which ultimately turn out to perform the same stuff. Remember, more the number of tests created, more will be the efforts that go into maintaining them. This may lead to inconsistencies and glitches to creep in, rendering the whole software test automation process a time consuming and expensive exercise.

  • Distinct processes for tests and development: The creation of an automated test entails processes like coding and recording the actions. While running such a test, there can be hitches like the identification of bugs at the initial stages. These bugs are then fixed by the developers, leading to a considerable delay in getting the first clean test run. Moreover, the clean test run can be deemed valuable when there is some regression. To avoid such a situation, it is better to create the test automation script at the beginning, especially at the story level.


Choosing any automation testing approach would need doing away with the pitfalls as discussed above. The entire testing exercise should be a combination of both automation and manual testing. It is only when test automation is implemented right at the beginning of the Agile based development process that the outcome can turn out to be free of glitches.

Discussion (0)