Mentoring QA without cloning yourself

Most QA mentoring is imitation with good intentions. A senior tester shows a newer one how they write a defect, how they work through a story and which checks they always run, and says: do it like this. Six months later the team has two people who test the same way and miss the same things, and one of them still asks the other before calling anything a blocker.

As Test Practice Manager on a global facilities programme I interviewed QA engineers, mentored them and embedded them across teams. The mistake I see most often is mentoring as copying. What I try to hand over is the criteria behind my habits, because a tester can still use those on the day I am not there.

Why “do it like I do” fails as QA mentoring

A habit is the answer to a question the mentor stopped asking out loud years ago. I run certain checks first because of what the products I have worked on taught me to worry about. Copy the check without the worry and it becomes ritual: run where it does not matter, skipped where it would have.

Imitation has three costs. The mentee can reproduce my output and cannot defend it, so when a developer pushes back on a severity they come to me for the verdict, and I have built a queue with myself at the front. They inherit my blind spots, which removes the reason for having a second tester: different eyes on the same journey. And the habits do not travel: what works on a web back office is wrong in places for a native app or a watch.

The shared criteria a QA team needs

Better mentoring is shared criteria: a written, arguable basis for the calls a tester makes every day. Four questions cover most of them.

The wording above is one example. What matters is where a team’s version comes from. I bring a draft and a handful of real tickets, and we argue each line against them until two people would make the same call without consulting each other. Criteria the team has argued with belong to the team. Criteria they were handed stay mine, and people keep checking with me that they applied them properly.

The defect row pays back fastest. A defect template I introduced cut developer returns by about 40%, and the template was only that row made concrete. I cover the writing itself in Defects Product thanks you for. The last row depends on acceptance criteria Product can sign, because a tester can only spot a missing oracle if they know what a present one looks like.

How I mentor QA engineers day to day

• Pair on the hard ticket, then step back. I take the ambiguous story or the defect nobody can reproduce and work it with the mentee, saying my reasoning aloud. The next one of that kind, they drive and I ask questions. After that I stay out of it.
• Review a sample, for signal. Every few weeks I read a small sample of each person’s cases and defects. I ask whether a developer could act on this without a follow-up question, and whether Product would understand what the user lost.
• Ask for the reasoning before giving mine. “What made this a major?” teaches more than changing the field myself. If the reasoning holds against the criteria and the conclusion differs from mine, the conclusion stands.
• Give people their own numbers. I build dashboards in JIRA or Azure DevOps that show each tester what happens to their work: defects returned for more information, defects reopened, questions waiting on a decision. Nobody has to wait for my opinion to see their own impact.

Those dashboards are for the tester. The first time a returned-defect count is used to rank people it stops being honest, because people start writing tickets to protect the number.

Protecting a tester’s focus on large programmes

On a programme of forty or more people, a newer tester is rarely short of information. They are short of an uninterrupted hour. Judgement develops when someone has room to follow a suspicion to its end, and nobody does that in the gaps between calls.

So I treat the calendar as part of mentoring. I take people out of zombie meetings, the recurring ones that outlived their purpose, for the reasons I give in Stakeholder engagement without meeting inflation. I make ownership explicit, so a question about an area goes to one named person and not to a channel of thirty. And I defend blocks of time for exploratory sessions. Quiet time is a quality tool.

What goes wrong when mentoring testers this way

“It is faster to just tell them.” This week, yes. Every answer I give without the reasoning is one I will give again. Under release pressure I do simply answer, and go back to the why once the build is out. The failure is never going back.

The criteria harden into a rulebook. Applied without thought, a page of criteria is imitation with better documentation. So the page comes with a standing invitation: bring a ticket where the criterion gave the wrong answer, and we change the criterion. A team that has never amended its criteria is not using them.

I correct taste and call it quality. A defect written differently from how I would write it is not a worse defect. If the developer can act on it and Product understands it, what remains is my preference. Noticing that in myself is most of the discipline.

The test of mentoring is the handover. When I leave a team, I want readiness notes that still say what is not known, severities argued from the user’s journey, and open questions that go to Product before anyone guesses. If the practice only produced honest evidence while I was in the room, I was doing the testing through other people’s hands, and it leaves when I do.