Hello! My name is Luba and I am a QA engineer for the contact center systems development team at Lamoda.

Three years ago, I have recently been working in our company, and this made me think and look again at the events that have occurred since the moment I chose this profession, at the decisions that I made. At some point in my career path, I ran into burnout, and was close to completely leaving the profession. But I didn’t leave, but on the contrary I continue to realize myself in the same field, moreover I have been working for a relatively long time in one place, and so far I am not going to leave.

Software testing - is this the profession that I want to do?

I am a mathematician-programmer by education, but at the institute I realized that I do not want to become a developer. Testing, on the contrary, immediately seemed interesting to me, because it requires a variety of skills (and at the same time it remains an opportunity to code).

For the first three years of my career, I worked in two companies, and in both I was engaged in testing banking software - and I gratefully recall my past jobs and my former colleagues who helped me gain initial experience in the profession.

In the first place, I tested WEB applications on tablets / mobile devices (iOS, Android) and desktop client-server applications. I began to apply different types of testing, and new skills appeared in the piggy bank of my technical experience:

I learned to do everything necessary for working in a * nix system through the command line;
learned how to make requests to Oracle DBMS;
learned to create and customize your test environment, including using VirtualBox;
I realized the importance of logs and learned how to work with them, as well as adjust them by levels.

Then I got a job as an outsourcing company providing testing and analytics services. This work gained me little technical experience: only getting to know SoapUI, integration testing, and on one of the projects I managed to get even more involved in testing mobile applications.

But on some projects, I managed to try myself in the role of analyst and test lead for a small team of testers. I talked a lot with both colleagues and customers, which helped me to develop software skills.

In these first three years, I realized that I was not mistaken, testing is really very diverse, and I like the work in this area. But the more experience appeared, the more I began to demotivate some points that at first seemed quite acceptable. Basically, these were the features of the organization of work processes adopted by the company - something that I could not influence. I tried to cope with discomfort by investing my internal resources, because I liked the work. But at some point it stopped working.

Burnout

There was a millennial on open space, sees - the work is on. He sat down for her and burned out.

By the end of the third year of work, I had burned out so much that for three months I simply went “nowhere”. Resting and recovering, I tried to understand what exactly brought me into such a state. The most critical moments for me were:

: (/), .
: , , . , QA- , .
, , .
, , , .
. .
- — , , .
— , « » , , , .

All these unpleasant things, if you think about it, are not directly related to the profession of a software tester. But at that moment, of course, it was difficult for me to separate one from the other. And when, after the break, I again had the desire to go in search of work, I thought about changing my profession to an adjacent one. For example, go to analytics, or try to continue in the role of QA Lead.

But at the same time, I realized that I incredibly like the technical component of my profession. And then I realized that I want to continue to develop as a QA engineer. That analytics is likely to bore me without technical points, and in the role of QA Lead I will gradually lose technical skills. And according to my feelings, in the near future, strong technical specialists will be more in demand in the labor market.

Search for a new job

This time I entered the labor market as an experienced enough specialist. I determined for myself a list of requirements by which I evaluated the offers of employers. Of course, I would like to see the same disadvantages that caused my burnout at the new place of work. Separately, I identified a few more criteria:

the subject of testing should no longer be associated with banking software;
the company should not have bureaucracy;
and most importantly, to be satisfied with the work, I must see the results of my work and receive feedback from users and my colleagues.

A long search began. I was not very pleased with the proposals received - it seemed that most of the disadvantages of the previous places would be here.

And suddenly I remembered that a year ago I was staring at a job as a QA engineer at Lamoda. At the interview, I was hooked by the fact that it was supposed to do a lot of technical tasks, use new tools for me and test a large and complex system. And that normal communication is one of the company's values.

And so it was possible?

The first unusual thing that I came across in a new place was that here all the work is done by the team.

This is manifested in established processes in the form of adapted scrum - synchronous 2-week iterations in each team, during which various meetings are held (meetings, grooming, assessment of tasks, discussion of projects). My workload is planned taking into account the fact that I will attend all these meetings. As a result, I am always up to date with all the project news.

Healthy working relationship

Personally, I really like that there is no testers department as such, headed by a supervisor. When there is a dual subordination - the team leader of the developers and the head of the testing department - sometimes there is a conflict of interests and a struggle for resources for certain tasks.

In Lamoda QA, an engineer is part of a specific system team .
And it turns out that I am subordinate to the team leader of my team, who is aware of my current and upcoming work, and this helps us to effectively conduct 1-to-1 meetings. At them we discuss my painful work, and the team leader tries to help with everything necessary, and also determines further possible development vectors. That is, I get the very feedback from colleagues through team lead - something that I really missed before.

And I began to feel absolutely normal when I needed to ask for help from a developer or analyst, or even other teams. Nobody makes you stupid if you don’t know something, but on the contrary share knowledge, and welcome this approach.

Autonomy in work

Especially important for me was the availability of access wherever needed. And I can independently configure my test environment as I need, climb into the database and logs, and also see the application code as a whole and all changes in it according to the task request pool.

For example, when I take a task to work, I see what exactly was changed in the code. At this stage, I can already notice the defects. If I understand that I need to check the exchanges with another system, then I can deploy any other system on my testbed myself - raise databases for it, containers with the necessary version, roll migrations. And I do not need to ask one of my colleagues to do this.

Knowledge sharing culture

From the very beginning of my work at Lamoda, I was incredibly pleased with the openness to sharing knowledge accepted in the team. This greatly simplifies many work points. But knowledge sharing works really effectively when it is shared by the whole company, when a whole culture has formed, and each employee is a part of it (about how exactly this was achieved at Lamoda, my colleague recently wrote in an article ). I appreciated all the advantages of this culture on myself, and with pleasure I now support it myself.

, , , . , , . , , , .

In general, such banal awareness came that instead of writing abstruse documentation (which is still written very rarely and slowly), you can simply share knowledge in notes accessible to all, and in the simplest possible language. After working in the banking sector, this was unusual for me, and I deliberately weaned myself from adding excessive terminology and “water”.

Leaving such notes, first of all, I take care of myself future. Which, after a while, will be forgotten, as I checked something the last time, and here my notes from the past will come in handy.

And over time, I realized that it was possible and necessary to share knowledge not only within the company, but also outside - at various conferences and meetings. For example, I once made a report on integration testing. Well, or an article here you can write =)

-

Our company has a really large IT unit, more than 340 engineers, and I constantly work with only one part of it. But, thanks to integration testing, I get acquainted with the systems that other teams support and develop, and even participated in testing them at times when those teams had difficulty with the resources for this. And this is again the very diversity that I love in my work.

It is also very important to me that I can look inside all the processes that are built in the system. For example, it is possible to observe the work of call center operators. What turned out to be very useful for me, as a call center tester, I was able to better understand the business logic of some cases, as well as see the weak spots in the application and tell the team about them in order to make improvements in the near future.

, ( ). , 17:00 sms , . sms , , - , . , , , sms – .

In the past few months, I have joined the guys who conduct interviews to find new QA engineers in our backend teams. It also turned out to be very useful: I pumped up soft skills and even learned new technical things from the candidates. Plus, it was very nice to help find really cool specialists in their field, with the same burning eyes as mine, with whom I then work together to get high.

Recently, I had a transition from one team to another, and I wanted to leave the system and all my developments in good hands. Therefore, it was especially important for me at this moment that I could personally interview new candidates and choose the best one.

What, in fact, have I tested all this time?

In the beginning, I got into the Order Processing system team for storing and processing orders (a colleague told more about this system in an article ). At that moment it was a very large monolith written in PHP, which communicated with a huge number of other systems. And, honestly, at first it was difficult and painful to test it. I had never before encountered such systems. Over 3-4 months, testing of each task began almost from scratch - they all related to completely different functionality, and required different approaches to testing.

But personally, I realized that I enjoy such complex challenges. Because, firstly, it does not get boring, and secondly, there are many opportunities for developing technical skills.

Hooray, finally automation!

Here, I finally got the opportunity to get acquainted with test automation and do it closely. I always had a point that I would not want to forget the acquired programming skills.

And now I am engaged in testing automation for php + codeception - my colleague talked about how it works in this article .

The whole team is working on the creation of integration auto-tests, trying to ensure that as a result, hands-on testing had to be done only once when developing new functionality. Regression in my system is already covered by autotests, and it pleases. Passing the same scripts manually from time to time is probably the most unloved part of the work of many testers. It is much more pleasant to spend this time developing your skills and other interesting activities.

Frequent changes - extra difficulties or an opportunity for development?

Of course, over the three years I have not always been fine.

For example, over the past few months there have been changes in the team supporting CI / CD. During this period there were problems with the test environment, they were solved for a long time, or they were completely left without a solution. Of course, this upset me and made my work less enjoyable. But at some point I realized that a large number of changes that are difficult to predict are an integral part of working with any really complex system. And in all this you can find the pluses. I managed to better understand my test environment, I learned to fix some problems on my own.

It happened that the containers in the docker after lifting almost immediately fell. And here it was necessary to get into the logs of the container, understand what exactly went wrong, and try to localize it on your own or understand which of the developers can be attracted for help. At that time, this method was much faster and more effective than waiting for help from the guys from CI / CD.

My technical growth: specifics

Compared to past places of work, I feel that for now I have been growing professionally “for three years,” my tasks were so different and rich.

?
— Jenkins, VirtualBox, .
docker, k8s .
— Bamboo.
— PHP+Codeception PHPStorm, Git.
— Allure .
— API – Postman, SoapUI, Swagger.
— SQL Postgres – Sequel Pro DBeaver.
— Kibana, .
— RabbitMQ Event-bus&Kafka.
— FTP, SFTP, S3 Cyberduck.
— Jira, Confluence.
— SoapUI Wiremock.
— , , .

:

Despite this kind of great variety in work, after about 2 years I felt that I had again stopped in development. Tasks became repetitive, I just started to get bored.

As a result, I openly talked about my thoughts and feelings to my team leader at the 1-to-1 meeting. It turned out that the company is ready to give me a lot of opportunities for horizontal development. A month later, I was offered to go to the Callcenter team with a rather different technical stack, which I work in now.

What did this transition give me?

From the point of view of the test object itself, I again plunged into a completely new area for myself. The call center is about telephony, there is a completely different architecture of the whole system, not similar to all those with which I worked earlier.

The system itself consists of several services that are historically written in different languages - there are PHP, Go, Scala, and JS Node.

There were very few notes and documentation; there were no integration autotests.

In fact, I got the opportunity to build testing from scratch for a large and complex system. We ourselves come up with and establish internal team processes - as we agree, it will be so. So, we decided from the very beginning to work on test automation, using tools convenient for our team.

So the problem with boredom was definitely resolved, I feel that I am now making a huge leap in professional development.

What am I feeling right now?

Personally, it is surprising to me that the fire in my eyes did not diminish for the three years spent in the company. Perhaps I really found that very occupation and place in life that I wish for everyone.

Here I do not feel isolated. I always have the opportunity to develop technology, test different systems, switch to other teams, which means to learn something new again and participate in various general events, which allows me to really feel the value and importance of my work.

And how, in the end, can an engineer cope with burnout QA?

There is no universal medicine. After all, there can be many reasons leading to burnout. But here are the conclusions that I have drawn from my experience.

, , , , .
, . — , , . , , . , =)
, . , - , .
Companies with a modern and diverse technological stack allow you not to foul as a specialist, because you have to keep up with the times, studying all these technologies.

If you feel tired and annoyed, and think that testing is no longer your business - think about it, maybe it’s in the working environment, and not in the profession as such. It is likely that you are tired of the fact that the processes are not established, the work goes “to the table” and the results of work are not felt, the communication in the team is too complicated and takes away a lot of energy ... There are many demotivating factors.

It is possible to find your own business and your own place: sometimes you need to look outside, sometimes you need to negotiate inside. The main thing is to clearly understand what is not happening right now and how we would like to, and clearly convey our expectations and Wishlist.

My QA Engineer Path: Through Burnout to High Testing