When we talk about test automation, we should consider it as part of testing itself; we know the existence of functional testers and automation testers (You can read about SDETs, SET, DevTest, and other QA roles in this post).
Test automation was a game-changer. The ability to run many test cases automatically and conduct so many validations makes it a great “ally” for testing. That was the main goal, helping testers focus on the essential tasks.
Many companies are currently requesting testing that is 100% automated. We rely on automatic checks over and over and wholly misplaced testing activities such as exploratory testing, ad-hoc testing, or mob testing. If we want to succeed with our testing approach, test automation must help us to deliver faster with high quality.
Test automation and the temptation to automate everything
Consider the act of clearing a minefield; if we have the automated test suite running over and over again, we won’t find any new mines in the grass, unless we introduce variations for the test to recognize.
We must consider some critical points when we do test automation.
Weigh the cost of test automation over other options
Test automation can help us speed up our testing activities, but that speed comes at a cost. We must understand different aspects like the cost of automating, time constraints of the project, resources available, etc. Keep in mind other testing options (Exploratory Testing, Mob Testing, Pair Testing) and most importantly, don’t automate tasks that will not have to be repeated.
Plan for test automation maintenance
Maintenance costs grow as the set of test scripts increase. In my experience, I have noticed extensive test automation suites, including thousands of test scripts (Parallel Testing could help here).
My recommendation is to keep your test automation design simple. Avoid flakiness on your test scripts and try to implement an intelligent element selection strategy or take advantage of AI and intelligent selector functionality (Auto-healing).
Don’t run automated tests too soon
An important aspect of continuous testing is testing early. However, testers can begin too early, especially if the application is not ready and we are creating tentative test scripts. If you start automating from day one, you’ll spend too much time shooting at a moving target. Avoid this waste of time and focus on your Test Automation strategy at the right moments.
Over-automation can kill your delivery
Avoid the temptation of automated everything. As mentioned above, automation must focus on repetitive tasks and risk-based scenarios, but we cannot entirely rely on it.
Test automation can be a powerful ally during our agile testing. Always keep looking for opportunities to save time for functional testers. In response to the minefield analogy and repeated checks, we must use Exploratory Testing to capture other business scenarios or corner cases.
Keep in mind that all testing may be exploratory. Currently, not all testing is done exploration first. Not all testing focuses on learning as much as proper exploratory testing does.
Codeless / Low-Code Testing
Codeless test automation helps to create automated tests without the need to write codes. It could be tough to assimilate for some automation testers.
We should try Codeless / Low-Code testing as it can reduce time spent testing, allows the test process to adapt to agile and DevOps requirements, and enables faster information on the business risk associated with a software release.
We must avoid comparing handcrafted test automation (creating our test framework from scratch) against Codeless / Low-Code test automation advantages.
Test frameworks are built by analyzing the purpose of automation testing for the project. To be more specific, it is the working style of writing, running, reporting, and maintaining the tests. As part of an Agile team or QaOps approach, if we can deliver our products/services faster using codeless testing tools, we should try using those first.
The same as defining which programming language to use for our test automation framework, we could take advantage of codeless testing tools.
Remember, test automation is the process of performing software testing activities using testing automation tools with little or no human interaction to achieve higher speed and efficiency. So basically, these testing automation tools can be scripted or codeless.
When we learn about test automation, we try to automate everything we can. In the paper, automating our testing duties frees us up for other valuable testing work. But in practice, it rarely works in that way. My recommendation to all automation testers is to focus on repetitive tests and risk-based test scenarios.
More test scripts mean slower execution time and more time spent in maintaining those test scripts. Take advantage of codeless testing, and let’s try to perform test automation smarter.
Happy Bug Hunting!