QA outsourcing pricing models and their incentives

The four models

Testing vendors price their work in a small number of ways. The names vary, but the mechanics are the same.

Model	You pay for	Vendor is rewarded for	Risk sits mainly with
Hourly time and materials	Hours worked	More hours	You
Monthly per tester (dedicated team)	Headcount per month	Keeping headcount	You, with some predictability
Fixed price per release or project	A defined deliverable	Finishing with less effort	Vendor, until scope changes
Outcome-based	Measured results, often plus a base fee	Hitting the measure	Shared, depending on the measure

None of these is right in general. The UK Sourcing Playbook asks buyers to choose a delivery and pricing model that fits how well the requirement is understood and how much it is likely to change. The same logic applies to testing.

Hourly time and materials

You pay for the hours the vendor works, at agreed rates by role.

When it fits. Scope is unclear or changing fast, you want to start quickly, or you are still learning what you need.

What it rewards. Hours. Nothing in the model rewards finishing sooner or finding the important defects rather than many small ones.

What to add. Timesheets by person and activity, approval of hours by someone on your side, a cap per period that needs your sign-off to exceed, and rate lock for the initial term. Read fixed price vs time and materials for more detail.

Monthly fee per tester

You pay a fixed monthly amount for each named person on a dedicated team.

When it fits. Ongoing work alongside your developers, where you want the same people every sprint.

What it rewards. Keeping the team the same size. It does not reward efficiency, and it can hide weak output behind full attendance.

What to add. Named individuals with key personnel terms, notice and approval for replacements, a clear process to scale down, and a few measurable service levels so you can tell good months from poor ones. The SLA metrics guide lists measures that suit testing.

Fixed price per release or project

You pay an agreed amount for a defined piece of work: a regression cycle for a release, a test strategy, an automation build for a set of journeys.

When it fits. The deliverable can be written down clearly, with acceptance criteria, and your scope is stable for the duration.

What it rewards. Delivering the defined scope with as little effort as possible. That can be good (efficiency) or bad (thin testing that meets the letter of the scope).

What to add. Written scope, written assumptions, acceptance criteria for each deliverable, a change control process with agreed rates, and payment tied to acceptance. If scope is defined too narrowly, every question becomes a change request.

Outcome-based pricing

Part of the fee depends on measured results, such as regression runs completed on time, critical defects triaged within a time limit, or escaped defects below an agreed level.

US federal guidance on performance-based acquisition (FAR Subpart 37.6) describes the idea: state the required results, how they will be measured and, where appropriate, the incentives tied to them, rather than prescribing how the work is done. The TechFAR Hub applies the same thinking to digital services.

When it fits. You can define and measure the outcome fairly, the vendor controls enough of what drives it, and you have baseline data.

What it rewards. Hitting the measure. If the measure is poorly chosen, the vendor will still hit it. Counting defects logged, for example, rewards volume, not risk reduction.

What to add. Written metric definitions, the data source, the measurement period, who reports it, and what happens when a target is missed. See defect leakage as a vendor metric for one measure that needs careful definition.

How to choose

Ask three questions.

1. How stable is our scope? If it will change often, fixed price will generate change requests. Start with time-based pricing and move to fixed or outcome-based parts once scope settles.
2. Can we measure the outcome we care about? If not yet, do not tie money to it. Collect the data for a quarter first.
3. Who controls the drivers? A vendor cannot be paid on release quality if you control the code, environments and go-live decision. Tie outcomes to things the vendor controls, such as turnaround and coverage of agreed risks.

Comparing quotes across models

Vendors will sometimes quote in different models to make comparison harder. Ask all of them to quote in the same model, or ask for a price build-up (roles, rates, volumes, overhead, tooling) so you can convert each quote yourself. Enter the quotes in the cost tool and compare total cost over the term. Then draft the matching terms in the contract clause builder, including rate lock, change control and service credits. The selection path shows when to settle the pricing model so it does not hold up the contract.