What’s the right ratio of developers to testers?

What’s the right ratio of developers to testers?
Photo by Aniket Deole / Unsplash
What’s the right ratio of developers to testers?

For as long as testers have been working with (other) developers, this question has existed. It’s a question focused on a false belief there is a right ratio in staffing levels across the industry.


Ratios are relationships between two numbers. Compare the numerator to the denominator and you’ve got yourself a ratio.

You can question that relationship:

  • What ratio is too high?
  • What ratio is too low?
  • What ratio is just right?

You can even share that relationship:

My lowest ratio was 1 developer to 2 testers. I was testing internal regulatory engines and originations at a mortgage company. Lots of focusing on getting the calculations correct.

My highest ratio was 7 developers to 1 tester. This has happened a few times in my career in consumer tech startups. I've also been on teams (not as a tester) with 0 testers but there’s no ratio in that situation.

Same title, Different work

The work was often very different in each company. Testers do a wide range of things across a wide range of organizations and industries.

For example, while holding a testing title I've:

  • Written documentation
  • Built and maintained internal tools
  • Handled test infrastructure
  • Provided risk assessments
  • Helped with technical support
  • Managed product development
  • Investigated bugs
  • Fixed bugs
  • Written UI and API tests in several languages and frameworks

Among several consumer tech startups, the work I did was different. Some commonalities included writing documentation, providing risk assessment and investigating bugs. Yet I've managed product development in one job. I've helped in tech support. I've handled test infrastructure twice. This makes direct comparisons between past experiences hard.

If we can't rely on ratios to help us to make hiring decisions, how do we make those decisions?

Hire based on work backlog

First, hire based on a backlog of existing work. Often times we see the work piling up and decide we need to hire help. Look for a backlog of tickets or a list of technical debt and solve for that problem.

Hire based on historical data

Second, hire based on historical data. Part of hiring is anticipating what future staffing needs might be. This is where ratios might be applicable. I’ve used historical information to anticipate hiring needs with success. We created new business lines with similar organizational structures which allowed us to predict when to hire.

Supporting Research

An influential paper published in 2001 on the ratio of testers to other software developers had a big impact on how I think about this problem. In the workshop (STMR) behind the paper, the participants didn’t find a correlation in tester to developer ratios in good projects. Yet they found a strong correlation in bad projects.

I recently listened to a few podcasts with Elisabeth Hendrickson where she talks about the work on ratios and I recommend a listen:

The paper concludes in the same way I started this article: there is no right ratio across the industry. Hire based on your needs and you’ll do better.

The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester, which aims to provide responses to common questions and statements about testing from a context-driven perspective.

It's being edited by Lee Hawkins who is posing questions on Twitter,  LinkedIn,  Slack, and the AST mailing list and then collating the replies, focusing on practice over theory. This was my reply.

Subscribe to Shattered Illusion by Chris Kenst

Sign up now to get access to the library of members-only issues.
Jamie Larson