Friday afternoon. As the tech lead, you get three outsourced testing quotes from procurement for a product that is growing faster than your team. The first: €10 per executed test case, with an estimated 2,000 cases a month. The second: one manual tester and two automation engineers on time and materials, with day rates in a table. The third: a “managed QA team” for a fixed monthly fee, with no breakdown by person. Procurement wants to know one thing: which is cheapest?
You cannot answer that by comparing the numbers in the quotes. The first comes to €20,000 a month, but only if there really are 2,000 cases, and nobody knows how many there will be once scenarios are split into smaller ones. The second depends on how many days people actually work and whether someone on your side manages them. The third is predictable, but it is not clear what exactly you are buying.
This article breaks the cost of outsourced testing into its parts. We do not repeat the rate table, because QA outsourcing rates: what to expect in Poland and CEE 2026 covers that in detail. We look at what happens to the rate after the contract is signed: how the three main pricing models work, what each actually costs, where the traps are that you pay for without knowing, and what to write into the contract.
What does the cost of outsourced testing actually consist of?
The cost of outsourced testing has five components, and the rate is only one of them. If you compare quotes on rate, you are comparing a fifth of the bill.
The first component is delivery work: the day or hourly rate multiplied by people and days. It is the only line you see directly in a quote. In ARDURA’s pricing, manual testers start from €130 per day, and a QA engineer (test automation, SDET) costs €165–240 at junior level, €335–465 at senior level and €465–595 at architect or lead level, for an 8-hour day, net. Add VAT where it applies; for B2B services from another EU member state, the reverse charge mechanism usually applies.
The second component is onboarding and product knowledge. A new person needs time to learn the domain, environments, test data and how the team works. During that time you pay the full rate for partial output, and your own people spend time explaining. This cost is unavoidable; you can only reduce it with good documentation and a stable team.
The third component is management. Someone has to set test priorities, review defect reports and decide what is good enough to release. In time and materials this is usually someone on your side; in a managed team the vendor takes on part of this work and prices it in. Either way, the cost exists.
The fourth component is tools and environments: test management licences, device farms, CI infrastructure for automated tests, test environments. Some vendors include them in the rate, some invoice them separately, and some assume you will provide them.
The fifth component is maintaining what was built. Automated tests must be updated with every change to the interface and logic. Test cases go stale. If the budget covers building automation but not maintaining it, you will pay a second time six months later. For the cost of automation itself, see How much does test automation cost in 2026?.
Only the sum of these five lines over the period you plan to work together lets you compare quotes. Most of the difference between quotes is not in the rate but in which of the other four components the vendor has taken on and which it has left with you.
How does time and materials work in testing, and when does it pay off?
Under time and materials (T&M) you pay for the working time of specific specialists at an agreed rate, usually daily, invoiced monthly for days worked. The specialists work in your team, to your priorities and in your tools. This is essentially software tester rental, or staff augmentation for QA roles.
The advantage of T&M is flexibility. The test scope changes every sprint, and you do not have to renegotiate the contract for each change. You can add a person before a big release and scale down after it. At ARDURA, staff augmentation has a one-month minimum, new specialists can be added with two weeks’ notice and the team can be reduced with 30 days’ notice, with no recruitment fees and no penalties for scaling, under the terms on the pricing page.
The disadvantage of T&M is that the whole effectiveness risk stays with you. The vendor is responsible for providing a competent person, not for how many defects they find or whether the release is stable. If nobody on your side sets priorities, a T&M tester will diligently do what they are pointed at, which is not necessarily what matters most.
T&M pays off when you have someone on the team who can manage quality: a tech lead or QA lead who sets the test strategy while external specialists execute it. It also pays off with a changing scope, for early-stage products and when you want to build QA capability inside your organisation with external people filling gaps. With T&M, check three things: whether you pay for days worked rather than calendar days, whether the specialist’s holidays and sick days are excluded from the invoice, and what the terms are for replacing someone who does not work out.
Those replacement terms vary widely, so compare them in writing. At ARDURA, every engagement starts with a two-week satisfaction guarantee: if the specialist does not meet expectations in the first two weeks, they are replaced at no cost, and if a specialist leaves during the engagement, a replacement is provided within 5 business days.
How does a dedicated or managed testing team work?
In the team model the vendor provides not individuals but a team with a defined composition and responsibility, usually billed at a fixed monthly rate. The vendor handles recruitment, cover and work organisation, and often the test process as well. In ARDURA’s pricing, a dedicated team is billed at a discounted monthly team rate, with a recommended minimum of three months and three specialists.
The advantage of this model is predictability and continuity. You know the monthly cost, you do not manage each person individually, and the vendor is responsible for keeping the team running through holidays and turnover. For a long-lived, stable product it is often the cheapest model over a year, because product knowledge stays in the team and you pay the onboarding cost once.
The disadvantage is the risk of buying execution while believing you bought quality assurance. A vendor-managed team can execute test cases very efficiently and still have neither the authority nor the information to say whether a release is ready. We cover this in detail in Who defines quality when you outsource QA: if the definition of quality stays with you and execution sits with the vendor, you pay for clicks rather than accountability.
The team model pays off when the product is developed long-term, you need several roles at once (manual testing, automation, performance) and nobody on your team wants or is able to manage testers day to day. Before signing, ask for the composition with roles and seniority levels, how the price changes when the composition changes, which outcome measures will be used (more on those below) and who on the vendor’s side is accountable for quality, not just for staffing.
When do fixed scope and fixed price make sense in testing?
A fixed price for a defined scope is a model where the vendor takes responsibility for a result within an agreed budget. In testing it works well for one-off work with a clear start, end and deliverable: building an automation framework, a QA process audit, setting up a test strategy and test management tool, pre-launch performance testing, a regression test before a migration.
One example is the QA strategy and test management package in ARDURA’s offer: a risk-based test strategy plus a working TestRail, Xray or Zephyr setup, with existing test cases migrated and Jira and CI integrated, in two weeks, from €3,700. The scope is closed, so the price can be fixed upfront.
Fixed price does not work as a model for continuous testing of a product under development. The test scope changes every sprint, so the vendor must either price the risk with a large buffer or defend against every change with a change request. Either way you pay more than under T&M. The typical symptom: a “fixed price per release” quote with a long list of exclusions, followed by a series of change orders for every new screen.
The legal framing matters in some markets. Under German law, for example, there is a meaningful difference between a service contract (Dienstvertrag, § 611 BGB), where the provider owes diligent work, and a contract for work (Werkvertrag, § 631 BGB), where the provider owes a result. Continuous T&M testing is by nature a service; a closed package with a defined deliverable is closer to a contract for work. In Germany it is also worth taking legal advice on how external testers are directed day to day, because close integration into your team can raise questions under the rules on temporary agency work (AÜG). The name of the contract matters less than its content, but what the vendor is responsible for should follow explicitly from the clauses, not from assumptions.
What does each model really cost in an example scenario?
Let us run one example to show how much the model changes the bill. Assume a web product with a mobile app, releases every two weeks, and a need for one manual tester and two automation engineers for 12 months. The figures below are our illustrative estimate based on ARDURA’s published rates, not a quote; we assume about 20 billable days a month.
T&M. Two senior automation engineers at about €400 a day and a mid-level manual tester at about €210 a day come to roughly €20,200 a month, or about €242,000 a year. On top of that comes your QA lead’s management time (if you have one) and tools on your side. If releases pause for a month, you can reduce the team with 30 days’ notice.
Dedicated team. The same composition in the team model has a discounted monthly team rate and part of the management on the vendor’s side. The discount and the management scope are agreed individually, so we do not give a figure; when comparing, subtract the discount from T&M and add the management cost that moves to the vendor. If your QA lead will manage the team anyway, you pay for management twice.
Per test case. At €10 per case and 2,000 cases a month you get €20,000 a month, comparable with T&M. Except the number of cases is not fixed. If the vendor splits each scenario into three smaller cases, the bill triples with no change in risk coverage. If in a month with a big release you need exploratory testing, which cannot be counted as cases, it does not exist in the model at all.
Fixed scope. For continuous testing of this product, a fixed-price quote would have to price 12 months of scope uncertainty. In practice that means a risk buffer and a change procedure. Fixed scope does make sense for one-off elements: building the automation framework at the start, setting up the test strategy, pre-launch performance testing.
The lesson: at a similar monthly amount, the models differ in who carries the risk of scope change and whether you pay for outcomes or activity. The cheapest model on paper is often the one that shifts risk to you in a way the quote does not show.
What is paying for clicks, and how do you spot it?
Paying for clicks is when you pay a vendor for testing activity (executed cases, hours of manual clicking, number of reported defects) rather than for the quality information you need to make a decision. Activity is easy to measure and invoice; information is harder, which is exactly why so many contracts bill the former.
The most common forms of paying for clicks look like this.
Billing per executed test case. It rewards the number of cases, not their value. The vendor has an incentive to split scenarios, to repeat the same regression tests by hand instead of automating them, and to avoid exploratory testing. A rising case count in the report does not mean the tests cover more risk.
Billing per reported defect. It looks like outcome-based pricing but rewards the number of reports. The vendor has an incentive to report trivia, duplicates and cosmetic issues, and less of one to chase a single serious problem that is hard to reproduce. Your team spends its time on triage instead of fixes.
Manual regression without an automation plan. A T&M tester who clicks through the same 300 cases every two weeks is a cost that grows linearly with each release. Automation does not always pay off, but having no decision about what to automate always means paying for clicks.
An SLA on the number of test cases. A contract in which the vendor commits to executing X cases per cycle measures exactly what you do not want to buy. A met SLA says nothing about whether the release is safe.
How do you spot it in your own engagement? Ask three questions. Does the test report say whether the release is ready, or only how many cases were run? Is the number of manually executed regression tests shrinking over time or growing? Do customers find serious defects in production even though test reports are green? If the answers are “only numbers”, “growing” and “yes”, you are paying for clicks.
Which outcome measures should replace test case counts?
If case counts measure activity, you need measures that describe outcomes. No measure is perfect, and any of them can be gamed in bad faith, so use several at once and look at trends rather than single values.
Escaped defects, weighted by severity. This is the most direct signal of whether testing catches what it should. It requires agreeing what counts as a defect and what is a requirements change.
Risk coverage, not case coverage: the share of high business-risk areas covered by automated tests or planned manual tests. It requires a risk list that you create and the vendor maintains. That is part of a test strategy, without which no measure has a reference point.
Time from change to feedback: how long it takes from merging a change to the regression result. Well-built automation cuts this from days to hours and directly speeds up releases.
Automated test stability: the share of flaky tests that pass and fail without a code change. A high share means the team stops trusting tests and every red light gets ignored.
Share of regression tests run automatically, and its trend. The goal is not 100%, but making sure manual effort goes where it adds value: exploratory testing, usability and new features.
Here is what that looks like in practice. Instead of “the vendor will execute 1,500 test cases per release cycle”, the contract says the parties review each quarter the number of critical production defects, the share of high-risk areas under automation and regression duration, and the vendor presents a plan to improve them in the next quarter. Such a clause guarantees nothing, but it moves the conversation from “how much did you do” to “what got better”.
Write the measures into the contract as the subject of a regular review, say quarterly, rather than as a payment condition, at least at first. Measures tied to payment attract gaming; measures reviewed together build a conversation about quality. After a few quarters, once you know the baselines, you can consider linking part of the fee to the trend.
Which hidden costs most often push the bill up?
Beyond paying for clicks, several items rarely appear in a quote but regularly appear in the budget.
Turnover and re-onboarding. Every change of person means several weeks of partial output and your team’s time spent explaining. Ask the vendor about specialist retention and who pays for a replacement’s ramp-up. ARDURA publishes a 99% specialist retention rate on its pricing page; whichever vendor you use, ask for this figure and how it is calculated.
Knowledge locked in at the vendor. Test cases in the vendor’s tool, automation scripts in its repository, test data on its servers. When you change vendor or bring testing in-house, you start from zero. This cost is invisible until you want to leave, and then it is very high.
Automation maintenance. A framework built in three months needs maintenance for years. If the quote says nothing about maintenance, ask how many days a month it assumes for updating tests when the application changes.
Environment downtime. Testers waiting for a working environment cost as much as testers who are testing. Under T&M this cost is plainly yours; under fixed price it comes back as a risk buffer.
Tools and infrastructure. Test management licences, mobile device farms, CI minutes. Check who provides them and who pays.
Minimum commitments and long notice periods. A lower rate is sometimes bought with a 12-month minimum or three months’ notice. If after a quarter the team turns out too large or the project slows, you pay for people you do not need. Work out what leaving at the worst moment would cost and add it to the comparison. A shorter notice period at a slightly higher rate is often cheaper over the whole engagement, because it lets you fit the team to the real pace of work rather than the forecast on signing day.
Coordination cost on your side. Even the best external team needs someone who knows the product and makes decisions. If you do not have that person, include their cost or choose a model where the vendor takes part of that role.
When comparing quotes, lay these items out in one table per quote over 12 months. A 10% difference in rate rarely outweighs differences in turnover, artefact ownership and automation maintenance.
How do you compare quotes that price different things?
Outsourced testing quotes are rarely directly comparable, because each vendor prices a different mix of the five cost components. To compare them, reduce them to a common denominator. The table below is a tool for that: for each model it shows what you pay for, who carries the risk and what to watch.
| Criterion | Time and materials | Dedicated / managed team | Fixed scope and price | Per case or per defect |
|---|---|---|---|---|
| What you pay for | Days worked by named people | Monthly rate for a team of agreed composition | A defined deliverable (framework, strategy, report) | Number of executed cases or reported defects |
| Who carries scope-change risk | You | Mainly you, within the composition | The vendor, within the written scope | Apparently the vendor, in practice you |
| Who manages the work | You | The vendor, within the agreed scope | The vendor | The vendor |
| Best for | Changing scope and a team with a QA lead | Long-lived, stable product without a QA lead | One-off work with a clear result | Rarely justified; possibly short acceptance testing |
| Main trap | No priorities on your side | Buying execution instead of accountability | Change requests for every change | Paying for clicks |
| What to check in the quote | Replacement terms, billing only days worked | Composition with seniority, outcome measures, who owns quality | Scope, assumptions, number of fix rounds | Definition of case and defect, monthly cap |
| Artefact ownership | Usually your tools, your repository | Must be written into the contract | Must be written into the contract | Often with the vendor |
To finish the comparison, calculate the total 12-month cost for each quote: work, onboarding, management on your side, tools, automation maintenance and the estimated exit cost. For the broader question of whether to outsource testing at all, see In-house QA vs outsourced testing: how to decide.
What should you write into the contract to avoid overpaying?
A testing outsourcing contract should protect you against three risks: paying for activity instead of outcomes, losing knowledge when you change vendor, and uncontrolled cost growth. These are the clauses worth having whatever the model.
Goal and division of responsibility for quality. Who decides what is good enough to release, who maintains the risk list, who makes the release decision. If the vendor is only to execute, say so; if it is to share responsibility for quality, give it the information and a voice to do so.
Pricing model and invoicing rules. Rates, unit (day, hour, team, deliverable), invoicing only for time worked, how holidays, sickness and environment downtime are handled, currency and rate indexation.
Outcome measures and review rhythm. A few measures from the section above, baselines to be set in the first weeks and a quarterly review.
Replacement and continuity. A guarantee period for replacing a person, the time to provide a replacement, knowledge transfer rules when people change, and who pays for a replacement’s ramp-up.
Ownership and handover of artefacts. Test cases, automation scripts, test data and documentation in your tools and repositories. An explicit transfer of rights, or in jurisdictions such as Germany and Austria, where copyright cannot be assigned, an exclusive and unrestricted right of use. “Handing over the files” alone does not grant rights. An obligation to transfer knowledge at the end of the engagement, with a defined number of days.
Notice and scaling. Notice period, rules for scaling the team up and down, and whether there are any penalties for scaling.
Security and personal data. A data processing agreement under GDPR if testers will access personal data, environment access rules, an NDA.
How do you start so the first three months are not wasted?
The first three months of outsourced testing decide whether the next nine will pay off. During that period you pay the full rate for rising output, so every week saved on onboarding goes straight to the cost.
Start with strategy, not staffing. Before the testers join, write down what the risks are in your product, which areas are critical, what is already automated and where the biggest gaps are. Without this, testers start with what is easiest to test rather than what matters most. If your team has neither the time nor the skills for that, consider a short fixed-scope package first and only then T&M or a team.
Prepare onboarding. Access to environments, tools and documentation from day one. A person on your side to answer questions. A list of first tasks for two weeks. Testers who spend their first week waiting for access are the most expensive week of the entire engagement.
Set baselines for your measures. How many defects reach production, how long regression takes, how many tests are automated. Without baselines, in three months you will not be able to say whether the engagement is working.
Review after six weeks. Is the composition right, are the people working out, are priorities set well? That is the moment to replace someone under the guarantee, change the composition or the model, before the cost of a mistake compounds.
Speed of staffing is rarely the bottleneck. ARDURA states it delivers vetted QA specialists within 2 weeks and, for urgent needs, pre-screened testers within 48–72 hours. The bottleneck is your organisation’s readiness to take them on.
When does outsourcing testing not pay off?
There are situations where no pricing model will make outsourcing worthwhile, and it is worth recognising them before you start comparing quotes.
When nobody on your side owns quality. Outsourced testing without a quality owner on the buyer’s side usually ends in activity without direction. First decide who in your organisation decides what is ready to release.
When the problem is not testing but process. If defects come from unclear requirements, no code review or releases without a test environment, extra testers will find more defects but will not prevent them. Then a QA process audit is a better start than a team.
When the product is very small or short-lived. The cost of onboarding an external person can exceed the cost of their work in a project lasting a few weeks. A short, closed scope or helping developers write tests works better.
When key domain knowledge is unique and scarce. In some domains testing requires knowledge an external tester cannot acquire in reasonable time. Then outsourcing works for automation, performance and security, while domain testing stays in-house.
These situations do not rule outsourcing out entirely, but they change its scope. Often the best answer is a mixed model: strategy and quality decisions in-house, specialist capabilities (automation, performance, mobile testing, security) from outside.
What are the key takeaways?
The cost of outsourcing software testing is not the rate but the sum of five components: work, onboarding, management, tools and maintenance. Quotes differ mainly in which of these the vendor takes on and which it leaves with you, so compare the total 12-month cost, not rates.
Remember five things. First, time and materials pays off with a changing scope and when someone on your side manages quality; a dedicated team suits a long-lived, stable product; fixed scope suits one-off work with a clear result. Second, billing per test case or per reported defect is the most common form of paying for clicks; avoid it as your main model. Third, instead of case counts, measure outcomes: escaped defects, risk coverage, feedback time, stability and the share of automation. Fourth, write artefact ownership, rights transfer, replacement terms and knowledge handover into the contract. Fifth, start with a strategy and prepared onboarding, because the first three months decide whether the whole engagement pays off.
You will find more on testing and quality in our Quality Assurance hub. If you are comparing outsourced testing quotes or want to work out which model fits your product, see the scope of our software testing services or talk to us about your case. In a short call we will work out which pricing model makes sense, what team you need and what it will cost in your scenario.