How to decide which tests to automate

I passed my driving test on the second attempt. My first attempt was a failure when I pulled out in front of a BMW. Which makes a change, I guess.

I remember the days following my success; I wanted to get a car of my own immediately and drive anywhere and everywhere in it. For too long, it restricted me to driving my instructor’s car around town centres like someone trying to locate a car parking space on a busy Saturday afternoon.

I wanted to use this new skill that I now had, and I wanted to apply it to everything.

But then I saw the cost of a car, insurance etc so I decided that I should just get a bike instead.

This urge to use a new skill can be like how we feel about test automation.

From unit tests, API calls to using a tool like Selenium and making it look like our application is being used by a ghost. Automation testing is not only cool, but having tests run by the computer can save us serious time and money.

But before you automate all the things.. ask yourself the below questions.

What should test automation do?

Converting a manual test into an automated test needs to be treated the same as a development project. And should start with a specification.

• What are you trying to achieve with your automation?
• What kind of feedback are you looking for?
• What are the inputs/outputs?
• Who will use it?

Answering these questions will give you a plan of what to develop and allow you to design your strategy around your answers. Instead of moulding your strategy around your tests and then ending up with something hard to maintain and hard to use.

Start simple

Automated tests are best when they’re simple. So start there.

Instead of automating a large end-to-end scenario that takes 10-15 minutes to run, can we break it up into smaller sections?

Splitting up your tests like this into smaller sections will really help if your test encounters a bug, and it requires a ticket for the developers.

Does it add value?

This is the most important question that you need to consider before automating any of your tests. Because otherwise, why are you automating it?

Automated tests should add value to your overall test strategy. Whether it’s saving test execution time, providing you with insight, or allowing you to increase your test coverage.

You should never automate a test that takes a half-hour to run manually but is only run once every month for example.

Is a report generated? Who should see it? Consider these questions amongst your team before starting.

What is the lowest level that you can go to?

Test automation is not just Selenium.

The above is a version of the automation test pyramid (there are others and different types).

The bottom level is your unit tests, which are bits of code that test the code you have written. You can find out more about unit testing in this blog post.

Then there are the service level tests or API tests. An API is essentially an interface for communicating with your application.

So, in the example of a banking application. The GUI of a web app (the layer you see on your screen), will most likely be communicating with the API and instructing it to fetch the information that you want to see on the screen from a database.

We can use an application API in our automated tests, and the advantage of this is that we are separating the GUI layer from the application logic.

At the top, we have the GUI tests, which are tests then deal with the presentation layer of the application and is often referred to as the front-end of your application.

Writing a test for this level is useful if you want to test the functionality present at this level.

The pyramid itself can guide you in your automation strategy and if you automate a test on the GUI layer, ask yourself, is this the lowest I can go?

Will it be better if this was a unit test? Or an API test?

If speed is a serious factor for you to consider, I recommend going as low down as possible.

• Category: Software Testing