Creating a product factory (solving the developer to QA Ratio)
For most of you, this might seem to be a rather arcane topic. But to any IT leader, getting the developer to QA ratio right can make or break your product success. We all want to create a product factory where software engineers create quality code that can be deployed frequently. Quarterly release cycles are a relic of the past.
Unfortunately, there is not a definitive answer on what the correct ratio should be. There are many factors that go into establishing a ratio that makes sense for your organization. I've seen both ends of the spectrum (almost non-existent QA resources to QA resources outnumbering developers). What your current ratio is tells a story about your product.
If you have more QA resources than developers, does that mean your software developers write bad code? Does it mean developers aren't doing any testing? Does it mean requirements weren't written clear enough to know what success means? Does it mean that the software is so complex that testing is very hard? Does it mean automation is not in place? Does it mean you are using outdated technology requiring additional resources to perform QA? Does your software require extensive integration with 3rd parties requiring additional QA resources?
Whatever your answers are, having a 1:1 or 1:1.5 developer to QA ratio means you need put a microscope on your product life cycle. To properly scale a product, you want more software engineers than QA resources. Should you have a 3:1 or 10:1 developer to QA ratio will depend upon your specific application stack and integration points.
If you have your development team integrating unit tests into their development cycle, use common object oriented development frameworks and have created a continuous integration environment, you should be able to achieve a high developer to QA ratio. There are so many tools today to assist with automation that having a 1:1 or 1:1.5 developer to QA ration most likely means you haven't invested enough in your development methodologies and automation. Recently I've used Mocha for unit testing of NodeJS code, Jenkins for continuous integration, Browserstack for browser test automation, Blazemeter for automated load testing, Black Duck Software for automated security and compliance, SonarQube for static code analysis, OWASP ZAP for OWASP top 10 vulnerability testing. Integrations exist with Gitlab, Github, and Bitbucket for linking in your code repository. Likewise, Google and AWS have tools to assist with automation.
The point is there are numerous automation tools for all development languages. Automation alone doesn't solve the developer to QA ratio as someone still has to setup the automation and evaluate the results. Don't get caught in the extremes of having no QA resources (or having developers doing QA) or having as many QA staff as software engineers.