What are the benefits of automation?

Reading Time: 6 minutes

I was thinking on an idea about an article related to testing and software development and their relation to automation. I still think I will go for it, but while thinking about it I got another idea.

I was provoked by one of these articles on LinkedIn that seem to have a catchy heading but turn to have dubious content and expresses questionable assumptions.

In that specific article (I won’t link it, not because I don’t respect its author’s work, but simply because I find a lot of the assumptions in it wrong, and I won’t share misguiding content with my audience), the author was expressing one of “the evergreen” misconceptions about automation and testing and it sounds like this:

“The Automation Engineer simply seeks to automate the repetitive and tedious tasks of the manual tester so that they are performed, without assistance, by a program.”

Like it or not that’s the “definition” that you will hear rather often when you ask people what’s the purpose of automation or why would they like doing it. And it’s…WRONG!

If you are curious why I think it’s wrong, you can look at the following resources:

https://mrslavchev.com/2016/06/14/test-automation-the-bitter-truth/

https://mrslavchev.com/2017/01/09/the-non-manual-unautomated-tester/

https://mrslavchev.com/2018/02/07/hindsight-lessons-about-automation-why-automation/

https://mrslavchev.com/2017/11/23/the-missing-link-between-testing-and-automation/

and a small note on that “manual” testing part
https://mrslavchev.com/2017/12/11/manual-testing-never-existed/

As you can see I as anyone have my fair share of rants discussing why we shouldn’t put all our eggs in a basket called “test automation”.

Anyway, I am a firm believer automation is useful, it’s a tool that can extend our reach, but only if we know how to use it. And we can only know, if we understand our basics very well. And statements like the above show a significant problem with the basics – why is automation useful.

So, in order to assist other confused people, I decided to take a step back and spend couple of minutes in thinking out loud – what are the benefits of automation and why should we use it and appreciate it?

Tedious tasks, they say

Let’s clear this out once and for all. If you ever feel that your job is tedious and boring task, then quit it. You’re simply not a good fit for it. If you feel bored, because you must repeat same task over and over, then don’t – come up with a new approach, think of new scenario, prove repetition is inefficient in that manner.

Software testing is a game of creativity, curiosity, experimentation, excitement, despair, anger and many other feelings, tangled in order to find answers, no activity aiming for that could be boring.

Anyway, you can make it boring by writing test cases and following them blindly, leaving your critical thinking behind, or even worse, following someone else’s scripts without questioning and a sign of reason. This is not software testing, it is mediocre testing and trying to automate mediocre testing doesn’t create testing excellence, it creates automated ideocracy.

What is the true purpose of automation?

To help that, let’s look at some forms of automation that we take for granted – the car, the washing machine, the airplane. If they were simply “automating tedious manual actions” we would currently have carriage with robotic horses or robot performing human washing of clothes or flying machine that’s flapping its wings. Anyway, none of this is the case. Instead – a smarter, more creative, more efficient technological approach is used so that we can get the same result.

My humble opinion is that automation is simply a hygiene necessity, in the same manner that brushing your teeth twice a day is a hygiene necessity. It doesn’t mean you will never ever have to visit a dentist if you brush your teeth, but it will help you not spend additional time with the dentist.

In the same manner – automated checks are not going to help you omit testing, but they will be an additional resource of information, that we value so dearly.

But what sort of information?

The known knowns

Not too long ago, I gave a presentation that was called “Hindsight lessons about UI automation”, where I showed this diagram.

In short – testing in general is the quest for knowledge, about the product.

Knowledge comes in couple of different shapes:

• We know things that we know – some of it is necessarily wrong, regardless if we know it or not. I believe if we are clever enough, we at least suspect it.
• We don’t know things that we know – I believe we can translate this as “tacit” knowledge, the one that we do intuitively or at least without giving it explicit meaning or definition – like bike riding or writing on a keyboard.
• We know things we don’t know – and we normally try to attack that area, so we move it to the area of known knowns.
• We don’t know things that we don’t know – and this is the vast ocean of ignorance, lack of knowledge or expertise out there that we might bring closer to our scope or leave it there forever.

The funny thing is – automated checking lives in the part that we know we know. For various reasons, we can’t automate tacit knowledge, we can’t automate stuff we don’t know either. Therefore, automated checking helps us check the validity of already known facts. Which is not that bad after all.

In the life span of a testing project the information grows almost exponentially, the last day you are testing you will probably be facing times much more known knowns then in the first day of you testing. It really helps to have a mechanism that gives us fast feedback that what we already know is still there, still intact, nothing exceptional. Think of it as a software representation of a minesweeper – it will run forward for you to inform you about mines, so you don’t step into them. In the same manner, the automated checks will run to confirm facts that you already know, so you don’t have re-interrogate the system every time yourself. Not that you can’t, but it’s not what you want to be doing.

You can also think of it as a prerequisite for testing – a tool that make sure the system is OK-ish enough to start testing, so you don’t have to waste time to report bugs like blank pages, 500 errors or similar.

Surprises, we only call them like this when they are pleasant

If a surprise is unpleasant, we call it a problem. And we don’t want problems in our product. Therefore, we are ready to use any given opportunity to track and remove unintended changes. This is where automated checks can be very useful as well, being a proactive change detector.

You might want to track changes for various reasons:

• You are in intense refactoring/change phase, where risks to introduce bugs or regression bugs is high.
• You are in a team that simply doesn’t communicate quite well, people make changes without letting you know.
• “Changes” that are unexpected might have large impact on clients or testing or the duration of testing.

Predictability

When I run the vacuum robot cleaner in my living room, I don’t just do it because I want to replace my hand-held vacuum cleaner. I often do it, because it’s very predictable, it uses same algorithm over and over, it cleans rooms in the same order, starting from the same starting point. I know for sure it will clean the floor of the apartment for about 38 mins. Note that I said the floor, not the windows, not the sofa, not the dust on the wardrobe or the spider web over the bed, just the floor. It also doesn’t know anything about risks and unexpected occurrences like a pigeon that flew into the room and make dirt on the floor or a domestic animal that will start chasing it or sit on it. I mean, throw a sock in front of that robot and it’s dead, forever, until you take it out of it.

With all of that, I wanted to give a clear picture about one thing – I run the robot, because it’s simple and predictable, but it’s also very primitive. You can’t expect it to take care of everything, but that’s OK, if you don’t expect it to fly to the sealing and clean spider webs.

It’s simply not enough

As you see, automated checking is a good thing, after all. It is useful, when used as a proper tool, but it’s simply not enough. It lives in that small quadrant called “known knowns” which is also very problematic:

• It’s very small bit of information, compared to all the other ones.
• If the things you know are wrong, you practically know shit.
• It becomes irrelevant quickly if you don’t update it.

In other words, everything else besides the known knowns and even themselves, require exploration – the thorough art of gaining knowledge, modelling, questioning, asking, arguing, refuting, rethinking, refining and rediscovering new information that might be vital for your testing. And this is a task for you, my friend, you and no one else.