One Day at Work for Automation QA Engineer

In a QA job, once you start assigning tasks, there is little time left for technical solutions. Well, I can say that indeed there are more meetings and conversations. Despite this, I still do my day-to-day tasks and even switch to something new and different. In this article, I would like to tell you what my working day and work in general looks like.

I worked remotely even before it became ubiquitous. And I always considered it important to stick to the schedule.

7 AM

My day starts at 7 AM. By 8:50 AM I take my girlfriend to work. Three times a week from 9 to 9:50 AM I go to the swimming pool next to my house. It keeps me energetic for the whole day.

Moving around my city does not take much time. It would seem that it was possible to work in an office but remote work provided much more opportunities: exchange of experience with colleagues on more interesting projects, professional growth, getting familiar with new technologies, approaches, and tools. At the same time, this is a way to get more income than they pay in local IT companies, without moving anywhere. This solution might seem obvious but until recently I had almost no friends who would work the same way. People working in IT either working for a small local business or moved to the capital. I preferred to be remote from my beloved city.

10 AM

By 10 AM I sit at my computer and start working by reading emails and messages in Slack, looking at new pull requests from colleagues.

At 10:30 AM we start the daily meeting, where the team shares who did what yesterday and what they plan to do today. Then, before lunch, I usually have a whole series of calls with individual team members. Since there are no “fires” in my work, which have to be urgently “extinguished” 24 hours a day, I have the opportunity to plan conversations in the way that suits me. And for me, it is better to hold them in a row –conversation after conversation, without interruption.

By its nature, my job requires spending 3-4 hours a day on the calls. Most of this time I advise the guys on test automation on several different projects. I tell them what to do and how to do it, and what approaches can be used in special cases.

A year ago, there was a lot of training among these calls. Initially, my main project did not have an automation team, only manual testing. The company’s policy is not to attract automation engineers from the market, but to cultivate them from previously hired manual testers to make a full-stack team. Realizing that I cannot manage testing automation on three parallel projects alone, I started training colleagues on my own. Of course, the training did not go from scratch as most of them already had some experience in programming or simple automation. On top of this knowledge, I talked purely about automation a couple of times a week for an hour. The training took about 1.5-2 months and during this time I even invited my colleagues to do five homework assignments (they were also sent to me for checking).

Three colleagues listened to the lectures in real-time. But we recorded the videos, so two colleagues who joined the team later were also able to watch them to start working on the same basis. To be honest, while preparing lectures, I refreshed a lot of knowledge in my head. So the training was good for everyone. Moreover, now our developers are also engaged in testing automation (front-end developers create automatic tests to check the UI, and automatic engineers are engaged in E2E tests).

When all the conversations are over, I still manage to work a little quiet until lunchtime.

2 PM

In addition to morning calls, we have other mandatory activities (for example, additional planning). They usually take about an hour and are scheduled in the afternoon. But, of course, they do not take place every day.

After lunch, I work with IntelliJ IDEA, TeamCity, Jira, Stash, and other tools, so I have a period of quiet activity. I dive into current tasks.

As I already said, the work is proceeding in a calm way: we have a list of test scenarios, every 2 weeks we take the most relevant for the current release of the product or the most labor-intensive ones ─ those that are difficult to check by hand – and automate them. This reminds working at the conveyor belt: you take a scenario, read it, delve into it, automate it and take the next one.

If we do not automate some of the scenarios on the project with the current means, we discuss possible adjustments to the plan: either the scenario is not so necessary and can be checked by hand for now, or we lack something to automate it, which means we are introducing some new technologies and tools.

This is the time when I am engaged in self-education. I know that some colleagues take a little time each day to learn new technologies. But I prefer to learn from real-world problems. I am periodically pulled from quiet work on related projects, where at the moment teams face new or non-standard tasks for our work technology.

For example, I get a task to make a stand for performing automatic tests in Docker, which I have never used in my life before. Together with the developers, I am happy to understand the tool, read the documentation: what is an image, container, docker compose, docker hub, etc. And I immediately apply this knowledge.

Another example is the automation of our own work. Not so long ago I wrote a bot that helps us collect statistics on the work of the test environment. To implement it, it was necessary to study the work with web sockets, the protocols and technologies involved, take a closer look at the features of interaction with mobile devices. In the process, by the way, I found out that there are decent WebRTC libraries only for these very mobile devices and for the web. There are libraries for Java Desktop, but all of them are either very outdated or without documentation.

In general, I like to combine measured work and new challenges. This keeps me focused and motivated. Many people use systems like the Pomodoro timer to solve the same problem, but they only distract me. I barely have time to tune in to work, and the timer is already ringing to rest.

7 PM

The working day for me ends with reporting. In the task management system, I record the time spent on everything that was completed during the day. I write intermediate data in a regular notebook, and at night I report in Jira.

Honestly, during a pandemic, and even with the training of colleagues, the evening boundary of the working day has blurred a little for me. Sometimes I can get carried away and sit up until the night. But they won’t let me do that a lot as the dog’s schedule is stricter than mine.

At night, I walk the dog, go shopping or meet with family or friends to start a new working day tomorrow.

As you already understood, I like the measured course of life. For me, it doesn’t mean boredom at all. Without fires and missing deadlines, you can solve problems, change the technology stack to a more modern one and grow professionally, and I wish you the same.