I was recently chatting with a middle manager, who was facing the challenge of improving quality on a development team that is part of a larger organization that still relies heavily on manual software validation before release. This manager was looking for ways to help manage the dependency on a slow, external QA team for manual verification.

This manager agreed with me that a separate testing phase, managed by an separate QA team, was an anti-pattern that ultimately hurts quality, rather than improving it, and that the proper approach is to remove or mitigate the dependency, rather than adding policies to manage it. However, he was resigned to the fact that eliminating the dependency would require an organizational re-organization of some sort, that was beyond his immediate control.

But… is that really true?

I’ve worked with many companies that have a separate, manual QA process. But I’ve never waited for a re-org to make quality the developers’ responsibility, even if just on my own team. Or when I’m an IC, just for myself.

As an individual developer, or as a development team, you never need to wait for a re-org, or any other kind of permission, to start doing quality work.

Just pretend that the QA team isn’t there. Do your own testing. Get your own feedback as quickly as you can. Build your own QA process. The QA team will no longer be your bottleneck, regardless of the org structure. And the QA team will quickly learn that your features don’t need extensive testing, becuase they’re already high quality. Or they won’t. And it will be on them to re-test your already rock-solid code. Either way, you’ve built a better product you can be proud of.