What is a good ratio of software developers to testers on an agile team?

The developer:tester ratio question comes up a lot and I find most, if not all, answers are “it depends”.

I won’t say “it depends” (it’s annoying). I will tell you what works for me given my extensive experience, but will provide some caveats.

I’ve worked on different agile software development teams as a tester for a number of years and I personally find a ratio of 8:1 developers to tester(s) (me) works well (that’s 4 dev-pairs if pair programming). Any less developers and I am bored; any more and I have too must to test and cycle time is in jeopardy.

Some caveats:

  • I’m an efficient tester and the 8:1 ratio works well when there’s 8 equally efficient programmers on the team – if the devs are too slow, or the user stories are too big, I get bored;
  • Everyone in the team is responsible for quality; I have to make sure that happens;
  • A story must be kicked off with the tester (me) present so I can question any assumptions/anomalies in the acceptance criteria before any code is written;
  • A story is only ready for test if the developer has demonstrated the functionality to me at their workstation (bonus points in an integrated environment) – we call this a ‘shoulder check’ – much the same way as monkeys check each others shoulders for lice;
  • A story is also only ready for test if the developer has created sufficient and passing automated test coverage including unit tests, integration tests (if appropriate) and some acceptance tests; and
  • Bug fixes take priority over new development to ensure flow.

What ratio do you find works for you?

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

7 thoughts on “What is a good ratio of software developers to testers on an agile team?”

  1. Arent the caveats you mentioned “dependencies”? And those dependencies depend on further dependencies. I understand the cliche “it depends”, however that is the realty and in this article they are worded as caveats instead of “dependencies”. The ratio of developers to testers I believe is a case-case analysis [analysis guidance from your caveats] and while i know on average 2:1 is too low and 10:1 is too high, a range in between is where i would like to leave it. The team can expand or contract the “qa” role or distribute the responsibilities as they pivot.



    1. Yes, you can interpret it that way. 8:1 is value I have found that works really well for me. Having those things listed (like devs responsible for auotmated tests) also works really well for me. So if someone asked me how many testers do I need for this many developers, instead of saying a range I can give a specific number, with some conditions (caveats) attached which we can put in place. Cheers!


  2. Most teams I’ve worked on for the past 15 years supported that 8:1 ratio, with the caveats you mention. However, I find this is also quite dependent on domain. I worked for quite a few years on a financial services application. Not only did we have to make sure we didn’t lose anyone’s money, we had to help customers stay in compliance with a host of complicated, illogical government regulations. On that team, over nine years, we went from having four programmers and one tester, to having four programmers and three testers. Even though the team mastered good practices such as TDD, refactoring, great regression test coverage at all levels, short feedback loops, working closely with customers and so on, it was so testing-intensive.

    On less risky applications, such as the one I work on now (a project tracking tool), then a higher ratio of programmers to testers works.

    Also in the mix could be other roles. On that financial services app, if we’d have had a good business analyst, we could have had fewer testers.


  3. I also think that we need to understand the risk, as Lisa says, as well as the attributes of the solution under test. For a focus on functional testing a ratio of 8:1 may be ok, but when the testing has to move beyond functionality into the various non-functional aspects then the workload on the testers would increase. Additional effort and ratio adjustment would also have to come into consideration for regression risk and test approach. Automated regression testing through the build pipeline can help manage this but must be built into the approach as well.


  4. I like your summary Alister.
    Our scrum team consists of 5 devs, a scrum master, 2 product owners (its complicated…), a tester who’s a subject matter expert, and a test automation specialist (me). So, depending on how you count, it’s a 5:1 or 5:2 ratio.
    I’m never bored, but that might be because we’ve got quite an aspirational ‘definition of done’, where gui driven test automation that covers (and proves) all new changes before we say it’s ‘done’.
    This addition of new coverage alongside the continual refactoring of this behemoth of a nightly regression suite means I’m always busy.
    You said: “A story is also only ready for test if the developer has created sufficient and passing automated test coverage including unit tests, integration tests (if appropriate) and some acceptance tests”.
    As a result of our defn of done, there isn’t really a concept of ‘ready for test’ in our little team, and the velocity of delivery is impressively optimised.
    More parallel testing (by more testers) I say!


Comments are closed.