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.
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.
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.