Software testing outsourcing is priced one of four ways: a monthly dedicated team, a per-release or per-cycle fee, a fixed-scope engagement, or hourly time and materials. None of those numbers tells you whether the engagement is good value. The figure that does is cost per release shipped with a release decision you trust — and that includes automation maintenance, environment and test-data effort, and the triage hours your own engineers still spend.
This guide covers what each contract shape actually charges for, the scope variables that move a quote up or down, the line items that are quietly excluded, and a method for comparing proposals when no two vendors quote the same way. It deliberately avoids publishing vendor rate cards: they differ by market, seniority mix and commitment length, and a benchmark copied from a blog post is not a benchmark.
The four shapes a QA quote takes
Monthly dedicated team
You buy named engineers — a mix of manual testers, automation engineers and a lead — at a monthly rate per person, with a minimum team size and a notice period. This is the most common shape for continuous testing because it is predictable and keeps priorities with you. It is also the shape most often mis-sized: teams are staffed for the busiest release of the quarter and idled for the rest.
What to check: whether the rate includes a test lead, whether partial capacity (half an engineer) is even possible, and what happens to capacity when your team has nothing to test because the build is late. Good contracts allow a defined draw-down; bad ones bill the seat regardless.
Per release or per cycle
Priced against a defined release cadence — a regression cycle, a release candidate, a migration cutover. It suits teams that ship on a rhythm and want the cost to follow the work. The incentive is worth reading closely: if the vendor is paid per cycle, a release that slips a week is their revenue problem, which is healthy, but a vendor who is paid per cycle also has no reason to reduce the number of cycles you need.
What to check: the definition of a cycle, what counts as a re-test after a failed gate, and whether scope changes inside a cycle re-price it.
Fixed-scope project
A defined deliverable with a price: a test strategy, an automation framework built and handed over, a performance baseline, a compliance test pack. This is the cleanest shape for work with an end date, and the right starting point for most first engagements, because it produces an artifact you can judge.
What to check: the definition of done in testable terms — not 'framework delivered' but 'the suite runs from our CI pipeline, on our accounts, and a team member can add a test without vendor help'.
Hourly time and materials
Rates per role, hours against a purchase order. Flexible, transparent on paper, and the shape with the weakest cost discipline: effort expands to fill the budget, and you carry the coordination cost of approving timesheets. Use it for genuinely unpredictable work — exploratory testing on a new surface, an incident investigation — not for steady-state regression coverage.
| Shape | What you pay for | Fits when | The cost risk to price in |
|---|---|---|---|
| Monthly team | Capacity per engineer per month | Testing is continuous and scope is stable | Idle capacity; minimum team sizes |
| Per release | A defined cycle or release gate | You ship on a regular cadence | Cycle definition creep; re-test billing |
| Fixed scope | A deliverable with a definition of done | There is an artifact to hand over | Scope disputes at the boundary |
| Time and materials | Hours per role | Work is genuinely unpredictable | Effort expansion; approval overhead |
Most sensible engagements mix two: a fixed-scope assessment or framework build first, then a monthly team or a per-release arrangement once the scope is understood. A vendor who cannot describe which shape fits your situation is selling one product.
What actually drives the number
Seniority mix
The single largest variable. A pod of mid-level manual testers and a pod of automation engineers with performance testing experience are not comparable products, even when both are described as QA. Ask for the role mix in writing and check that the senior person is not a part-time name on the org chart.
Who owns the automation framework
If the vendor hosts the framework in their own tooling and runs it from their own environment, you are renting coverage and the price reflects a dependency they control. If the framework lives in your repository, runs on your CI and is maintained by engineers who document as they go, you are paying more upfront for something you keep. The second is usually cheaper by the second year, and it is the only version where you can leave.
Environments and test data
Testing needs a place to run and data to run against. Environment provisioning, data masking, synthetic data generation and keeping a staging environment alive are real costs, and in many engagements they land on the client because nobody priced them. A partner who has a method for environment and test-data setup will quote it; one who says 'we work with whatever you provide' has moved the work back to your engineers without saying so.
Regulated testing
Testing systems that carry PHI, PII or cardholder data adds access controls, evidence trails, environment segregation and staff background checks. That is not padding — it is work — and it should appear as a line you can see rather than being buried in a blended rate.
Time-zone overlap and on-call
Full overlap costs more than partial overlap. Pay for overlap where decisions are made — design reviews, triage, release go/no-go — and accept asynchronous coverage for execution. Out-of-hours release support is a separate cost and is almost never included by default.
Tooling and licences
Test management platforms, device farms, load-testing infrastructure and commercial automation tools are usually billed separately, at cost or with a markup. Cloud device farms in particular can exceed the labour cost of mobile testing if nobody caps the usage.
What is usually excluded
- Environment provisioning and maintenance
- Test data creation, masking and refresh
- Tooling and licence costs
- Out-of-hours or weekend release support
- Performance testing infrastructure
- Security testing, which is a different discipline and a different contract
- Re-testing after a scope change inside a fixed-price cycle
None of these is unreasonable to exclude. The problem is discovering them after the first invoice, when the comparison you made between two proposals turns out to have compared different scopes. Ask every vendor to list exclusions in the proposal, in the same format, so you can add them back before you decide.
Why the hourly rate is the wrong comparison
Two proposals at different rates can produce the same cost per release, and one at a lower rate can produce a higher one. The rate only means something once it is divided by output you care about:
Cost per release = (team or cycle cost + tooling + environment and data effort + your triage hours + automation maintenance) ÷ releases that passed a gate you trusted.
The last two terms are where quotes diverge most. A cheap team that generates defect reports your engineers must reproduce and re-triage has moved cost, not removed it. An automation suite with a high maintenance burden shows up as engineers pulled off feature work every sprint. Put a number on both, even roughly, before you compare rates.
How to build your own benchmark
You do not need a market benchmark to make a good decision; you need your own baseline. Four figures are enough:
- Releases per quarter and how many of them required a hotfix in the first week.
- Escaped defects per release, with severity — the defects customers found that your process should have caught.
- Engineering hours spent on quality work that is not feature work: triage, reproduction, environment fixes, flaky test maintenance.
- Time from code complete to a release decision you were confident in.
With those, a proposal can be expressed in the same units: what it costs per release, what it is expected to change in escaped defects, and how many of your engineering hours it returns. Our guide to QA testing ROI works through how to fund that case internally, and the enterprise IT pricing benchmarks piece covers the same normalisation method for services beyond QA.
How to compare two proposals
Put both through the same five columns before you talk about price:
- Scope, in artifacts. What exists at the end of month one — a strategy document, a framework in your repo, a release gate with agreed criteria — or only a team.
- Role mix and named people. Who does the work, at what seniority, and whether the person who presented is the person who delivers.
- Cost per release at your actual cadence, including exclusions added back and your own triage hours at a realistic hourly cost.
- Automation ownership and maintenance share. Where the code lives, who runs it, and what proportion of effort goes to keeping it green.
- Exit terms. Notice period, knowledge transfer obligation, and whether the suite keeps working after they leave.
The software testing partner selection guide goes deeper on the evaluation criteria and the questions that produce unrehearsed answers. If you want the worked version on a real engagement, the fintech release-cycle case study shows what a gated release process changed in practice.
Contract terms that change the economics
- Ramp and draw-down. A defined ramp period priced below steady state, and the right to reduce capacity with agreed notice, both protect you against a slow first quarter.
- Minimum commitment versus minimum spend. A minimum number of engineers is a staffing guarantee; a minimum spend is a budget guarantee. They behave very differently when the roadmap changes.
- Change control. How a scope change inside a fixed price is priced, and who approves it. Vague change control is where fixed-price engagements quietly become expensive.
- Knowledge transfer. An explicit handover obligation — documentation, pairing sessions, a working handover — priced into the engagement rather than offered as goodwill.
- Metrics in the contract. Escaped defects, gate pass rate and suite stability are measurable. Writing them into the agreement is the difference between a report and an accountability.
Pricing red flags
- Billing per test case executed. It rewards volume over judgement, and the volume is decided by the vendor.
- Unlimited testing for a flat fee. Either the scope is narrow enough to be honest, or the definition of testing is thin. Ask what is excluded; the answer is usually the work you actually needed.
- Automation in the vendor's environment only. You are buying a subscription to their capability with no exit.
- No sample reports. A vendor who will not show a redacted report from a previous client is telling you something about their reporting.
- A blended rate that hides the role mix. Seniority is the biggest cost driver; a single number removes your ability to judge it.
Questions worth asking before you sign
What does software testing outsourcing cost?
There is no public rate card, and any single figure quoted without knowing your release cadence, stack, compliance obligations and current quality baseline is a guess. What you can do is force the comparison onto a common unit: cost per release, with exclusions added back and your own triage hours included. Prices differ substantially between markets, seniority mixes and contract lengths, so the only benchmark that means anything is one built from your own release history.
Is outsourcing QA cheaper than hiring in-house?
Sometimes, but the honest comparison is capability and elasticity rather than headcount cost. Outsourcing tends to win when the need is specialist, uneven across the year, or tied to a defined surface, because you can scale the depth without permanent headcount. In-house tends to win when quality decisions are inseparable from architecture and product decisions, or when you need the same people working continuously on the same system. Many teams run a hybrid: in-house ownership of strategy and the automation framework, with a partner supplying execution depth and specialist coverage.
What should a first engagement look like?
One surface, one strategy document, one release gate you can actually enforce. Fixed scope, four to eight weeks, with a defined artifact at the end. It gives you a real sample of how the partner thinks, a framework you own, and a defensible basis for deciding whether to scale — without committing to a team before you have seen them work.
How quickly can quality metrics improve?
The first measurable change is usually in time to a release decision, because triage and reporting discipline change in weeks rather than quarters. Escaped-defect rates move more slowly, because they depend on coverage of the paths that actually break and on fixes reaching production. Treat any promise of a specific improvement by a specific date without a baseline as marketing rather than a plan.
If you are comparing quotes now, the useful next step is not another rate card — it is putting your own numbers against each proposal. Our QA and testing practice scopes fixed-price assessments that produce the strategy, the framework and the baseline in one engagement, and we will tell you plainly whether outsourcing is the right model before you commit to one.