What is the best ratio of testers to developers in an agile team?

You may or may not find this response useful. :-)

"It depends".

The "it depends" response is an old joke. I think I was advised by David Gelperin in the early 90s that if someone says "it depends" your response should be "ahh, you must be a consultant!"

But it does depend. It always has and will do. The context-driven guys provide a little more information - "it depends on context". But this doesn't answer the question of course – we still get asked by people who really do need an answer – i.e. project managers who need to plan and to resource teams.

As an aside, there’s an interesting discussion of "stupid questions" here. This question isn't stupid, but the blog post is interesting.

In what follows – let me assume you’ve been asked the question by a project manager.

The 'best' dev/tester ratio is possibly the most context-specific question in testing. What are the influences on the answer?

  • What is the capability/competence of the developers and testers respectively and absolutely?
  • What do dev and test WANT to do versus what you (as a manager) want them to do?
  • To what degree are the testers involved in early testing (they just system test? Or are involved from concept thru to acceptance etc.)
  • What is the risk-profile of the project?
  • Do stakeholders care if the system works or not?
  • What is the scale of the development?
  • What is the ratio of new/custom code versus reused (and trusted) code/infrastructure?
  • How trustworthy is the to-be-reused code anyway?
  • How testable will the delivered system be?
  • Do resources come in integer whole numbers or fractions?
  • And so on, and so on…

Even if you had the answers to these questions to six significant digits – you still aren’t much wiser because some other pieces of information are missing. These are possibly known to the project manager who is asking the question:

  • How much budget is available? (knowing this – he has an answer already)
  • Does the project manager trust your estimates and recommendations or does he want references to industry ‘standards’? i.e. he wants a crutch, not an answer.
  • Is the project manager competent and honest?

So we’re left with this awkward situation. Are you being asked the question to make the project manager feel better; to give him reassurance he has the right answer already? Does he know his budget is low and needs to articulate a case for justifying more? Does he think the budget is too high and wants a case for spending less?

Does he regard you as competent and trust what you say anyway? This final point could depend on his competence as much as yours! References to ‘higher authorities’ satisfy some people (if all they want is back-covering), but other folk want personal, direct, relevant experience and data.

I think a bit of von Neumann game theory may be required to analyse the situation!

Here’s a suggestion. Suppose the PM says he has 4 developers and needs to know how many testers are required. I’d suggest he has a choice:

  • 4 dev – 1 tester: onus is on the devs to do good testing, the tester will advise, cherry pick areas to test and focus on high impact problems. PM needs to micro manage the devs, and the tester is a free-agent.
  • 4 dev – 2 testers: testers partner with dev to ‘keep them honest’. Testers pair up to help with dev testing (whether TDD or not). Testers keep track of the coverage and focus on covering gaps and doing system-level testing. PM manages dev based on tester output.
  • 4 dev – 3 testers: testers accountable for testing. Testers shadow developers in all dev test activities. System testing is thorough. Testers set targets for achievement and provide evidence of it to PM. PM manages on the basis of test reports.
  • 4 dev – 4 testers: testers take ownership of all testing. But is this still Agile??? ;-)

Perhaps it’s worth asking the PM for dev and tester job specs and working out what proportion of their activities are actually dev and test? Don’t hire testers at all – just hire good developers (i.e. those who can test). If he has poor developers (who can’t/won’t test) then the ratio of testers goes up because someone has to do their job for them.

Comments

It depends - 4 testers, 4 devs, and ownership

Thanks for the Galperin reference (someone who replies "it depends" must be a consultant).
Saying "it depends" can lead into interesting discussions of trade-offs, conditions, etc., as you have indicated in your list of factors influencing the answer.
Your blog, though, assumes (unconditionially ;-)) that in determining the right ratio IN AN AGILE TEAM, of testers to developers:
- the number of testers will necessarily be less than or equal to the number of developers (where am I going with this? in TDD, is the worker a developer or a tester? Conceivably there are neither developers nor testers, just software artificers. And there may be less-exotic instances where # testers > # devs, especially when those testers have development skills)
- there is a PM involved (the PM you describe seems much more integrated with the Agile team than Agilistas I work with would be comfortable with)
- tester accountability and tester ownership are recognized only in the last two configurations, viz. 4 dev & 3 testers, and 4 dev & 4 testers). Is there no ownership for testers in the first 2 configurations?

TDD, testers and tools

I think it's less the tool than the balance of testing done by developers versus that done by the testers.

On the one hand, some developers create rather superficial tests and automate them. They may only demonstrate the story 'flows', leaving more detailed and end-to-end testing to the system tester.

On the other hand, the developer may create more detailed, test-driven tests, and add more tests to cover code and interesting scenarios as they write code and learn more about the intricacies of meeting that particular requirement. The tester is left with constructing what might be seen as rather superficial 'end-to-end' tests.

Clearly, the developers and testers need to agree where thay are on that range of possibilities.

Of course there are tools and tools and there's a dependecy on the tool as well.

It Depends

The other 'It Depends' is it depends on the Automation Tool you are using and how much you are going to automate. If it's a tool like Twist then this will involve significant help from the Developers, at least until the Testers are up to speed on enough Java knowledge to script themselves.

Do you want to fully automate the testing or use a story driven approach which covers most of the application?

Each choice affects the required tester to dev ratio.

At the end of the day it's an agile project so nothing is set in stone. Try things out, adapt and improve until you find the setup which works for you on your project.

It Depends

You are correct of course ! it does depend - however from experience in an Agile team working on "ECommerce" applications we have a 1 tester to 3 coders setup and that works very well, has done for the last 4 years.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
Sorry to be a pain - this question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.