Transitioning from a heating engineer to an automation tester. Is it a radical career shift or not?

In the context of a series of articles on testing at START, we had a conversation with Vadim Danilov, a Junior Test Automation Specialist. How to break into IT, how tasks are planned and assigned to automation testers in our online cinema, and advice for beginners who also want to transition into the world of IT.

Share your career journey with us. How did you get into testing?

Before I got into testing, I worked in the field I studied at university — thermal power engineering. I was employed at a Gazprom subsidiary, working in various positions for a total of 4 years. During my time at the company, I managed to climb up to a managerial position.

I have an engineering degree and had done some Python programming previously. When I decided to switch careers and find a job that I could do remotely, my friends who have been in the IT industry for a long time suggested testing. They shared books and courses with me, which I absorbed very quickly. Mainly because I found it interesting and was eager to secure a job in this field as soon as possible.

I was hired by START online cinema despite having no experience, probably because of my strong theoretical knowledge, and perhaps they recognized my potential.

Is it possible to immediately start in IT with automated testing?

Certainly, it’s possible. Different companies have different requirements for candidates because they are looking for people to fulfill specific tasks and processes. I believe that if candidates know what they want and at least study the theoretical part, they will surely find a job that suits them.

I’m interested not only in writing autotests but also in process development. I want to examine quality assurance processes from various angles, so I’ve been involved in both manual testing tasks and autotests, trying to understand them in a real project and start contributing to the business as soon as possible. The proportion of time I spent on manual testing and automation was agreed upon by the heads of departments. In addition to working on autotests, I also set aside extra time in the evenings to study literature and solve problems.

What level of Python knowledge is required for automation?

It depends on the company and the project. Everywhere is different, even if it’s called the same thing. For my current tasks, a good level of Python knowledge is required. You also need to understand things related to CI/CD, Docker, Kubernetes, and have experience interacting with them at least at a user level (understanding basic abstractions). Currently, I’m taking an in-depth course in one of these tools, which was selected and paid for by my company.

Do you have a specific task planning horizon? Or do you just work on tickets as they come in? What’s your roadmap or what format do you operate in?

We have extensive planning, similar to development, for a fairly long period. For instance, the backend team has a task to completely rewrite one of the main services. Based on this, we know that in 3–4 sprints we will need many man-hours to write and rewrite autotests to accommodate these changes. Otherwise, our entire tech department looks at what tasks the developers have taken for the sprint and assesses which ones we will cover.

But often tasks come in unexpectedly. Since these tickets are usually prioritized over scheduled tasks, we switch to them almost immediately. This happens in any team, not just in autotests, as there are always unforeseen circumstances that can’t be planned.

There are also long-term tasks that aren’t dependent on sprints or sudden tasks. Generally, we have many services that differ not only in terms of code and business functionality but also in terms of implementation in the admin part and interaction with each other. Also, the services are described in varying degrees of detail in the documentation. Depending on what is currently prioritized, we write unit tests, integration tests, or end-to-end tests. Or we start by conducting exploratory testing if the documentation is completely outdated and we need to determine the expected behavior of the service before covering it with autotests. This is an interesting part that makes routine work almost unnoticeable. Decisions on what tests the service currently needs are made jointly with the team through discussions. If it’s about unit tests, we coordinate with the developer responsible for the relevant project.

Let’s talk about the workflow. Who assigns tasks to the automation testers?

We attend the backend and web planning meetings and see what tasks they are taking on for the next sprint. When a project manager brings a task, it’s already broken down into smaller tasks. Together with the development and testing team, we look at how much we can do it for, estimate the cost value, and then decide whether we will automate it. Since I moved to the automated testing department not so long ago, my tasks are assigned by the department head who explains what needs to be done and asks me to create a ticket myself. In the future, I will choose my own tasks, as my more experienced colleagues do. Now I am already taking on some of the tasks myself.

You’ve been in testing for almost 1.5 years now. What knowledge do you think you still lack within your profession if you continue to develop further in automated testing? Or do you already have enough knowledge and everything is going well?

My current knowledge is sufficient for the tasks I’m doing now, but I plan to upgrade my skills, so I’m constantly learning new information. For example, I’m currently taking a course on Kubernetes that START provided me for professional development. It’s more related to DevOps, but we also use it from our side, so understanding and being able to work with it on a deeper level will be a huge advantage for me.

How are tasks distributed in your team?

In our tech team, one developer can work on multiple microservices, just like a tester. The same applies to the automation team. There is a division of tasks, but usually, we have more than one microservice per automation tester.
So, you were an engineer in a heating network and now you’re essentially an engineer in an IT company. Do you think you’ve had a significant change in your career path or is an engineer always an engineer?

An engineer is a specialist who takes many known parts and assembles them into something new that is needed to solve a problem. And all the accompanying things, like a programming language, are just tools. So there are some common points, of course.
In general, concepts such as structure, constraints, trade-offs, recombination (when we disassemble something into elements and then create something new for our tasks) are elements of engineering and they are often used in all fields.

Do you believe it’s beneficial to evolve by switching jobs every two years or to thoroughly understand everything about one service and progress with it over the years?

The outcome relies on both the project and the individual specialist. From my perspective, in a new company, half a year will be spent just learning the company’s internal processes, while in your previous company, you could have used this time for your professional growth. However, if there’s some form of compensation, then why not. In our team, if an employee consistently performs well, they are assigned more complex tasks, leading to their growth.

Can you explain what exactly is automated, and how decisions are made on what to automate and what not to? Or perhaps there are universally accepted guidelines in the IT community about what we cover with autotests and what will always remain manual?

There are universally accepted guidelines, and they are readily available; this is probably the first thing any budding automator learns. In testing and automation, there is a wealth of information available in the public domain. On our end, the engineer’s role involves applying theory to the project context, and the project context, particularly its technical aspect, doesn’t unfold immediately: it requires both time for the picture to form in your mind and the individual’s professional qualities.

What guidance would you offer to those starting out in automation?

It’s hard to recall everything all at once.
Firstly, understand that autotests are merely a tool. Secondly, feel free to ask questions. Thirdly, if you’re unsure where to start with a solution, begin by writing “pseudocode,” then translate it into a specific programming language.

There’s an abundance of information about the QA field. There’s plenty of information on personal development and even on career building — take the time to learn, it will be beneficial. Even if you might lack practical skills at the beginning, there will always be a company with tasks that you can handle. If you’re already working in a related field, don’t hesitate to discuss your growth prospects and desired career path with your manager. For instance, you might be working as a manual tester now, but envision yourself as an automation tester in the future.

Bonus

Here’s a list of books, courses, and other resources that Vadim used to become a test automation professional:

Books:

Automation:

Learning Python. Mark Lutz

Complete Guide to Test Automation

Testing:

Software Testing. S. Kulikov

Key Testing Processes. R. Black

Useful Resources:

Articles:

Habr

Practice and problem solving:

Leetcode

Codewars