Naturally, the answer is "it depends". Here are some factors to consider:
- Are the developers doing a good job of TDD? Does the team use acceptance tests to drive development, also?
- How good is the automated regression test coverage?
- How good is the communication between developers and customers?
- Is the application testing-intensive, or does testing go pretty fast compared to coding?
- Do the developers help with testing activities such as automating acceptance tests?
I worked on another team of 20 more more developers (subdivided into smaller teams but all working on one project) where I was the only official tester. While the team did a good job of TDD, and we had good communication with customers despite the fact that we were a distributed team, this was clearly not enough. Fortunately, we were developing a non-critical internal application that would be used by a few expert users, so it wasn't the end of the world if the functionality wasn't perfect. One or two developers or business analysts wore a tester "hat" each iteration and performed testing activities. I worked hard to transfer my testing knowledge to everyone on the team, so that our unit tests covered more test cases, and we could automate at least some of the functional regression tests.
My third successful agile team consisted of 8 programmers and me, the tester. At first, the programmers could not get a handle on TDD or even unit test automation after coding, and I was buried. I asked our coach for help. He helped us figure out how to get traction on unit testing, by providing training and time to learn. Once the team mastered TDD, and pitched in on functional test automation, I was able to handle the other testing activities and we all worked well together.
Those are my stories on tester-developer ratio. Got any of your own to share? Please comment.