We decided to write our opinion about the thinking, that the automation of testing will replace the testers themselves. First of all, because quite often we hear a similar opinion among the Junior QA, who is just taking his first steps in testing and is already afraid that he didn’t manage to do something.

Frankly speaking, a similar opinion exists among experienced testers too. Quite often it is believed that automation is almost the only way of development for a manual tester. About all this and much more in our article.

A little clarification before we begin. All the discussion below will be about functional autotests. These are UI tests, which should not be confused with unit tests in this context. The latter have always been written and should be written by developers, and where this is not so – it is the subject of a completely different discussion.

Shortly about history of automation

I have been working in testing for quite some time and have seen several stages in the development of testing automation. With its development, the attitude towards it also changed. Let’s see how it was and try to understand – what is all this going to?

Back in 2010, when I was just taking my first steps in the IT world, not everyone knew such a tool as Selenium. At that time, in use was its first version, which was called Selenium Remote Control.

I remember how we automated our first project on Selenium. This tool was then quite simple, it could click on invisible elements, sometimes it was mistaken in finding locators and even when receiving text of some tricky elements.

But time passed, Selenium developed, it had new opportunities. At first there was a second, and now its third version. A standard appeared (browser manufacturers began writing drivers themselves), Selenium started to have several protocols, acquired competitors in the market, and now almost anyone working in IT knows about it, regardless of whether it belongs to QA.

At the moment there are many solutions for automation testing of both: web and mobile applications.

Now it’s much more than before, now the average conversation between HR and candidate for the QA position looks like this (joke, of course):

– Good afternoon. According to your resume, it’s not clear. Can you write autotests?

“No, but I’m good at …”

– * already hung up *

And if this is a lead position, then you hear that they would like to first set up automation, and only then hire QA engineers. Or don’t hire. What if it’s not necessary? Well it is kind of savings

Of course, with such trends, arises the question: will manual testing replace automation? And when will this happen?

Autotests through the eyes of developers

To answer this question, it is worth first of all to think –  who writes autotests? I saw companies in which autotests are written by the developers themselves. And I saw companies where QA engineers write autotests. What do you think is the fundamental difference?

I would like to assume that the difference is in the code. Like, since they are developers, they write code better. Therefore – their tests are better. But it is not so.

The quality of the code is undoubtedly an important parameter, but for the developers themselves, testing is not the main task. And therefore they cannot spend a lot of time for it. Tests are written in haste and the code sometimes is really bad. And this is a normal situation, I repeat – this is not what they should spend a significant amount of their working time on.

Especially good code is not the most important thing in autotests. What is more important is what cases these autotests cover. And here the thinking of a QA specialist is already significantly different from how the developer sees the product.

Let’s have a look at an example. It is necessary to cover the registration on the site with automatic tests. It is clear that in the first place we will cover a positive case. We went in, scored a form of five or six input fields, went through some additional steps like confirmation via mail or SMS – the test is ready, you are great!

I am sure that 90% of developers who have got the responsibility of writing autotests will stop there. They will not describe part of the cases because they consider them to be essentially no different from the one already covered. To part simply will not be paid attention.

Equivalence classes, boundary values, negative cases – all of this stays somewhere on the sidelines.

QA Engineer Approach

The QA engineer takes a different approach. He has experience, an understanding of the principles of test design, a sufficient amount of time and, most importantly, to look for bugs and to verify it is his direct responsibility. Plus, most often, such people are just interested in checking something. What happens if you click here out of turn? And if you enter the data here incorrectly?

It is the approach that distinguishes the QA engineer from the developer. And it is formed not by the ability to automate testing, but by a way of thinking. A bad tester will write bad tests. In this case, a good tester will find more problems with manual verification than a bad one with his huge amount of ill-conceived test cases.

Which conclusion would I like to make from this? Everything is very simple. A QA specialist is primarily an understanding of the principles of testing and the testing experience that a person has. And not the tools that he uses.

Of course, just being a good tester is not enough. Without knowledge of the basic tools, such as bash, Git, SQL, etc., it is impossible to work effectively in any company. They must be studied.

Automation is the same tool; it alone is neither good nor bad. It will not make your work more effective simply because you picked it up. You still need certain skills.

Well, what about manual testing?

Manual testing will not go anywhere. Anyway when we will see a new feature or an entire product, we will study it with our hands. We still need to figure out how it works, which cases to consider priority and in general, whether they work now. What is the point of rushing to write a test if the product is broken?

And so it will always be, with each new feature or change made. First there will be a manual testing step. And only then – coverage or updating of tests around it.

Would it be better if manual testing and writing of autotests were performed by one specialist or shared responsibilities? I don’t know, it already depends on the features of how the process is built in your company. Somewhere it will be efficient and therefore beneficial. And somewhere – no.

So to the question whether it is worth studying test automation, I categorically answer yes. The QA engineer must be familiar with automation. Usually, specialists with this skill have more in CVs and better salary, and they are valued higher in the market. But will automation replace manual checks and manual testing? Of course not.