Navigation Layout: Stacked Header Style: Light

Should my company ditch Testers and use Quality Coaches instead?

Should my company ditch Testers and use Quality Coaches instead?
Photo by Natalia Y. / Unsplash

TL;DR: Quality coaching is a model you grow into, not adopt. That's because testing is an acquired skill, and teams must learn how to test. Pairing is an optimal way to learn about testing. As teams learn about risks, test design, and exploratory testing, they can preempt risk and build quality into their design. As a team matures in its quality practices, a tester may feel their role becomes redundant. This is a great time to introduce a quality coach.

A fairytale in tech

A long time ago (10 Julian calendar years, centuries in Bezo years), a fairy godmother was asked to devise a way of scaling testing in a hypergrowth company. The independent test team was small then, with minimal automation coverage. The engineering department was hiring rapidly, and as the number of product teams grew, so did the number of features being deployed. Consequently, this test team struggled to test quickly, rapidly becoming a bottleneck.

The fairy godmother was wise. While pushed to increase the size of the team and increase test automation, she knew these solutions only patched up a problem that others couldn't see. And, as the team scaled, this problem would only be exacerbated.

What the team desired most of all was access to the Book of Knowledge. Of course, the Book of Knowledge wasn't a real book. It wasn't even a confluence page. The Book of Knowledge was the company's songline. Passed from engineer to engineer, these verbal conversations shared the history of any change.

The test team desired most of all to be included in these stories. To hear what the changes were and why changes were being made. They knew if they had access to this book, they would begin to understand the why and the what and test with that change in mind. Without the book, they searched aimlessly through code, attempting to figure out what had changed.

The fairy godmother sent each tester on a quest. "Go forth, sit among the teams, learn their ways and learn the secrets of the book of knowledge". And so it came to be, the testers slowly began to understand the why and the what. They sat closely with the engineers, pairing to test early and often. They asked questions about changes early on, pointing out impacts to other system parts.

The engineers, at first were skeptical. Who were these strangers from a foreign land, unused to their ways of working and unable to code efficiently? But the testers persisted until gradual change came. Engineers began to ask testers for their input. They began to learn their ways. Slowly teams began to embed tester's concerns into their work.

Until one day, a very smart tester approached the fairy godmother with a concern. "What shall I do?" the tester wailed. "I no longer have anything to test! The engineers have learned all my wise ways and are doing it themselves!"

Thus, the quality coach role was born. Not out of cost-cutting but because of existent team maturity. A quality coach who could help teams maintain quality through facilitation and guidance.

Now, the fairy godmother helps other teams and companies shift to a quality coach model. But she has never forgotten that company, where quality coaching was not adopted, but through pairing and coaching emerged.

FGM's advice to senior leadership.

Some words of wisdom for senior leadership.

  • Quality has a cost, regardless of who does it. Your engineers must have additional time and space to perform software testing and quality-related activities. As a heuristic, if you remove a tester from a team, double the time engineers require to perform the same work. Failing to do so puts stress and possibly unrealistic expectations on teams.
  • Rolling out a quality coach model without an embedded tester coaching and mentoring a team is possible. Allow for longer timeframes.
  • Teams that have worked extensively together, have deep domain knowledge, and have the agency to experiment and learn will benefit more from a quality coach model than a newly formed team that has never owned testing without a tester.
  • Teams will make mistakes, you must allow them the space and time to learn these new skills.
  • Not all teams will benefit from quality coaching. Allow teams multiple models and let them decide if they need a tester or a quality coach

That's it! I hope you all manage to get some rest over the holiday period. See you all in 2024!