What’s the ideal ratio of devs to QAs?

I hear this question asked every now and again. Of course, as a consultant, I can confidently tell you: It depends! (I’ll send a bill.)

But let’s get real. There’s practically always an assumption built into this question that makes it actually trivial to answer. That assumption is: QAs are acting as a bottleneck to releasing software. This usually takes one of two forms:

• Devs write code, then pass it off to QA who tests it before release
• Devs write code, then QA writes tests before release

In either case, every new code change must wait in a queue for an available QA person to do their part before the code is released.

So in these scenarios, what’s the ideal ratio of devs to QAs? This one is easy:

∞:0

Yes, that’s right. Infinite devs to zero QAs.

Here’s the thing…

Except in literal life-and-death types of situations, QA should not stand between developers and releasing to production. Devs need to be writing their own tests. There’s simply no other way to achieve continuous delivery/deployment.

And an interesting thing we’ve learned from the last several years of the State of DevOps reports is that “having automated tests primarily created and maintained either by QA or an outsourced party is not correlated with IT performance”.

So rather than having your QA Engineers do either manual testing, or writing automated tests, have them build and maintain the test automation framework, and provide training and mentoring to devs as needed, on new testing techniques.