Will automation replace manual testing?
Hello, Habr!
I decided to write my opinion on whether the automation of testing will replace the testers themselves. First of all, because quite often I hear a similar opinion among the Junior QA, who is just taking his first steps in testing and is already afraid that he did not manage to do something.
In fairness, a similar opinion exists among older children. Quite often it is believed that automation is almost the only way to develop a manual tester. About all this and much more under the cut.
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 is the subject of a completely different discussion.
I have been working in testing for quite some time and have seen several stages in the development of testing automation. With her development, her attitude towards her 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, its first version was in use, 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.
I still remember that our boss called them “pokes”. Seeing how we sit and write these tests, he said so: again, write your pokes? Like, there wouldn’t be a long time to check and release.
But time passed, Selenium developed, he had new opportunities. At first there was a second, and now its third version. A standard appeared (browser manufacturers began writing drivers themselves), Selenium acquired 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 testing automation of both web and mobile applications.
Now it’s more than just poking, now the average conversation from HR to the QA position looks like this (exaggerated, of course):
- Good day. 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 do not hire. What if you don’t? Well this is some savings. Even after you write all the tests, you would be fired. And the developers, when they’ll do it all ... Leave on the site a single “Pay here” button and drop off into the sunset ... Something got me wrong.
Of course, with such trends, the question arises: will manual testing replace automation? And when will this happen?
To answer this question, it is worth first of all to think - and 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 occupation. And therefore they cannot devote a lot of time to it. Tests are written in haste and the code quite often leaves much to be desired. 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.
Consider 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 argue that 90% of developers who have fallen off 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. Some simply will not be taken into account. Anyway, "I myself wrote the production code, everything is reliable there and forever."
Equivalence classes, boundary values, negative cases - all this remains somewhere on the sidelines.
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 poke 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 bunch of ill-conceived test cases.
What conclusion would I like to draw 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. He still needs certain skills.
Manual verification will not go anywhere. One way or another, when we 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 verification 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 GPs, and they are valued higher in the market. But will automation replace manual verification and manual testing? Of course not.
This is how this article came about. I shared my opinion and my vision of the issue. I will be glad to know about yours, be sure to share in the comments!
And also, a colleague from Yandex developed an online course for those who would like to immerse themselves in the automation of mobile testing. Information and links can be found on my profile page. :)
Thanks for attention!
I decided to write my opinion on whether the automation of testing will replace the testers themselves. First of all, because quite often I hear a similar opinion among the Junior QA, who is just taking his first steps in testing and is already afraid that he did not manage to do something.
In fairness, a similar opinion exists among older children. Quite often it is believed that automation is almost the only way to develop a manual tester. About all this and much more under the cut.
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 is the subject of a completely different discussion.
Briefly about the 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 her development, her attitude towards her 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, its first version was in use, 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.
I still remember that our boss called them “pokes”. Seeing how we sit and write these tests, he said so: again, write your pokes? Like, there wouldn’t be a long time to check and release.
But time passed, Selenium developed, he had new opportunities. At first there was a second, and now its third version. A standard appeared (browser manufacturers began writing drivers themselves), Selenium acquired 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 testing automation of both web and mobile applications.
Now it’s more than just poking, now the average conversation from HR to the QA position looks like this (exaggerated, of course):
- Good day. 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 do not hire. What if you don’t? Well this is some savings. Even after you write all the tests, you would be fired. And the developers, when they’ll do it all ... Leave on the site a single “Pay here” button and drop off into the sunset ... Something got me wrong.
Of course, with such trends, the question arises: 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 - and 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 occupation. And therefore they cannot devote a lot of time to it. Tests are written in haste and the code quite often leaves much to be desired. 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.
Consider 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 argue that 90% of developers who have fallen off 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. Some simply will not be taken into account. Anyway, "I myself wrote the production code, everything is reliable there and forever."
Equivalence classes, boundary values, negative cases - all this remains 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 poke 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 bunch of ill-conceived test cases.
What conclusion would I like to draw 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. He still needs certain skills.
Well, what about manual verification?
Manual verification will not go anywhere. One way or another, when we 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 verification 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 GPs, and they are valued higher in the market. But will automation replace manual verification and manual testing? Of course not.
Total
This is how this article came about. I shared my opinion and my vision of the issue. I will be glad to know about yours, be sure to share in the comments!
And also, a colleague from Yandex developed an online course for those who would like to immerse themselves in the automation of mobile testing. Information and links can be found on my profile page. :)
Thanks for attention!
All Articles