What does a tester-to-developer ratio tell you about a team, and what does it hide?
answer
- It is an output, not an input
- Same number, two very different teams
- Depends on the ownership model chosen
- Ask what only a tester can do
- A target that destroys its own meaning
basics
~20 sA tester-to-developer ratio describes how testing labour is staffed, not how quality is produced. The same ratio fits a fast embedded team and a badly queued separate group, so read it as a symptom that needs explaining, never as a target to hit.
solid answer
~50 sThe ratio is an output of the ownership model, not an input to it. An independent group verifying finished work needs far more testers per developer than a team where engineers own their own checks, so a number quoted without the model attached means nothing. Published figures range from roughly one tester per three developers in high-assurance work to one per twenty or more where developers own most verification — and there is no industry-wide correct value. What the ratio hides is everything that matters: how long feedback takes, whether the tester works before implementation or only after, who fixes a failing check, and what portion of the tester's day is work only they can do. Staff to a ratio and you get the classic Goodhart outcome: enough testers to keep a queue moving, and a team that has stopped testing because someone else is paid to.
go deeper
Be ready to say that the number of testers per developer varies enormously between organisations and that no standard value exists. Knowing who on your own team writes and fixes the automated checks is the concrete part you can speak to.
Explain what the ratio depends on — the ownership model, risk level, how much verification developers already own, and the product's surface — and name at least two things it cannot see, such as feedback latency and when the tester engages.
Demonstrate that you would answer a staffing question with a diagnosis: where the current interval from change to feedback is spent, and how much of a tester's week is work only a tester can do. Show what you would measure afterwards.
Own the Goodhart argument. Be ready to explain why a company-wide ratio target entrenches whichever model produced today's queue, and what you would put in front of leadership instead when they ask for one number.
## Why the question gets asked "What ratio of testers to developers should we have?" is one of the most common questions a hiring manager puts to a candidate who will influence staffing, and the strong answer refuses the premise politely before offering something better. The ratio is a **derived quantity**. It falls out of the ownership model, the risk profile of the product and how much verification developers already own. Treating it as an independent lever gets the causality backwards. ## What the number actually depends on **The ownership model.** If an independent group verifies finished work, testers must absorb the full verification load of everything the organisation produces, and the ratio has to be generous or a queue forms. If engineers own unit and integration level checks and a tester's job is exploration, risk analysis and the cases nobody thought of, the same product needs far fewer testers. Moving a tester into a team does not change how much testing is needed — it changes who does which part. **Risk and consequence.** Software where a defect costs a life, a licence or a large sum carries more verification per unit of code than software where a defect costs an apology. Regulated products additionally carry evidence work — producing and retaining proof that verification happened — which is real effort that has nothing to do with finding defects. **What is automated and who maintains it.** A large automated suite reduces repeated manual verification but adds maintenance. If testers maintain it, they are absorbing developer-shaped work and the ratio inflates for a reason unrelated to testing skill. **Product surface and change rate.** A wide surface with many configurations and integrations demands more verification per developer than a narrow one, and a team shipping several times a day needs a fundamentally different arrangement from one shipping quarterly. ## The numbers people quote Published ratios span roughly one tester per three developers in high-assurance and heavily manual environments to one per twenty or more in organisations where developers own most verification, with some well-known companies operating with no dedicated testers at all. These figures circulate as folklore, are rarely defined consistently (do you count part-time testers, automation engineers, the people who maintain environments?), and are not evidence of anything transferable. Quote them, if at all, as a range that demonstrates how model-dependent the answer is — never as a benchmark to hit. ## What the ratio hides The ratio is silent on every variable that predicts whether quality work is effective: - **Handoff latency.** How long between a change existing and someone competent judging it. Two teams with identical ratios can sit hours or weeks apart on this. - **When the tester engages.** Before implementation, shaping cases and challenging a requirement, or only afterwards on finished work. The first prevents defects; the second finds them late. - **Who fixes a failing check.** If the answer is always the tester, developers have outsourced their feedback loop and the ratio will keep climbing. - **What only the tester can do.** Deep exploration, adversarial reasoning, data design, understanding real usage. If most of the tester's day is environment babysitting and re-running known cases, the role is being spent on work that should be automated or owned elsewhere. - **Skill depth.** Two testers who shape requirements are worth more than six who execute scripted steps, and the ratio cannot see the difference. ## The Goodhart trap Once a ratio becomes a target, it stops measuring anything. Staff to a fixed ratio and two predictable things happen. First, testers are hired to keep the existing queue moving, which entrenches whichever model produced the queue. Second, developers reasonably conclude that testing is somebody's job and quietly stop doing theirs, which raises the required ratio again. The ratio then rises steadily while escaped defects do not fall, and the organisation concludes it needs more testers. ## What to propose instead Ask what the current arrangement costs and where. Useful replacement questions: how long is it between a change being written and someone finding a defect in it; what proportion of defects are found by the people who wrote the code; how much of a tester's week goes on work only a tester can do; and what would break tomorrow if one tester left. Those questions lead to a staffing conclusion — sometimes "hire testers", often "change who owns what" — that a ratio alone can never justify. If asked to give a number anyway, give a range, attach the model it assumes, and say what you would measure after three months to find out whether it was right.
- A director asks you for a single target ratio for the whole company. What do you say?That one number across teams with different models, risk levels and release rates will be wrong everywhere at once. I would offer a range per model, state what each assumes about who owns which checks, and propose measuring the interval from change to feedback and the share of a tester's week spent on work only a tester can do. Then revisit staffing with evidence rather than a company-wide constant.
- The ratio is stable but escaped defects are rising. What does that suggest?That the constraint is not headcount. Common causes are testers engaging only after implementation, verification happening too far from the change, a growing product surface without a change in approach, or developers having quietly stopped testing because a dedicated role exists. Adding testers to any of those raises cost without moving the outcome, so diagnose which one it is before staffing.
saying these in an interview costs you the question
- Quotes an industry-standard ratio as if it were settled
- Treats the ratio as a lever rather than a result
- Ignores who owns automated checks when counting
- Assumes more testers always means fewer escaped defects
- Compares ratios across teams with different ownership models