Talk Description
Charles Penn shares his experience as the sole test lead (alongside one or two other testers at any given time) on a project with 60+ developers. A complete rewrite of two interconnected desktop applications for a client in the construction industry. What was estimated as a one-year project ran for eight years, and Charles reflects candidly on the arc of the project and the lessons it taught him.
Key lessons learned:
- Delegation is unavoidable at scale and letting go of hands-on work is genuinely hard if you enjoy it.
- Advising and guiding becomes the job. Writing wiki pages, training materials, and coaching developers matters more than writing tests yourself.
- Domain knowledge is critical. Charles would prioritise deeper, earlier relationships with domain experts if starting again, rather than relying on a single PO as the knowledge bottleneck.
- Tool choices have long-term consequences. He'd reconsider the use of TestComplete given its cost and quirks, noting how difficult migration becomes once the test suite is large.
- Be more assertive early. His quieter personality meant he was sometimes edged out of key conversations by stronger personalities, which he'd push back on with hindsight.
- Rotating test triage ownership. A system where teams take weekly turns investigating test failures helped avoid the "everyone's problem is no one's problem" trap.
- Code coverage as a metric has limits, particularly with pass-through code layers and, increasingly, AI-generated tests that inflate coverage without adding value.
Charles Penn
Senior Test Engineer
He/Him/His
Software tester in the Midwest of the US.
Typically happy to discuss testing of any sort, geeky things, and parenting.
Charles Penn
Senior Test Engineer
He/Him/His
Software tester in the Midwest of the US.
Typically happy to discuss testing of any sort, geeky things, and parenting.
Sign in
to comment
