Wednesday, December 17, 2008

Tester-Developer Ratios on Agile Teams

A question that came up yesterday on the Agile Testing Realities discussion, and that comes up a lot everywhere, is "What is the ideal tester-developer ratio on agile teams"?

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?
My current team works with a financial services web app that is quite testing-intensive. The functionality is complex, and since we are dealing with peoples' money, we have to get it right. For some stories, testing takes more time than coding. Our programmers are quite experienced in TDD and our regression test coverage is excellent. While our developers and customers sit close to one another and communicate well, and the developers have a high degree of domain knowledge, our stories are often quite complex. A lot of tester time is devoted to working with customers to get examples of desired behavior and sort out technical challenges and other questions. The developers take on a lot of testing tasks, including automating FitNesse tests and often writing the FitNesse test cases themselves. We have five programmers and two testers, and even so, the developers often have to pitch in extra on testing.

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.


Mykhailo Poliarush said...

Good stories!

I can't believe that you were one official tester on second project.
Do you really have time to fulfil your job?

Lisa said...

Mykallo, I confess I was very stretched on that project. The biggest problem was that I had to coordinate post-development system testing with the client's own QA department and other teams. While I did that, the team started out on a new release. Having one or two other people wear a tester hat each iteration worked well enough, though. Usually one analyst and one developer assumed the tester role in addition to me.