The ratio myth

Recently I've been hearing a lot about the developer to tester ratio for agile teams. This is usually evangelised as an ideal of 4:1; four developers to one tester.

Having worked in many different agile teams, this ratio doesn't align with my experience. Here are a few examples of successful teams I have worked in with structures outside the norm.

More Developers [6:1]

In one of my earliest roles within agile development, I worked as the sole tester in a team with six developers. We were tasked with developing a system from scratch that would replace a legacy application.

The business had a clear vision, were engaged in what the team were doing, and sought to provide timely feedback on early versions of new features. Their involvement bought the users' expectations to any new features as soon as practical.

The developers had a lot of infrastructure oriented work to do, as they were setting up an entirely new application stack. In addition to technical stories, the team always carried at least one with a customer focus, to provide continuous delivery of business value. Features were small and well-defined from a business perspective, but usually involved the interaction of multiple systems behind-the-scenes, which meant they took time to develop.

As a tester, my primary focus was developing and maintaining a tidy suite of automated regression checks. The testing I did was either quick and sympathetic, so that simple issues were discovered and resolved before early engagement of the business, or aggressively sought out interesting problems.

In this team I often felt bored. Though I had six developers, it took a lot of programming to produce small pieces of front-end function. Fast feedback from the business reduced the amount of testing I had to do. I didn't feel challenged.

Less Developers [2:1]

In a different organisation, I worked in a team tasked with re-designing an existing purchasing workflow in an online marketplace. The team included two designers, two developers and myself as the sole tester.

In this team, the pace of development was determined by the rate at which the designers could agree on the updated user interface and workflow. Programming changes were to reflect paper prototypes; updating stylesheets, JavaScript and links between pages.

Though development was relatively simplistic, the testing required was significant. The existing workflow included a number of different business rules, which were recorded in varying detail across multiple documents. There were a vast number of variables to consider in purchasing an item, both obvious variables and those that were indirectly accessible. There was no automated checking available in this domain.

In this team I was busy. Due to the financial impact of failure in this workflow, testing had to be comprehensive and meticulous. Proportionally, much more time was spent in testing, so the output of two developers was enough to keep me occupied.

More Testers [4:2]

Finally, in a third organisation, I worked in a team asked to fix a production issue in a complex shared web service. This team included four developers from four specialist areas; mainframe, database, integration and front-end. I was one of two testers.

In this environment, the complexity of development varied dependent on the system. Most changes were isolated to a specific aspect of functionality, which could only be observed when users followed a specific workflow.

From a test perspective there was a lot of work to do. As in the previous team, the code change was in an important area of the application with complex business rules. Unlike the previous team, there were automated regression checks available at multiple layers of the architecture.

In this team I was challenged. Testing had to occur on each piece of development in isolation, then via multiple front-end consumers of the web service. In addition, due to their specialist focus, a large component of testing in this team was to facilitate communication among developers. With a tight deadline, and proportionally more testing than development, we needed two testers to get through everything.

*****

There are a lot of variables in determining the best ratio of developers to testers in an agile team. A ratio of 4:1 may be a good place to start, but inflexibility in resourcing is folly. There is no hard and fast rule.

If you encounter a scrum master that attempts to enforce a ratio at the expense of common sense, perhaps you can remind them of the first principle of the agile manifesto. Individuals and interactions over processes and tools. A ratio is just a tool, so be sure to listen to your people if they tell you it's not working.