How Do You Grow a Senior QA on Your Team?

So your team has a Middle QA engineer who wants to develop further. What should you do as a team leader to raise a Senior? Below you will find tips based on the experience of FUNCORP’s Head of QA, Alexey Anisimov. If you are an engineer, give it a read as well: these recommendations will help you figure out how to grow and what to ask for from your team leader.

A future senior needs a mentor

While progress from junior to middle mainly relies on developing hard skills, the subsequent upward growth is more related to soft skills, although technical development should not lag either.

Growing from a Middle to a Senior is tricky, and motivation alone may not be enough. A mentor will help you along the way; they can be experienced in seniority and QA leaders.

Foster a desire to understand

In addition to an experienced mentor, someone who wants to grow must have a drive for improvement, including self-improvement. Such people grow into senior roles in a short time.

Here’s how you can incorporate that into the work routine:

Encourage QA engineers to study how the product is structured in architecture and interaction. Let them participate in discussions with developers and teach them that they shouldn’t be afraid to ask even those questions that they find stupid. You can explain this during 1-on-1 meetings and set a personal example.

See that potential Seniors study the tools they work with when testing and figure out what makes them tick. To better understand how things work on the inside, consider avoiding extensive answers to their questions: instead, give them a link to more comprehensive documentation. And sometimes, sending them directly to the doc is helpful instead of providing an answer.

Set higher-level tasks and ask the QA to decompose them on their own. At first, they will need help and example, but later on, this will improve their independence and ability to understand foreign material.

Develop a problem-solving mindset, not a simple delegation mindset. Suggest that the QA engineers go to others with their problems and try to solve them together. For example, they can explain the issue to the developer instead of just reopening the task. Maybe this way, it can be solved faster.

Focus on the problem instead of the solution

Usually, the tasks for midlevel QAs already contain a detailed description of the desired solution: “To test a new service, use this tool and check this and that.” If the QA wants to reach the Senior level, giving them something to think about is better, and they should be the ones to come up with a solution.

If we want to challenge the QA engineer to grow, the example above could be rephrased as follows: “There’s this new service. What do you think is worth testing?” Provide some references to explain how the service was tested before. After all, your QA engineer is not a full-fledged Senior yet. And analyze the decision-making process and the results together.

Encourage sharing knowledge

For QAs, an excellent way to grow is through helping other testers. For example, start by directing people who need help to your Senior candidate. Then ask the candidate to help without waiting for instructions from you, and expect them to take the initiative to help others.

Here are a couple more options:

Make the almost senior a mentor and assign them to a new employee. Ask them to create an onboarding plan for this employee. It should have clear goals and steps. Pay attention to how detailed the project is. Is it enough to teach a beginner? And don’t forget the feedback from the new employee themself: did they get enough information, and was it consistent?

Ask them to make presentations for the internal QA community. For example, the future senior can talk about testing techniques, technology, and the intricacies of the products they are working with.

Teach how to set priorities and manage time

The transition to the senior level is when employees should be given more freedom in setting deadlines and prioritizing tasks. Reduce control gradually. Start by asking for rationale. For example, there are two tasks with the same priority that both require testing. Ask the QA engineers to choose which job they will test first and explain why.

If they cite business benefits and risk reduction, this will be great. If they answer something like “The manager asked me to,” it is worth sitting down and analyzing both tasks to understand why one task has such a high priority, and the other has a lower one.

What else a team leader can do:

Ask the QA to analyze the time spent on the task to understand how to do it faster and better.

Help build goals for the short and long term. Break down the development plan into phases, and describe the timeline and results for each. Make checkpoints at the end of stages to understand the status.

Expand the area of responsibility

As the grade increases, so does responsibility. The first thing you can do is expand the area of responsibility when working with tasks. Ask the QA engineer to get involved in working with the task at the product discussion stage. Expect them to know what metrics it affects and track the task's status after its release. Ultimately, the QA should be responsible for the result, not just the testing quality.

Ask the QA to not just listen to discussions of the product and new features but be an active participant. At first, you can attend such meetings together. Note what kind of questions the QA asks. Discuss what questions they didn’t ask and why to reiterate that there is no shame in asking any questions.

Few more options:

You can expand the area of responsibility within the QA layer as well. For example, ask the engineer to explore the testing infrastructure: find out what they don’t like, listen to suggestions, and take the time to implement the initiatives.

Test automation is also perfect for expanding the area of responsibility. If it is already set up on the project, you can request automation for those tasks that a particular QA handles. If automation doesn’t exist, but the midlevel QA is interested, you can ask them to describe how they would do it and then try to implement the solution together.

Teach to see the whole product

It would be good to expand the QA’s mindset to understand how the task can affect the product and what risks will emerge if the bug is neglected. Be sure to talk about product metrics: which metrics exist in general, which are used for evaluating the business, and what affects what. The QA engineer needs to understand that, apart from technical metrics and logic, there is also the matter of how the product makes money.

If, for example, the QA is only dealing with the backend part, it is worth immersing them in what happens on the client end and how backend changes affect the users.

Also, involve the engineer with processing feedback from real users. This explains how people use the product and which areas are more critical to the user experience.

Appreciate the employee’s opinion and teach them how to present it

Explain how to fully deal with the bugs found: “If you find a problem, make sure it is fixed. To do this, it may be necessary to prove that the problem matters.” Teach the QA to use analytics, and documentation, bring in other people’s expertise, etc.

Tasking the QA with choosing a testing method or tool is excellent for their professional development. For example, the team leader knows that it is necessary to load test some service; they can determine the process and the tool on their own, or they can offer the growing middle QA a chance to choose and rationalize their choice. This will give them an opportunity for self-expression and a chance to formulate their opinion and argue in its favor.

Teach how to analyze mistakes and accept criticism

A QA engineer who is good at analyzing their work will not just improve their skills but will also serve as an excellent example for others. In particular, it is necessary to allocate time for analyzing errors and problem situations.

Here’s what a team leader can do to make it happen:

Talk to the QA. Change their thinking from “finding someone to blame” to “finding a way to avoid this in the future.” Ask them to explain why the incident occurred and make a plan to ensure no similar incidents happen again.

Explain that constructive criticism helps with development and should be accepted calmly, without frustration, and by any colleague. Offer to analyze communications with colleagues: tell them how to collect feedback and why they need to do it regularly.

Reduce control

As long as you are dealing with a midlevel QA, controlling whether they meet deadlines, what and how they test, and how they set priorities is an integral part of the team leader’s job. But as soon as the Middle begins to grow toward Senior, you have to let go: the only thing you ought to control is essentially the result.

You need to make them feel more independent: this will help them take on more responsibility. Control reduction can stem from greater employee autonomy. But as soon as systemic issues emerge, you will need to seize control again and investigate the core reason behind the problem.

P.S. Bonus for team leader: interviews

It’s always easier to raise a Senior QA from someone who aspires to be one. During an interview, you will already see if the candidate is ready to grow in the future by finding out:

How do they perceive responsibility? For example, you could ask them if they have any experience running a project. Do they follow up on the tasks that they tested after release? Were there tasks with tight deadlines, and how did their release go?

Are they showing initiative? To find this out, you can ask if the candidate was able to contribute something to the testing process/tools at their last job.

How do they work on their own? Ask what they would do if they encounter an issue during testing, but the developer responsible is away on vacation. Or how they would start testing a product if there is no documentation and the people who tried it before have already quit.

How do they treat mistakes and criticism? Ask how their 1-on-1 meetings went with the last supervisor and what their colleagues criticized them. Ask them about their failure and how they worked with it.

For QA Engineers

The above will also help you grow, regardless of your project leader. Take responsibility, take the initiative, deal with problems to the very end, be proactive, and do your job to the best of your ability!

P.S. Here’s an excellent related article: 11 Traits of a Senior QA Engineer.