Coaching developers; embedded quality models

A QA engineer who only tests what developers hand her will always be behind, because by the time code reaches her it has already shipped its assumptions baked in. The senior version of the job includes teaching developers to write better tests themselves, catch obvious bugs before a pull request, and think about edge cases without being reminded every single time. This is coaching work, not policing work, and it is one of the most underrated skills on the roadmap.

Why this falls to QA in the first place

Most developers were never taught to write good tests. They learned to write code that compiles and passes the happy path, and testing got bolted on later, often taught badly by whoever was around at the time. A QA engineer who understands both the product and the failure modes is often the best person on the team to close that gap, even though nobody officially assigned it.

At a payments startup, one QA engineer noticed the same pattern of bugs shipping every sprint: null checks missing on optional fields, tests that mocked the exact response the code expected instead of testing real behavior. Rather than filing the same bug type for the fifth time, she ran a 30 minute session showing two real examples pulled from their own codebase, one broken test and one good one, side by side. The pattern of bugs dropped noticeably within a month.

Coaching, not correcting

The failure mode is turning every code review comment into a lecture. Nobody responds well to "you should have tested this" written on a pull request for the tenth time. What works better is pairing on a specific case: sit with a developer while they write a test for a real bug that just happened, and let them see the gap themselves rather than being told about it.

What good coaching actually looks like

Good coaching is specific and low frequency, not a weekly mandatory workshop nobody wants to attend. A short pairing session tied to an actual bug, a five minute comment on a pull request that explains why a test misses a case rather than just flagging it, and an occasional short writeup of a bug pattern the team keeps repeating. This connects to owning the test estate, because a healthy suite depends on developers contributing tests that are actually worth keeping, not just quantity added to hit a coverage number.

• Use real, recent bugs from the team's own code, not generic examples from a blog post.
• Pair on the fix rather than assigning homework; watching the gap land beats reading about it.
• Keep sessions short and specific. A 15 minute pairing session beats an hour long workshop.
• Track recurring bug patterns and address the pattern once, rather than each instance separately.

Coaching also changes how a QA engineer is perceived. Someone who only files bugs looks like a bottleneck. Someone who visibly makes the rest of the team better at catching their own mistakes looks like a force multiplier, and that distinction shows up directly in promotion conversations. It is also a strong entry for proof of work: a short writeup describing a bug pattern you coached out of a team, with a before and after, is more convincing in an interview than a list of testing tools you know.

The limit worth naming honestly: coaching does not replace a QA engineer's own testing work, and it does not scale to a team that has no interest in improving. Some developers will never care about test quality no matter how it is presented, and forcing the issue past a certain point becomes a management problem rather than a coaching one. Knowing where that line sits is part of doing this well.

FAQ