Proactivity in practice: how a junior can find interesting tasks

Accept routine as an inevitable but useful task

I joined T-Bank as an intern, and at first, I was only assigned simple tasks: for example, testing changes in the response of a GET endpoint. When I first started on them, they seemed interesting, but after a while, I got the hang of it, and they turned into routine, so I got bored.

Then I decided that I needed to become a mid-level specialist as quickly as possible because they don't have routine tasks. But after talking with senior colleagues, I saw that mid-level specialists also have plenty of such tasks. The only difference is the speed: I would spend a couple of days on a similar task, while a mid-level specialist would complete it in a couple of hours.

After talking with colleagues, I concluded that routine tasks for me are a way to improve my skills for faster and, most importantly, higher quality work. But understanding this didn't make it any easier: will there really be only monotonous and boring tasks on the way to becoming a mid-level specialist? And will I be entrusted with something complex only when I reach my goal?

Of course not, and here's why.

Choose complex tasks with low priority

I divided tasks into three types. The first type is simple, and there are many of them. They did not require complex programming skills or knowledge of testing theory, but they needed to be completed quickly. At first, I performed them much slower than my senior colleague. Over time, the difference in speed decreased, but I did not gain deep knowledge, although I got the hang of it.

The second type of tasks is more complex and requires quick execution. For example, when the EOL of mock servers occurred, we had to urgently migrate. I didn't take on such tasks: I lacked the hard skills to complete them quickly and without errors.

And finally, the third type of tasks are complex tasks with low priority. The problems are usually not critical, but of the "it would be good to solve them" series. In addition to the main and routine tasks, I focused on such tasks. This way, I met two needs at once: complexity develops skills, and low priority gives more time to delve into, understand, and implement — which is the optimal option for me.

Before taking on tasks, I discussed them with my supervisor, because not all of them provided real benefits. Those that passed the selection were included in my IDP. At the end of the internship and during the grade promotion to mid-level, this helped me because I showed my proactivity, the skills I acquired, and the benefits I derived from it.

The assessors — senior colleagues and supervisors — liked this approach to tasks, as they wrote in their reports. One of the goals of leads when working with a novice specialist is to develop his skills to such a level that he works and brings benefits without an external observer. Complex tasks with low priority just helped with this.

I will tell you about several tasks and how I came to them.

Implementation of the "Three Amigos" process. The team had a need to bring many questions from the development and testing stage to the preparation stage. For two retrospectives in a row, my colleagues and I noted that in complex logic tasks, we had to refer to each other several times to clarify points in the specification, find out what changes occurred in the contract during editing, and so on.

The team lead set the task of implementing the "Three Amigos" practice in the development process. After discussing in detail with the team lead and mentor what was required, I studied how other teams dealt with this problem and proposed a solution: several small tasks from the epic are brought up for discussion after analytics, where the tester, developer, and analyst jointly discuss the arising questions and, if necessary, make adjustments to the specification.

We tried it — we liked it. During the experiment, I noted the pros and cons, kept documentation, and adjusted the practice to the needs of the team. The tool proved to be convenient and useful for the development process and worked well with the practices already used in the team.

Integration of Unit tests development with the Allure project. The QA team did not understand what was happening in the development project, and there was a feeling of a crooked testing pyramid. To understand what was wrong, the development and testing team discussed the problem and decided to try building dashboards based on test cases.

The mentor suggested solving this problem on my own. Moreover, he noted that although the task is not urgent, it requires elaboration, and it will be necessary to get acquainted with new technologies and approaches, which will be a big plus in the application for promotion.

At first, I doubted that I could handle it, but the mentor assured me that everything was quite solvable: "If you have any questions, just ask." And so it happened. I had many questions: how test cases are loaded into Allure from autotests, how to better present graphs, what metrics besides the number of test cases should be considered, and many others. Colleagues of a higher grade helped me with all of them.

In the end, I did not find any bias, but the team gained confidence that we were covering the functionality correctly. Now the team monitors changes in the pyramid and adjusts the distribution of tests by levels. Thanks to the documentation on writing Unit tests, they became more understandable not only for testing but also for development.

Hiding sensitive data in autotest code. The task of integrating with the internal tool for storing sensitive data had been in the backlog for a long time. I discussed the possibilities and difficulties with the prof. lead and took on the task. During the work, I got acquainted with a new tool for myself, working with the GitLab pipeline and with the Gradle configuration.

I asked a lot of questions while performing tasks. Sometimes I thought they were stupid and obvious - maybe I shouldn't ask about it. I had to overcome the feeling that I looked stupid from the outside. But thanks to the questions, I understood better why and why something is being done. It seems to me that asking stupid questions and making mistakes is normal at first. The main thing is to try and ask for advice or help in time. A few hours of work, the task is not progressing - for me these are triggers to turn to colleagues.

Look for tasks yourself

If it seems that there are no development tasks, you can try to find them yourself. Salvation can be:

• Senior by grade, prof. lead, team lead, mentor or senior colleague. I constantly asked what needs the team had, what was stuck in the backlog, what could be improved.

• Literature. I read the approach - try to apply it. Articles, books, other information - will go straight into action. When I was preparing for certification in the company, I read about the testing strategy in the "QA Bible". I realized that it would bring more clarity to the testing process for team members, because questions often arise about how, what, and why we test something. I am currently in the process of writing documentation on the testing strategy - it will not only help the QA team organize their scattered instructions, but also make the testing process more transparent for other team members.

• External or internal meetups. After attending an internal QA engineers meetup on working with Unit tests, I realized that I was demanding too much from the development team (the task of integrating development Unit tests with the Allure project, which I wrote about above): putting a lot of annotations for tests and classes, renaming methods. I shortened the instruction - left only the necessary points and removed the recommended ones, which sped up the work for the development team.

• Thematic communities in the company, such as SDET teams, chats by directions, thematic meetings, and so on. Thanks to this, the idea of writing this article appeared. The guys encouraged me to write the material, which seemed interesting and useful for the skills of structured presentation of thoughts and working with edits and comments. Who knows, maybe you will notice something that will be interesting and useful to you.

• Other teams. Many practices and ways of applying technologies can be practically evaluated by a neighbor. For example, while performing the task of implementing the "Three Amigos" process, I communicated a lot with colleagues from other teams. They had no problem sharing their experience with this tool - in which situations it performs excellently, and in which it is better not to use it, sharing documentation. I managed to extract everything necessary for my team from this and start implementing the process.

• Daily meetings and brainstorming sessions - you can learn about needs and problems at them. It will be great to show initiative.

I tried to show by my example that a junior developer is capable of performing not only primitive tasks, but also complex and interesting ones. Such tasks can be found by oneself, the main thing is to be able to choose those that will benefit you and your team.