I’m the developer, and you’re the quality guy
The road to hell is paved with good intentions, and your Quality Department is no exception: it’s impossible to distinguish between “doing” and “doing better.”
This statement is an exaggeration, but it’s not all that far from reality. It reveals a conception of quality that, as we’ll see, is dysfunctional.
It all starts with good intentions, though. We have quality issues, so we need to create a “Quality Department.” It’s a bit of wishful thinking, but it still seems to be a step in the right direction.
In reality, we generally see two main scenarios: the “nuisance” department, which annoys everyone and serves no purpose, and the “safety net,” which catches the mistakes of others.
The Nuisance
It’s a team of quality assurance professionals full of good intentions but not hands-on, who ask developers to fill out a whole bunch of risk assessment matrices and measure esoteric KPIs, all while telling them how they should work: test pyramids, Test-Driven Development, and other “best practices.” For developers, who are already under pressure, the Quality Department’s interventions aren’t exactly welcome…
Before long, the KPIs become watermelon KPIs—green on the outside but red on the inside. This term is another way of describing Goodhart’s law: developers end up saying what the quality assurance team expects so that they’ll finally be left alone to work. In the end, no one is happy, and quality suffers.
The Safety Net
The alternative isn’t really any better. This time the Quality Department is fully operational because it runs the tests the developers don’t. These are mostly manual tests, or high-level automated tests (particularly end-to-end tests), because the application isn’t architected to be tested at a lower level—especially at the unit level.
This scenario is problematic because developers have no natural incentive to produce fewer bugs and regressions, since their development errors are corrected by the Quality Department. The astute reader will have recognized what economists call a negative externality, which is corrected by “re-internalizing the externality.” A tax on bugs? Surely not…
What can be done?
The fact that some people focus more specifically on quality isn’t a problem as long as you’re following a “Quality as a Practice” approach (which, by the way, is part of the responsibilities of managers, whether technical or non-technical). Quality shouldn’t be discussed as a separate entity: everything should be quality. We cannot separate development from quality; we cannot separate doing from doing better.
You, as the company’s leaders, should make it a priority to facilitate continuous improvement, provide the necessary training, and help teams establish a framework. Think “Lean” rather than “Quality Department”: quality shouldn’t be a separate role; it should be a requirement integrated into the day-to-day development process.
And in the end, it all comes down to company culture and hiring. You want developers whom you won’t have to convince that untested code is worthless code. You want developers who are eager to improve the way they work. They may lack certain methodological skills, and you’ll be there to help them, but at the very least, the desire to do a good job and intellectual curiosity will be there, and you’ll be able to work effectively.