Automated testing is gaining popularity with each passing year. According to a report from Global Market Insights, the automation testing market is projected to grow by 15% between 2023 and 2032.
With the advent of interest in automation, various tools and platforms have been introduced to support the increasing craze of automation testing. Suppose you google "benefits of automation testing". In that case, you'll find a dozen web articles going on and on about how fast and competent it is and how much you'll benefit from adopting automation to your system.
But have you ever stopped for a second and wondered, "Is automation always the right path to move to?" or "Is it really that fast compared to manual testing?" Well, truth be told, your question has a conditional answer.
"Is it fast?" Yes
"Is it always fast?" Hmm, not really.
"Isn't speed the main idea behind automation? Why isn't it always fast?"
Well, let me introduce you to the paradox surrounding Test Automation.
The Paradox of Automation
The meaning of 'Paradox' is having contradictory behaviors. Automation is usually associated with the speed of delivery compared to the time a tester takes to test manually.
Automation testing uses scripts and codes to test scenarios. They help to execute tests more quickly, especially during repetitive and regression testing. However, these test scripts require a certain level of expertise on top of the additional time it takes to create them from scratch. Even the best indestructible machine will break down without proper maintenance.
Test scripts are no different. They need to be constantly revised and maintained to keep up with the newer development phases of the application. They pair together to create the paradox of test automation.
Automation is built around the idea that the automated system will decrease the involvement of people. You have probably heard people say, "AI will rule the world", or "Automation will take away your job in no time", hinting towards human wipe-out.
However, the more efficient the automated system is, the more significant becomes the involvement of humans. Even the most efficient system is bound to break at one point. If skilled personnel is not present at such times, it can lead to multiple errors and a huge loss for the company.
Looking up "automation failure that costs companies billions" on the internet will clarify the damage that can happen when the automation system is not maintained properly. Big companies like Amazon, Dropbox, and Gmail have been major victims of it.
Effects of the Paradox in the Life Cycle
Automation testing requires a big investment, be it in terms of skilled workforce, time or capital. In addition, selecting a suitable framework for your company or project also takes a lot of research, time and expertise. This excludes the large portion of the SQA engineer's time taken up by its maintenance in the latter phases.
New features and builds are released quicker in companies that have adopted agile development methods. As an SQA engineer, with the introduction of new features, you need to develop new test scripts to accommodate them.
Ironically, the more tests you develop, the lesser time you have to develop more test scripts. You either focus on developing new tests, making the former test cases unusable, or maintaining the created test cases relevant to the new releases. No matter the event, you do not have time to build new test case scenarios.
Boris Beizer coined the term 'Pesticide Paradox' in Software Testing Techniques [2nd edition]. It describes the phenomenon where the more tests are done, the more ineffective they become. In other words, the more you automate, the longer it takes to maintain them. As a result, you have less time to automate.
This creates an infinite loop that you can not come out of easily. As you develop additional tests, the burden for its maintenance will increase with it. If you keep on maintaining the created tests, you will need more time to develop more tests to deal with the newly released features of the application.
So, either you get stuck developing more tests disregarding your past test scripts, or you get stuck maintaining your developed tests, such that you have no time to develop more. Thus, keeping you in a constant loop.
Overcoming the Automation Paradox
There are many paradoxes surrounding test automation, excluding the few I have mentioned above. The idea of testing the overall app is paradoxical in itself. As we all know, testing is endless, and an application can never be 100% bug-free. Paradoxes start to engulf test automation, especially when the same test and the test data set are reused repetitively.
In my opinion, one can never get out of this loop. However, there are some ways to decrease its impact and maintain the quality of the automation tests created. For instance, you must be continuously in the loop of application development. You must sanitize and review your codes religiously and, most importantly, write reusable codes.
The tests you write shouldn't break after every update or new release. You have to lessen the time you revisit the tests but review them constantly so that your old tests don't break while simultaneously ensuring that you include all test scenarios that could potentially find bugs in the system.
Final Say
Test automation will always be engulfed in some paradox, one way or another. Adapting the test automation framework is less of a "Yes or No" question and more of a "How to integrate and maintain the automated system?"
Along with the few paradoxes that I have mentioned in this blog, there are many more scenarios that you have to check out first before adopting an automation framework. Be it the size of your QA team, the skills of your QA team, or even the SDLC adopted by your company. Hence, before adopting any automation framework, you must watch out for all the criteria that could engulf and overwhelm your QA team.
Hope you found this read helpful. Subscribe for more!