Test Automation Is Needed But Not As Magic

Why Automation?

Just imagine the life of a financial accountant without a Calculator or any tool which helps in calculating. They need to calculate everything manually and they need to be like Shakuntala Devi. Chances of committing a mistake will be higher and time and effort will be more.

As Technopedia, “Automation is the creation and application of technologies to produce and deliver goods and services with minimal human intervention. The implementation of automation technologies, techniques, and processes improve the efficiency, reliability, and/or speed of many tasks that were previously performed by humans.”.

William Landay quotes “The human element in any system is always prone to error.“.

An autopilot is a system used to control the trajectory of an aircraft, marine craft or spacecraft without requiring constant manual control by a human operator. Autopilot does not replace human operators. Instead, autopilot assists the operator’s control of the vehicle, allowing the operator to focus on broader aspects of operations.

Why do we program? It is faster and efficient to fill an online form rather than a hard copy form where no auto checks are present. It is good to automate or program repetitive tasks. You may calculate 2+2 = 22 but a calculator will never. Don’t program to breathe and eat automatically because it is repeatable. I love to eat manually.

What is Test Automation?

Automation is everywhere. It is done:-

• To minimize manual intervention
• To perform repetitive stuff
• To increase efficiency
• To reduce cost** – It may be costly as well in some scenarios
• To reduce effort and time
• To reduce the chances of committing errors
• To gain reliability
• To speed up
• To extend coverage

Let’s talk about Automation in testing.

First of all, Automation testing is not a replacement for manual testing. Both have their own importance and together we can deliver a robust product. In agile methodology whatever framework we choose, we get frequent build or builds with new and extended features. We generally need to test those new features and enhancements or bug fixes in existing features in an ongoing sprint. But we also need to test impact areas and old functionalities as part of regression.

Every time it is not possible to find all the impact areas. You never know how developers have made changes. Functionality may not impact another functionality directly or indirectly based on the requirement but the developer made changes to a method that also handles another part of application that may break that part. So regression is needed in all sprints. In the beginning, performing regression of features manually will not be a problem but a growing number of sprint will make it as regression suite will be increasing.

Testing the same regression suite manually may not be effective and we may miss bugs as we test them in more comfort zone. If we could automate those or most of those checks then it will be good. We can save a lot of effort and time as well. We may be get an overall idea if application is nearly stable at en dof the sprint.

Automated testing can be helpful for testing a data-driven application. It may not be possible to test the same flow with multiple sets of data manually. Functionality may behave differently based on input data.

You will see that many agile methodology based projects have replaced manual regression completely with an in-sprint automated suite. The last day of a sprint that automated suite is triggered and results may be a shock for developers or testers and most of the time I see it is for testers because of flaky tests.

Test Automation is NOT Magic

Remember “We are writing “Code” to test other’s “Code”. I believe “It takes a lot of iteration to get confidence in your automated suite”. Till the day you convince everyone including yourself that a failure in the script is due to a probable bug in the application, your automated suite is not effective and this is the place where “Automation Testing” fails. When we run automated tests frequently and observe when and where scripts fail and fix them or add extra checks that increases the robustness of automated suite.

People think that if there is a requirement change or addition of new features in the application then we can get all broken old functionalities after running automated scripts. Automated scripts may also need an update as that is also code. A developer also does the same thing. Developer code to develop a functionality and tester code to test that functionality. I have seen many examples where top-level people in a project think an automated suite as magic. It is not at all correct.

Automating tests may not be an easy task or maybe proven costly if not done properly. Delivering a flaky regression suite at the end does not add any value and requires a lot of mainteance, execution time and effort.

Too many automated tests is not a proof of good test coverage. Automated checks may miss the broken functionalities or bugs if you don’t have proper assertions or checks. Flaky automated tests can not give a confidence during CICD to revert a build on failure. A robust automated suit helps in the maintenace of product after go-live. If automated tests are being scrapped once product is go-live, then there should be a rethink on the adoption of automation testing.

This is a debatbale topic and views varies person to person and I would like to hear that from you. You can always comment below.