Test Automation. Stop Asking Why, Start Asking What

Test Automation. Stop Asking Why, Start Asking What

Just because you CAN automate an application, doesn't mean you should.

Easier said than done right? Especially when you take the rather well-known benefits of test automation into account; speed, efficiency, reduced feedback loops, increased ROI, reliability, re-usability, accuracy and improved coverage.

With all those benefits, it’s hard not to automate everything, but this solution is not an effective test management strategy and will work out expensive in the long run.


Take your time

Automate the right test at the right time, to improve test coverage significantly. This will allow you to catch bugs early on, improvising quality for a faster release.

So let’s go to the big question…

What should you automate

Certain processes are more useful than others:

Regression Testing ensures older programming works when unwarranted revisions are triggered by adjustments in code, resulting in software regression. The intention is to catch bugs inadvertently released into the system, as a result of upgrades or patching.

These tests are frequent during the cycle, ensuring that any application code changes, (no matter the significance) do not brake application functionality entirely.

QA time is increased thanks to regression testing, allowing for checks into a variety of changes, leaving more time for conduct exploration of unusual cases in the production environment.

Functional Testing validates the core functions of a product, focusing on what the application does and it’s relation to the user.

This type of automation compliments the performance of Agile teams, making it easier for testers to automate by setting developer-independent benchmarks for performance.

Not all functional tests are ideal for automation, for instance, if the testing you require is highly dynamic, then the scripts will be invalid. If the volume of test cases are high, and those cases are continuously regressed, then this form of automation will not work.

Balance between manual and automated testing is the answer to achieving your desired outcomes.

Smoke, or Build Verification Testing, (also known as Sanity Testing and Confidence Testing), is one of the fastest ways to make sure that the most important functions work. It also ensures the build is stable, before going through further testing.

If you want to find the most obvious defects, this automation is your answer. For frequent builds, automating Smoke can help in finding bugs and defects early on.

Performance Testing is an intense exercise, ensuring products withstand expected and unexpected workloads. Speed, response, scaleability and stability depend on load conditions, deciding the performance of an application.

Performance issues can cause complications, because even if the application meets all the functional test criteria, it could still fail in delivering the desired output, (in terms of user experience). This is because, it might not be able to handle the varying degrees of transactions, nor be able to manage a large number of users, resulting in a crash.

Performance testing is advised early on in the quality lifecycle, addressing it at code level, in tandem with development for both newly developed sprint features, and larger system integration testing.

Unit Testing involves the testing of code in fragments, so that code performance can be reviewed from a granular view. These sections of code are isolated to verify and validate their behaviour to prevent defects in regression, increasing the developers trust in the code.

Manually doing this is very time consuming and cost intensive, not to mention potentially error prone. Automating is a key component to the Continuous Delivery paradigm.

Ideally, the test suite should run automatically every day, for full optimisation. This means source code remains healthy through changes in existing code.

Integration Testing ensures that the application works, and is usually performed on two or more systems that work together where coupling is required.

Due to the layered testing required by Integration testing, automation is recommended to save you the complexity of manually doing this, as well as cost and time. This is why such testing is used for complex applications, identifying defects, and ensuring there are no unwanted surprises when all elements are put together.


Sure, Test Automation is ideal for a number of reasons, but when might it not be?

Manual output is required for certain application functions which are subjective to validation, such as usability etc. For strategic development app functions, manual testing may be needed for attention to detail in certain areas.

Applications and functionality deemed complex, may require a combination of manual and automated testing for a better outcome.

Exploratory testing involves concurrent test case execution and design, where the tester creates the idea to explore the system, giving direction to create practical tests for app testing.

Random tests (or Ad-hoc), are necessary when domain expertise are required, this applies when tests need to be run urgently, and so are best done manually.

When outcomes are unpredictable, validating automatically needs to have predictability in order to pass or fail; manual testing is better in circumstances such as this.

Successful testing, is as a result of both automation, and a suitable test management strategy. High quality releases are not accidental and require careful planning with the right set of tools to aid the process.


Reader Interactions