QA Automation Engineer: A Profession for People Who Can’t Stand Inaction

We had a chat with Vasya Shuvalov, an expert in the field, about the tester profession, with special focus on test automation. You’ll find out whether testing truly is the easiest path to break into IT, and who writes more code: a developer or a QA automation engineer. As well as why there’s never a dull moment in test automation.

So tell us about your career track and education background.

I have been working in testing for 3.5 years, ever since the beginning of my third year at university. While I was still pursuing my bachelor’s degree, I also took a semester-long testing course from Mail.ru at my university, which eventually led to me getting a job there. For 2 years, I mostly did manual tests of mobile applications, and since December 2022, I’ve been working on automation at START. This summer, I’ll be graduating from the Master’s program at the Moscow Engineering Physics Institute. I’m majoring in Computer Science and Informatics, and I’m currently on track for graduating with honors.

Why did you decide to get into testing? The way we see it, someone with your educational background can pursue a career in development or a related field, such as product management or project work.

I think the reason is that, even as a kid, I would always ask questions like, “How does this thing work?”, “What is this thing’s breaking point?” and so on. And testing, especially test automation, which is my current job, helps me find answers to such questions, as well as figure out something new with each task, and locate weak spots in the software. Testing often goes hand in hand with research, requiring you to possess a range of professional qualities and skills to do a number of things, from coding and manual testing, to doing research so you can understand how a particular service works and how it’s supposed to function. You gather information, compile it, and then carry out your task based on that.

That sounds like project management. What language do you code in?

We primarily code in Python.

Let’s circle back to the topic of career choice. With a certain level of proficiency in Python, you could have delved deeper, improved your language skills and gained more practical experience. That could lead you to coding on your own and becoming a developer.

Essentially, right now, I am a developer in testing. I write and test code, just like our developers. The only difference is that our product is used within the team, not by an external client. I wasn’t initially drawn to product development. Development in testing offers more freedom: you are more flexible when choosing the tech stack and have more influence on the functionality.

Am I correct in understanding that developers write significantly more code than automation testers?

This is where we should probably make a distinction between testers who are involved in automation and developers who are involved in testing. As developers in testing, we also have to write and rewrite large volumes of code, modifying, changing, and augmenting it. We create mock services, refine external libraries, participate in writing unit tests, and so on. Sure, developers have to work with a more complex architecture, but, overall, the only real difference is the libraries used. So, like, if we take myself and a developer, we are both more familiar with the nuances of the libraries we need in our respective fields of work. However, if necessary, we can both turn to other tools.

Many consider testing to be the easiest way to get into IT, even without a technical background. In other words, they believe that the entry threshold here is lower than it is in development. Your profession seems to straddle the boundary between these two worlds: not only are you a tester, but you also have to write code. What was it that guided your choice? Could it be a sort of level-up for you? The next stage after manual testing?

I think that this interpretation devalues the profession of manual testers, and that’s not entirely fair. There are many potential paths for development within QA. Automation is just one of them.

Quality assurance engineer must possess a number of specific abilities and skills, such as being able to anticipate potential errors. Not everyone can do that. This job requires experience and a keen understanding of where and when things can break.

In his book about testing processes, Rex Black states that if someone approaches manual testing as a stepping stone to something else, it means they are but a temporary employee, which will inevitably impact the quality of their work, potentially leading to high turnover in the manual testing team. Considering the current market situation, we can see that this claim is true.

As for manual testing and automation — whether it’s a level-up after manual testing, a separate field, or just part of development — it depends entirely on the company, the product, and the specialists themselves. I know examples of products where manual testing requires more skills than automation. If we were to compare test automation engineers from two different companies, it’s likely that they’d have different sets of tasks. We are influenced by how processes are set up in development teams, manual testing teams, DevOps teams — it can vary from company to company. At START Online Cinema, test automation engineers are mostly developers who understand what testing is and how it works, so they write the code required for testing and quality assurance.

Did you learn Python before you started working on automation, or was it something that you had to tackle on the go?

At university, we used Python extensively as part of our studies, along with other languages. We had numerous courses: each semester introduced a new subject and a new language (Python, C, C++, JS, and others).

When you got into test automation at START, what skills were you lacking? Let’s start with hard skills.

I had a solid enough foundation and sufficient general knowledge, but any workplace uses certain specific technologies and tools that I might not be familiar with. The essence of development is to solve the given problem using the programming language. Developers always encounter something unfamiliar: be it a new library or a new type of task.

University education encourages you to learn problem-solving. It instills the understanding that languages and libraries are merely tools that we choose to solve specific tasks. So, I didn’t have much trouble getting to grips with something new. In the first few months, I had to figure out how the service was structured. Each product has its own structure, with unique nuances that are not immediately obvious. Whenever I encountered something new during my work, I had to puzzle out how everything worked, what connections existed between the microservices, and what each of them was responsible for. Now that some time has passed, I have acquired all the knowledge I needed, and can see the full picture. So, I am no longer facing problems like these.

On my first day at work, I was given a task. I was presented with a test and an explanation, told about what that test did and how I was supposed to modify it in line with new requirements. I didn’t need to delve too deep: it was essentially an isolated piece of code that I needed to modify. And I succeeded. I was then assigned a refactoring task, which required me to explore the code a bit more in-depth. Gradually, I kept receiving more and more tasks where I had to immerse myself further and further into the existing code. By now, I can explore the service and write tests all on my own.

Testers check the code written by developers, but who checks the code for test automation teams? Who reviews your work? Or maybe there are some services that you use to run your code and highlight errors?

Every piece of code is statically checked for any syntax errors. If the code doesn’t start at all, we will obviously see this. After everything is done, we review each other’s tasks. We examine each other’s code, verify it, cross-reference it against the requirements, which is similar to a developer team’s code review, essentially the same event, except for the lack of the manual testing phase. In essence, we carry out the task ourselves, and if something unexpectedly goes wrong, we also fix it ourselves. Occasionally, we invite interns to our reviews so they can read the code and familiarize themselves with it. We also make sure to double-check and don’t delay the task in case one of the interns has any questions. When it comes to unit tests, the review is done by the developers, while we write the code in line with the style used in the repository that we are changing. Since this code is deployed in production and impacts the services used by our customers, we bring in manual testers, or our teammates who have experience as manual testers, to help with the release.

What do you enjoy most about your work in test automation?

Probably the task variety. There are cases when you focus specifically on tasks related to automated testing, writing new tests. Essentially the part of automation where you act more as a tester: searching for requirements, writing automated tests, and so on. Then you wrap that up and move on to a task that is solely related to configuring CI or writing, for instance, a bash script or a mock service. And within an hour, you must stop being a code-writing tester and turn into a developer. You then shift to a different kind of development, because the code of the tests themselves versus the code of a test project, with its various internal aspects, is structured differently. And you need to quickly switch between these diverse tasks. I appreciate this change of pace because it prevents monotony from setting in. You don’t have to do the same thing over and over, and can see the development process from various angles. There are always several paths for development and different tasks to undertake.

Are there opportunities for professional growth within START and the team?

Yes, there are. Our team is highly competent, and we constantly share our experiences and knowledge. This helps with steadily moving towards new milestones and tackling new challenging tasks that you couldn’t have handled before. Through this exchange of experience and knowledge, you become more self-sufficient as an employee, with more skills and the ability to solve more problems on your own without needing to ask others for help or advice. Your area of responsibility expands; your professional expertise improves: you can confidently explain why something needs to be done this specific way. Over time, I was entrusted with increasingly challenging and large-scale tasks, and the more complex they were, the more insightful I became.

What are your current personal professional goals for the next 2–3 years? Is there anything keeping you from reaching them?

My primary goal is to make a significant contribution to the advancement of test automation, especially within START. That is, to invent and develop some kind of helpful tool, or contribute to its creation. Overall, I aim to become more experienced and versatile, and acquire new skills that will let me solve more complex problems. I lack experience and knowledge, and there are definitely some things that I have yet to encounter. But as time passes and I keep working on my tasks, these gaps will continue to close.

I’m graduating from university this summer. The subject of my thesis is directly related to my work: Development of an Automated Test Generation System. It is a product that partially automates the development of automated tests.

What would happen to QA automation engineers if such a product was introduced?

There are always some boilerplate elements in both test automation and coding. Some tasks that can be run automatically. Then there’s the engineering element, where certain standard parts need to be adapted to the current context, technical or otherwise. For instance, the program receives service documentation, say a swagger, and a list of all methods and their parameters for the API — all of this is automatically inserted into a test client, which is subsequently used for automated tests. It’s here that we can automate the preparation of some basics for subsequent automated testing. And that’s the challenge I’m set to tackle in my thesis. But you’ll still need to expand the resulting code. It’s just that the routine gets automated.

I hope that my thesis will not just be written for the sake of it, but will actually yield a good product and some useful insights. And if it all goes well, then I’ll be able to count it as achieving one of my goals.

#qa #automation #testing #python #qaengineer #career #careertrack