In this article, I will share my opinion on why it is worth going exactly this way and what will happen if the automation comes differently.
Disclaimer: I do not want to offend any of the testers with my article. I really respect the “handbrake” and I began my journey with manual testing.
I have been working as the head of the testing department for about two years. Recently, a lot of automators have come to me for interviews, who do not have a base in testing. They have experience in automation as such. But in their work, they always rely on someone else's test design (made by “hand-helds”).
In an ideal world, these skills correspond to the task: functional testers work out test cases and actually formulate tasks for self-tests. The machine needs to describe what he sees. But on real projects, the automation engineer has to go a little deeper into the essence of the matter. If the task requires some design skills of its own, an automated testing machine without a base will prefer to do everything on a whim, simply because it seems right to him. Often this leads to the fact that some cases are checked twice, while others are not checked at all.
I repeat, I do not want to offend anyone. But the abundance of such candidates made me weigh once again what factors are important in the work of QA. And here three conclusions beg:
- on real projects, the automation engineer needs the skills of a “parking brake”;
- The “handbrake” that is developing will sooner or later leave manual testing, possibly into automation;
- the path from the “handbrake” to the automation tool is the path to greater independence, which correlates well with the remote work format.
I will dwell a little more on each of them.
Why does the automation need a “parking brake” experience?
As I already noted at the very beginning, the automator needs some theoretical basis. But I'm not talking about any particular education. Need experience in the practical analysis of real applications.
To test the next feature, which is being prepared for production, functional testers analyze the specification in an attempt to close most of the cases. They learn to cover the maximum number of cases and possible problems with minimal time (both their own and, relatively speaking, processor). In testing, this is one of the basic skills - like walking. And as they say, if you don’t know how to walk, you won’t be able to play football (automate).
An automation machine that has passed the manual testing phase often can simply write code. But this is not enough. And in a nutshell you can’t explain the whole missing base. To get it, you need to turn to the side of functional testing, no matter how strange it may sound. We are primarily testers, and only then automation engineers.
Is it worth the handbrake to go to automation?
At one time, automation attracted me with the fact that, unlike manual testing, the tasks in it are not so uniform. In the role of a parking brake, I was bored. I always wanted to do something to reduce the routine. And from automation I got high.
As a handbrake, I started using the Selenium IDE (in my opinion, he is still alive), which allows me to record manual actions. He automatically formed a kind of script from them with automatically found locators. When I experimented with him, everything looked rather clumsy, sometimes falling, but it was Selenium IDE that prompted me to think: why not write something yourself? I realized the idea in my master's work, and then I went to work as an automaton.
The path from the “handbrake” to the automation is one of two possible. This is a technological branch development. As you upgrade your skills, you get closer to development. In the same way, you get into the code, only, in my opinion, it is even more interesting than development.
The second way is to go along the managerial line: to become a QA-lead, then go to manage the project, etc. Here you need to pump already business skills, learn to look differently at projects and testing in general.
There is no third way - only beyond QA. If you continue to develop, you will not remain in manual testing - you will rest against the ceiling of tasks. Yes, you can pump, for example, as a specialist in testing the “white box”. But with a probability of 99% at some point, it will become more interesting for you to do something outside the scope of the test documentation. And either you will choose one of the two paths mentioned above, or you will leave testing altogether. For example, you will be carried away by some infrastructure tasks, as a result, you will develop already as devops. And those who do not notice or ignore in themselves this desire to go further, in my experience, quickly “fade out”.
By the way, and salaries, that of automation, that of managers are higher (this is if we recall the material side of the issue).
However, no one says that manual testing should be gone once and for all. I myself sometimes like to poke something: to read the specifications, to do the good old test design - to help the guys from my department. As I said above, we are primarily testers.
From the “handbrake” to the automation - the way to udalenka
Since I had the opportunity to work in different sectors of testing completely remotely, I want to share my experience here too. The “handbrake" and the automation system have a slightly different task pool, which makes them feel different in the format of remote work.
“Handmen” is probably a little more difficult to find a remote job. There are a lot of vacancies, but the competition for them is rather big - there are more good hand testers than good automation engineers. But even if the desired work is obtained, manual testing involves constant communication with colleagues. In the process of writing test documentation for someone’s specification, a lot of questions arise: to the analyst, to the developers, etc. A manual tester has to look for people and ask them how this will be implemented. It’s easier to work somewhere close by in order to be able to come and chat in person.
Handbrake can work remotely if the project has well-built communications or a team is completely distributed, when no one has an advantage in communication. Otherwise, it will be difficult to reach someone in the office. Office colleagues can simply go into the meeting room and return in 2 hours. You’ll try to reach them all this time. It’s much harder to forget about a person live.
Automator in this sense is easier. His tasks are decomposed: sit and drink code. In fact, he can work separately from the team, especially if this is the very ideal project where he is provided with test cases from functional testers.
Thus, the path from handbrake to automation is a road not only to big earnings, but also to a remote place, if there is a need for it.
Have you ever switched between IT areas? How did you choose your path?
Article author: Ruslan Abdulin
This article is the third part of our IT career career publication series.
The first part is here .
The second part is here .
PS We publish our articles on several sites of the Runet. Subscribe to our pages on VK , FB or Telegram-channel to find out about all our publications and other Maxilect news.
Help us make the blog articles more interesting: Please answer three questions .