Common Test Automation Misconceptions
Until an organization successfully reaches the point of understanding the limitations of automated testing and setup realistic goals, that organization could exploit the benefits of test automation. Having a strong test automation strategy, alongside product development is one of the biggest achievements of an organization. Yet in the present world, many organizations take a step back from test automation due to common misconceptions attached to it.
In this Article, let’s discuss what are the famous misconceptions related to Test Automation and how these misconceptions put barriers to the success of test automation within companies.
Test Automation is better than Manual testing
First, let’s see the definitions of manual and automation testing. “Manual testing, execute test cases manually without using any tools and done by manual testers’ while automation, execute the set of instructions given and compares the actual outcome with the expected outcome.”
As per software expertise, test automation is checking of facts rather than testing. Test automation engineers write automation scripts / use test automation tools after understanding the application. Manual testing, on the other hand side, is an investigation activity where testers may find new information about the application under test.
Manual testing can be replaced by Automation testing
Achieving 100% test coverage is impossible by using any test method. Yet most of the people believe that test automation could cover 100% of test coverage. The fact any person should understand is, automation testing can be used to increase the test coverage. We can use more test scripts, test data, different configurations; yet, bringing out 100% test coverage from test automation is an impractical goal due to various reasons (example: Validate the look and feel of the user interface will be difficult , Complexity of the feature & How frequently application gets changes etc.)
Automation is the same as programming
Most of the testers do not like to get involved with test automation. They think automation is same as programming and do not involve since they believe they don’t have a talent in coding. Yes, a good programmer is typically good at factoring which definitely contribute in quality test design. Yet any tester can become good at automation scripting, it only requires programming discipline and continuous practice.
Higher Rate of Defect Detection through Automated Checks
As we all know Automation testing is well known for executing regression testing suites and there are circumstances where it finds good chunk of regression bugs. It comes handy when new features are introduced and the project requires to run a regression suite to ensure existing functionality has not broken. Although there are rich automation suites which covers complex scenarios with different data sets, it is unable to compete with the intelligence of human tester, who can spot unexpected differences in the application while exploring and executing a set of scripted tests against the system under test.
Also, Automated script always executes what automation tester scripted and execute in the same order, follows the same path. Hence as the time goes by number of regression bugs found by the automation suite can be fewer unless scripts are update by the automation tester.
We Only Require Unit Test Automation
Very common question that anybody gets is, why the Automation test can’t execute against the new functionality as it is being developed which means Unit Test Automation. Writing unit test is more like a responsibility of a developer. Until the planned functionality is delivered, Unit test cycle is repeated by the developer. The unit test is for finding programmer errors instead of failures. It contains high level aspect of testing that happens when all the components are integrated together to build a system.
With the feedback of the customers and due to unforeseen issues, there is high likelihood of the code being updated several times. Spending time on automating a not yet delivered function is not encouraged as there is high potential of rework.
Better ROI always come from Test Automation
Most of the time Automation ROI compares with Manual ROI and most of the people may think only the Automation for effective ROI. When it comes to ROI, there are two important things we should keep it mind. First one is some test cases should be manually executed and Getting ROI from Automation test takes longer than we think.
Even a fully functional framework is present, automation scripting initially takes longer than executing the same test manually. If we need to take quick feedback/ROI, validating it manually is usually faster than automating the test. So, the ROI depends on the situation and it is unfair to compare Automation vs Manually. However, the Automation ROI comes in handy when we need to execute the same tests regularly.
Conclusion
It takes time to develop and maintain test automation framework and scripts, yet, it is a long-term investment. Since it is not finished by one delivery, we need continuous monitoring and updating.
Instead of expecting the automation test to find lots of defects or targeting to replace manual testers, we must embrace the paybacks it has. Example: Use automation script to creating test data that can be used for manual testing. Clear knowledge about the test automation limitations and creating realistic goals is very important in overcoming these test automation misconceptions.
About the Author
Pivithuru Gunawickrama is a Senior Quality Assurance engineer at 99X Technology.