Tester to developer ratio: sizing a vendor team

Why no universal ratio exists

People search for a tester to developer ratio because they want a quick check on a vendor's proposal. The difficulty is that the ratio is an output, not an input. It is what you get after you account for how your product is built, released and used. Two teams with the same number of developers can need very different testing effort.

The UK government service manual on quality assurance describes testing as something the whole team does, with automated tests written alongside the code and run continuously. In a team that works that way, much of the checking is done by developers and pipelines, and dedicated testers focus on exploratory testing, risk and coverage gaps. In a team where developers write few tests and releases are manual, the same product may need far more dedicated testing. The research published by the DORA program also treats test automation as a capability of the whole delivery team, not of a separate function.

So a ratio quoted without context tells you little. It may come from a different kind of product, a different release pattern or a different split of work between developers and testers.

What drives the right team size

These factors move the number. Write down where you stand on each before you ask vendors to size a team.

Driver	Pushes testing effort up	Pushes testing effort down
Product risk	Payments, health, safety, regulated data	Internal tools, low-impact features
Release frequency	Frequent releases with manual regression	Infrequent releases, or automated regression in CI
Developer testing	Few unit or integration tests	Strong unit and integration coverage
Automation maturity	No suite, or a flaky one	Stable suite that runs in the pipeline
Platform coverage	Many browsers, devices, OS versions, locales	One platform
Integration surface	Many third-party systems and APIs	Few external dependencies
Non-functional scope	Performance, accessibility, security in scope	Functional only
Change rate	Large or frequent changes to existing flows	Mostly stable product
Documentation needs	Formal test evidence for audit	Lightweight reporting

A vendor who has understood your product should be able to explain its proposed team size using these drivers.

How to challenge a proposal's headcount

Put the question to each vendor in the same form: "How did you arrive at this team size? Please show the calculation from our scope." A useful answer looks something like this:

• Stories reaching test per sprint, and estimated test design and execution time per story.
• Regression scope per release, split into automated and manual, with time for each.
• Platform matrix and the extra effort per additional platform.
• Time for automation maintenance, test data, environment issues and reporting.
• A lead's time for planning, triage and communication.
• Assumptions, stated plainly, with what would change if each were wrong.

A weak answer names a ratio, cites "experience", or gives the same team size to every client. If two vendors give very different sizes for the same scope, compare their assumptions. Usually one has missed something or priced in something you do not need.

Also look past the headcount at seniority. A larger team of junior testers can cost more and deliver less than a smaller team with an experienced lead. The guide on how QA vendors staff projects covers what to ask about seniority and continuity.

What to measure instead

Once the team is working, measure whether it keeps up with delivery. These measures tell you more than any ratio.

• Testing turnaround. How long a story waits between "ready for test" and "tested". A growing queue suggests the team is too small or blocked.
• Regression cycle time. How long a full regression takes before a release, and whether it delays releases.
• Escaped defects. Defects found in production that were in scope for testing. See defect leakage as a vendor metric for how to count them fairly.
• Coverage of agreed risks. Whether the highest risks in the test strategy were tested each release.
• Idle or low-value time. Whether testers spend time on work you would not pay for if you saw it listed.

Review these at the end of the first quarter and agree whether to change team size. Build the right to scale up or down, with notice periods, into the contract.

Using the tools

State your drivers in the RFP so every vendor sizes the team against the same facts. The RFP builder has a section for release frequency, platforms and current test coverage. Then enter each vendor's proposed team and rates into the cost tool to see total cost under your own assumptions. The KPIs for a QA vendor guide lists further measures for ongoing review, and the selection path shows where sizing fits in the timeline.