Leading quality in a large team

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.