Matthew Steer posted a simple yet intriguing question over at the LinkedIn Agile Testing group:
What sort of developer / tester ratios are people using in their scrum teams?
My reply was that, at some level, it also depends on the skills that the team collectively has. If “devs” are willing and able* to do activities that QA leads and testers generally have skills in, more power to them. In my experience, however, devs are more naturally drawn to other activities, and QA leads/testers should have more advanced skills in customer-level testing and exploratory testing, which many devs mistakenly view as merely ad-hoc testing. Only about half of our teams have QA leads/testers, and I think they’re poorer for it. On an agile team that takes a high view of the “whole team” approach, though, a ratio of anywhere between 4:1 and 8:1 is reasonable, in my opinion.
*Although many developers have skills in the things I mentioned are generally the province of QA leads (customer testing, exploratory testing), I’ve found that they either don’t want to do those activities or do them with a particular blind spot. That blind spot is perhaps through no fault of their own, as it is borne of their unique vantage point as developers. As the team members most responsible for writing the code that literally makes the software for a customer, they tend to view the product from that perspective. It’s a rare developer who can shift so far away from that perspective to see things as a customer might. That doesn’t mean developers can’t understand requirements or the big picture, or even correctly anticipate the details that a customer will want; merely that having a customer mindset, or a total quality view of a project, is more natural for someone not as engrossed in the production-code development. That’s where, even in high-functioning agile teams, a QA lead or tester is indispensable. The skills may — and ideally do — overlap a lot, but the mindset doesn’t nearly as much.