Team Mentoring
A test lead's real product is not test scripts. It's people who can write test scripts. Learn how to build an automation culture that outlasts any individual.
1 The Hook — Why This Matters
Auckland-based SaaS company Pushpay had one senior automation engineer who built their entire framework. When he accepted a role overseas, the team discovered that no one else understood the dependency injection container, the custom DSL, or the CI pipeline triggers. Regression testing stalled for six weeks. The company hired two contractors at $250/hour to reverse-engineer the suite. The knowledge wasn't documented because "everyone knew how it worked" — until they didn't.
Test leads build systems that survive turnover. If your automation program depends on one person's memory, it's not a program. It's a hobby with a bus factor of one.
2 The Rule — The One-Sentence Version
Every critical system, pattern, and decision must be documented, reviewed by someone else, and executable by a new hire within their first week.
Pair programming, code review, and documentation are not overhead. They are insurance against catastrophic knowledge loss. The test lead's job is making the team's capability greater than any individual's.
3 The Analogy — Think Of It Like...
A sports team where only the star player knows the playbook.
When the star gets injured, the team loses every game. A coach's job is ensuring every player knows the plays, the formations, and the adjustments. Test leads are coaches. Your "players" are automation engineers. Your "playbook" is the framework, patterns, and standards. If only one person knows the playbook, you're not leading a team. You're managing a solo performer.
Senior engineer insight
The most effective mentoring I have seen happens in code review, not pairing sessions. When a senior engineer leaves a comment saying "this selector will break the moment the dev team renames that CSS class — look for a data-testid instead", that one comment teaches selector stability, ownership thinking, and professional standards in thirty seconds flat. I stopped scheduling weekly pair sessions and instead doubled down on thorough, annotated PR reviews. Within three months the team's test reliability went from 72% to 91%, and juniors were catching each other's brittle selectors before I ever saw them.
The most common mistake: treating code review as a quality gate rather than as the primary teaching surface — so reviews become a rubber stamp rather than a mentoring conversation.
From the field
On a large TransitNZ (TransitNZ) system integration, we inherited a Selenium suite from a contractor who had left six months earlier. The team assumed the tests were green — they were just disabled in CI. When we re-enabled them, 140 out of 180 tests failed because the internal portal had been upgraded and every XPath was stale. We spent two weeks in triage before we realised the real problem: nobody on the permanent team had ever written or reviewed a test. There was zero shared ownership. We paused new feature automation entirely for a month and ran daily mob-programming sessions where each team member had to fix at least one failing test and explain their reasoning to the group. By the end of the month, three testers who had never written code were independently patching locators. The lesson: automation capability in a team is not measured by what exists in the repo, it is measured by how many people can confidently change it.
4 Watch Me Do It — Step by Step
Here is a structured mentoring framework for growing automation capability.
- Pair programming with the Angie Jones model
Embed an experienced automation engineer with manual testers for 2-3 months.
- Week 1-2: Mentor drives, mentee observes
- Week 3-4: Transition to mentee driving
- Week 5-8: Independent work with code review
- Ongoing: Code reviews as the learning mechanism
Focus only on language constructs needed for automation. Don't teach full Java or Python — just enough to write tests.
- Define the skills ladder
Level Coding Testing Architecture Leadership Junior Basic scripts; needs guidance Executes manually Uses existing framework Seeks help proactively Mid Comfortable with OOP Designs cases independently Extends framework Mentors juniors informally Senior Refactors complex code Risk-based test design Designs frameworks Drives automation strategy Lead Sets coding standards Aligns with business risk Platform thinking Hiring, roadmaps, stakeholders - Structured 30-60-90 day onboarding
- Days 1-30: Environment setup, codebase walkthrough, shadowing, first simple test merged
- Days 31-60: Independent medium-complexity tests, first code review given
- Days 61-90: Leads small automation initiative, presents in demo, identifies one process improvement
5 When to Use It / When NOT to Use It
✅ Invest in mentoring when...
- Team has manual testers eager to upskill
- Automation headcount is constrained
- Domain knowledge is hard to hire for
- Retention is a known challenge
❌ Hire externally when...
- You need framework architecture expertise immediately
- Team lacks anyone with programming fundamentals
- Timeline doesn't allow for 3-month upskilling
6 Common Mistakes — Don't Do This
🚫 Throwing testers into code without support
I used to think: If they want to learn automation, they'll figure it out.
Actually: Unstructured learning creates bad habits that are expensive to unlearn. Provide structured pairing, documented patterns, and safe environments for experimentation. Learning by failing is effective only when someone is there to explain why.
🚫 No code review culture
I used to think: Code review slows us down.
Actually: Code review is where learning happens. Every review is a teaching moment. Require one approval from a senior automation engineer on every PR. Run weekly "review of reviews" to discuss patterns and anti-patterns as a team.
🚫 Knowledge silos
I used to think: Specialisation makes experts more productive.
Actually: Specialisation without cross-training creates bus-factor risk. Rotate pairing assignments. Ensure every critical system has at least two people who can maintain it. Document architecture decisions (ADRs) and update them when things change.
7 Now You Try — Interview Warm-Up
Scenario: You have three manual testers who want to transition to automation. None have programming experience. Your budget allows one external hire or internal upskilling. The team uses Playwright with TypeScript.
What is your 6-month plan?
The plan:
- Hire the senior: Bring in one external senior automation engineer to set standards and provide mentorship.
- Start with BDD: Have manual testers write Gherkin scenarios first (no code). This teaches thinking in automation without syntax barriers.
- Progress to API: API tests are more stable than UI. Teach REST fundamentals and basic assertions.
- Introduce UI automation: Pair each manual tester with the senior for 2 months on real Playwright tests.
- Code review loop: By month 4, each upskilled tester should be giving code reviews to peers. By month 6, they should own small features independently.
Why teams fail here
- Mentoring without a skills ladder: Engineers are paired and coached but nobody tracks progress against defined levels, so growth stalls at "can run the suite" rather than advancing to framework ownership or test design.
- The hero-mentor bottleneck: All code review and pairing flows through one senior engineer. When that person is on leave, sick, or in back-to-back meetings, the whole team blocks — recreating a new single point of failure at the mentoring layer rather than the code layer.
- Teaching tools instead of thinking: Juniors learn "how to use Playwright" but never learn how to decide what to automate, when not to automate, or how to evaluate whether a test adds value vs. adds noise. Tool literacy without testing judgment produces high-volume, low-value suites.
- No psychological safety in review culture: In organisations with a blame culture — common in NZ government and banking contexts where audit scrutiny is high — engineers stop asking questions and hide poor-quality tests behind passing CI. Mentoring fails entirely if people fear being seen as incompetent for asking basic questions during code review.
Key takeaway
Your job as a test lead is not to be the best automation engineer on the team — it is to become unnecessary, because you have made everyone else capable enough to not need you.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. What is the Angie Jones model for pairing manual testers into automation?
Embed an experienced automation engineer with manual testers for 2-3 months. Start with mentor driving, transition to mentee driving by week 3-4, focus only on language constructs needed for automation, and graduate to independent work plus code reviews.
Q2. What are the three phases of a 30-60-90 day onboarding plan?
Days 1-30: Environment setup, shadowing, first simple test merged. Days 31-60: Independent medium work, first code review given. Days 61-90: Lead small initiative, present in demo, identify process improvement.
Q3. Why is cross-training more important in NZ than in larger markets?
NZ has a smaller talent pool for dedicated automation engineers. Cross-skilling manual testers is often more viable than external hiring. Additionally, distributed remote teams in NZ benefit from strong documentation and shared knowledge over "shoulder-tap" support.