Does It Always “Depend”? Finding the Right QA to Dev Ratio

QASource | September 3, 2014

Does It Always “Depend”? Finding the Right QA to Dev Ratio


Over the years we have been asked, and have answered, nearly every possible question about QA. The one recurring question that no one can answer clearly is, “What is the right mix of QA engineers to development engineers?” We admit it: we don’t have a firm answer, either. The ideal ratio of QA to dev depends on several key factors, each of which may change on a project-to-project basis. For this reason, we recommend starting with a small team and scaling up or down as needed.

Assess each of the following variables as you structure your offshore QA and dev teams:

Complexity of the product is a big determining factor in an optimal QA to dev ratio. Consider two examples: a medical imaging system and a children’s computer game. The intended use of the medical imaging system, combined with the greater complexity of its UI and backend, necessitates more testing and thus more QA engineers relative to development.

Deployment of the product is another consideration. Will the product be deployed solely on Mac, or solely on Windows? In cases like this, a smaller QA team may be acceptable. Will it be deployed across various operating systems, including Mac, Windows, iOS, and Android? If so, you will need to increase QA in relation to dev.

Testing requirements will also determine the number of QA engineers you hire. If the product will be used by a government sector or must meet section 508 compliance, intensive testing may be required. The same is true for products that need compatibility testing or internationalization/localization testing. If you need help with increased test requirements, have a detailed look at our test capabilities and QA expertise.

Risk appetite, quality requirements, and time to market will directly influence the amount of testing. These factors vary across industries and from project-to-project. Consider these examples from two of our engagements: we have stopped shipping a product hours prior to release after finding a single bug, and we have shipped a product with 3,000 bugs. High risk appetite, flexible quality requirements, and a fast time to market may leave little room for extensive testing, thus resulting in a smaller QA team.

Coding methods and the ownership that developers take over the quality of their code will also affect the QA to dev ratio. Better code, reusable libraries, and unit testing will usually result in less manual QA engineers, however, there still may be rationale for test automation engineers.

QA timing plays a big role in how many engineers you will need. If QA is rushed in at the tail end of a project, a larger team may be required to handle the workload. However, if QA is pursued early on, a smaller team may be suitable. Learn more about how to see extra value from your QA team.

Though a 1:1, 1:2 or a 1:3 QA to dev ratio is often considered standard, it is important to remember that these numbers are always subject to change. The optimal ratio is one that remains flexible as your project matures, and the best team structure is one designed for scalability.

Did you find this post useful for offshore QA or onsite team management? If so, share it with your professional network on LinkedIn. If you know of other factors that affect the optimal QA to dev ratio, leave a comment below.


This publication is for informational purposes only, and nothing contained in it should be considered legal advice. We expressly disclaim any warranty or responsibility for damages arising out of this information and encourage you to consult with legal counsel regarding your specific needs. We do not undertake any duty to update previously posted materials.