Mentoring Junior QA Engineers
Teaching vs. Telling
There is a fundamental difference between telling a junior engineer "write a test for this" and teaching them how to think about what needs testing and why. Telling produces compliance. Teaching produces capability. The goal of mentoring is not to create someone who follows your instructions. It is to create someone who, given an unfamiliar situation, can figure out the right approach on their own.
Great mentors do not produce people who test the way they test. Great mentors produce people who think critically about quality and develop their own effective style.
The Mentoring Mindset
Principles
Ask before you tell. When a junior comes to you with a question, resist the urge to immediately give the answer. Instead, ask questions that guide them to discover it:
Junior: "Should I automate this test?"
Bad mentor response: "Yes, automate it with Playwright."
Good mentor response: "How often does this test need to run? What is the cost of running it manually each time? Is the UI stable enough that the test will not be flaky? What do you think?"
Make thinking visible. When you are testing, narrate your thought process out loud. Juniors cannot learn your reasoning if they only see your actions.
"I am going to test the coupon field next. I am prioritizing it because coupons involve money, and money-related bugs have high business impact. My first test will be a valid coupon, to make sure the happy path works. Then I will try an expired coupon, a coupon for a different product, a coupon with extra spaces, and no coupon at all. I am thinking about boundary conditions and negative cases."
Normalize not knowing. When you do not know something, say so openly. "I am not sure how this API handles concurrent requests. Let me look it up." This teaches juniors that expertise is not about knowing everything -- it is about knowing how to find out.
Separate feedback on the work from judgment of the person. "This test case is missing edge cases" is feedback on the work. "You always miss edge cases" is a judgment of the person. The first is constructive. The second is destructive.
The First 30/60/90 Days
A structured onboarding plan prevents the common failure mode where a junior QA engineer sits at their desk for three days reading documentation before anyone checks on them.
Days 1-30: Learn and Observe
| Week | Focus | Activities | Deliverable |
|---|---|---|---|
| 1 | Product knowledge | Product tour, user journey mapping, read existing test cases, shadow a senior QA | Written summary of top 5 user flows |
| 2 | Tooling and environment | Set up dev/test environments, learn the test framework, run existing test suites | Successfully execute the full regression suite |
| 3 | Process | Attend all sprint ceremonies, learn the bug reporting process, review past bug reports | File 3 well-written bug reports (reviewed by mentor) |
| 4 | First contribution | Write 5 test cases for a low-risk feature, execute them, report results | Test cases reviewed and approved by mentor |
Days 31-60: Contribute with Support
| Week | Focus | Activities | Deliverable |
|---|---|---|---|
| 5-6 | Independent testing | Own testing for a small feature, write test cases, execute, file bugs | Complete test coverage for one feature |
| 7-8 | Automation basics | Write first automated test (with mentor pairing), learn the CI pipeline | 3-5 automated tests merged and passing in CI |
Days 61-90: Contribute Independently
| Week | Focus | Activities | Deliverable |
|---|---|---|---|
| 9-10 | Expanded scope | Own testing for a medium feature, participate in three amigos | Test plan for a feature (reviewed by mentor) |
| 11-12 | Growing autonomy | Identify test gaps independently, propose improvements, mentor newer team members | Self-assessment of skills and goals for next quarter |
Pairing Techniques
Pairing is the single most effective mentoring tool. It provides real-time feedback, models expert thinking, and builds relationship trust.
Exploratory Testing Pairs
Format: Senior and junior test the same feature together for 30-60 minutes.
How to run it:
- Senior starts by exploring for 10 minutes, narrating their thought process
- Junior takes over, with senior asking guiding questions: "What would happen if...?" "Have you tried...?" "What are the boundaries here?"
- Debrief: discuss what was found, what was missed, and why
Code Review Walkthroughs
Format: Review a PR together, with the senior explaining what they look for and why.
What to point out:
- "I check the test file first. If there are no tests, that is a red flag."
- "This function has three nested conditionals. That means there are at least 8 paths to test."
- "This database query does not have a limit. What happens with 10 million records?"
Automation Coaching
Format: Build a test together using the driver-navigator pattern.
- Junior writes the code (driver). Senior guides the approach (navigator).
- Switch roles after 15-20 minutes.
- The junior should be driving 70% of the time. The point is for them to build muscle memory.
Giving Feedback: The SBI Model
The SBI model (Situation, Behavior, Impact) structures feedback so that it is specific, objective, and actionable.
Structure
- Situation: When and where did the behavior occur?
- Behavior: What specifically did the person do? (Observable facts, not interpretations)
- Impact: What was the result of that behavior?
Examples
Constructive feedback:
Situation: "In yesterday's sprint review..." Behavior: "...you presented the test results with clear metrics -- pass rate, coverage delta, and the two open risks." Impact: "The product manager said afterward that it was the first time she really understood the quality status. That kind of clarity builds trust in QA."
Corrective feedback:
Situation: "On the bug report you filed for SHOP-234..." Behavior: "...the steps to reproduce were missing the browser version and the specific test data you used." Impact: "The developer spent 2 hours trying to reproduce it before asking you for more details. That slows down the fix and creates frustration."
Follow up with a question, not a demand: "How can we make sure reproduction steps are complete before filing?"
Common Mistakes Junior QA Engineers Make
| Mistake | Why It Happens | How to Coach Through It |
|---|---|---|
| Testing only the happy path | They follow the spec literally without thinking about what could go wrong | Teach them to ask "What if?" for every input, state, and interaction |
| Filing vague bug reports | They do not realize how much detail developers need | Review their first 10 bug reports together; provide a template |
| Automating everything | They think automation means quality | Teach the test pyramid and ROI-based automation decisions |
| Not asking questions | They fear looking incompetent | Explicitly say "I expect you to ask questions. Not asking is the mistake." |
| Comparing themselves to senior engineers | They feel inadequate because they cannot do what the senior does | Remind them of the growth timeline. Show them your old code or early bug reports. |
| Over-relying on the mentor | They ask for help before trying to solve it themselves | Establish a rule: "Try for 20 minutes, then ask. When you ask, tell me what you tried." |
| Skipping exploratory testing | They treat the test case list as exhaustive | Pair on exploratory sessions; show them what structured exploration looks like |
| Not communicating blockers | They sit stuck for hours without telling anyone | Check in proactively. Create a safe channel for "I am stuck" messages. |
Setting Expectations and Tracking Growth
Skills Matrix
Create a simple skills matrix and review it monthly:
| Skill | Month 1 | Month 3 | Month 6 | Target |
|---|---|---|---|---|
| Bug report quality | Learning | Competent | Proficient | Proficient |
| Exploratory testing | Learning | Learning | Competent | Proficient |
| Test case design | Learning | Competent | Competent | Proficient |
| Automation (basic) | Not started | Learning | Competent | Competent |
| CI/CD understanding | Not started | Learning | Competent | Competent |
| Product domain knowledge | Learning | Competent | Proficient | Expert |
| Communication in ceremonies | Learning | Competent | Competent | Proficient |
Regular Check-ins
- Weekly 1:1 (30 min): What went well? What is challenging? Any blockers? Feedback in both directions.
- Monthly skills review (45 min): Update the skills matrix. Celebrate progress. Set goals for the next month.
- Quarterly career conversation (60 min): Where do they want to be in 1 year? What skills do they want to develop? What experiences do they need?
When to Let Them Fail (Safely) vs. When to Intervene
This is the hardest judgment call in mentoring. Too much intervention creates dependency. Too little creates frustration and wastes time.
Let Them Fail When:
- The failure is recoverable (a missed bug in staging, not production)
- The learning from the failure is high-value
- They have the tools and knowledge to recover on their own
- The failure will not affect other people's work significantly
Example: They write a flaky test. Let it fail in CI. Let them investigate why it is flaky. Let them discover the race condition themselves. Then discuss what they learned.
Intervene When:
- The failure would affect customers or production
- They are stuck and visibly frustrated (past the productive struggle point)
- They are about to make a mistake that would take days to undo
- The mistake would damage their relationship with the team
Example: They are about to file a bug report that accuses a specific developer of carelessness. Intervene before they send it. Coach them on neutral language.
The "Struggle Zone" Framework
Comfort Zone → Too easy, no growth
Struggle Zone → Challenging but achievable, maximum growth
Panic Zone → Too hard, causes anxiety and shutdown
Your job as a mentor is to keep them in the struggle zone as much as possible. Adjust the difficulty of assignments up or down based on where they are.
Building Confidence in Juniors Who Doubt Their Technical Abilities
Imposter syndrome is extremely common among junior QA engineers, especially those who come from non-CS backgrounds or who work alongside experienced developers.
Strategies
Acknowledge the feeling as normal. "Everyone feels this way when they start. I felt this way. The senior developers felt this way. It fades with experience and evidence."
Create early wins. Assign tasks that are challenging enough to feel meaningful but achievable enough to succeed. Each completed task builds the evidence that counteracts self-doubt.
Make their contributions visible. When they find a good bug, mention it in standup. When they write a clean test, point it out in the code review. When they ask a smart question in planning, tell them afterward.
Normalize the learning curve. Share the timeline: "At 3 months, I expect you to be competent at X. At 6 months, Y. You are ahead/on track/we need to focus on Z." Concrete timelines replace vague anxiety with clear expectations.
Separate technical skill from worth. "Not knowing how to write a Playwright test does not make you a bad QA engineer. It means you have not learned it yet. Let me show you."
Hands-On Exercise
- Write a 90-day onboarding plan for a junior QA engineer joining your team, customized to your product and tech stack
- Practice the SBI model: write one constructive and one corrective feedback example based on a recent interaction
- Identify one junior engineer mistake from the table that you have seen recently. Design a coaching approach to address it.
- Create a skills matrix for your team or mentee. Identify the biggest gap and propose a plan to close it.
- Reflect on your own experience being mentored. What did your best mentor do that you want to replicate? What did your worst mentor do that you want to avoid?