What to Automate and What not to Automate?

The one obvious question that comes up to the mind is, can automation testing remove all the manual efforts? Can we automate everything and end up with no manual testing?

Clear answer to this is, though everything can be automated(except few odds), but what value we get from automating it should be the decisive point in what to automate. Some tests can be take more time to automate than to develop that feature, some may require lot of maintenance and few tests can give you more confidence if tested by human intelligence.

Below are some generic guidelines that can help you to choose and understand what to automate.

Repetitive tests:

We should automate tests that are repeatable or often used across projects. Test cases that needs to be tested every time after change in the code would be suitable for automation. Repetitive test cases can be automated and run as part of build pipeline, which will reduce the repetitive efforts made for testing.

Stable functionality tests :

One key feature to note while picking test cases for automation would be stable tests. This would be hard to do in the agile world of testing. We often check for regression impacts on the existing stable functionalities as part of regression testing before any major release. Automating these tests would assure you that the previous functionality is retained. If there are numerous changes in a row for a particular feature, we can easily catch any bugs without testing it manually.

Deterministic result:

Picking up test that would either yield a pass or a fail. Testing is complex, so picking up test that would either result into a pass or a fail would be the right approach. Most of the test cases either result into a pass or a fail, but complex products might result into scenarios where the result is uncertain. So avoiding these areas will help you build a reliable automation suite.

Similarly beloccxzw are few tests which we should avoid from automating.

Dynamic UI:

We would not want the efforts put down to build an automation framework go in vain when the UI changes. This is the least that an automation engineer would expect. If the user interface of the product keep changing it would not be worth spending time on automating the tests, the goal of automation which is re-usability is let down. As we know building an automating test-suite would need a good amount of effort, so we would never want to rebuild the same automation suite after the UI has changed. In such scenarios automating the back-end services which are not altered frequently would be a right approach. Options can be like API automation.

Both automation and manual testing work hand in hand, to achieve a common goal of quality assurance. Automation should be to allow manual testing focus more on exploratory and intelligence testing. So start and continue to automate tests, but only after analysing value it returns and how much it helps to manual testing instead of replacing manual testing.

What to automate also majorly depends on how you automate it. You can find helpful guidelines on that in our below blogs.

24, January - 2022

Try it now for Free