Managed QA services: what do you actually buy, how is it priced and how do you choose a provider?

A VP of Engineering at a SaaS company in Boston has a familiar problem. Releases go out every two weeks, the regression suite takes three days to run manually, and every second release produces a hotfix within 48 hours. The company already rents four testers from a nearshore vendor. On paper that should be enough. In practice, the VP spends Monday mornings deciding what the testers should work on, Thursday evenings deciding whether to ship, and every retrospective explaining to the CEO why customers found bugs the team did not.

The problem is not the number of testers or their skills. It is that the VP bought capacity and kept all the responsibility. Managed QA services exist to change exactly that: to move responsibility for the testing outcome — not just the hours — to a provider who is accountable for it through measurable KPIs.

Below, we explain what that responsibility really covers and what it cannot cover, how managed QA differs from staff augmentation, project outsourcing and crowdtesting, how providers price it — with a worked cost example — which KPIs and SLAs belong in the contract, and how to plan both transition and exit before signing. Amounts are given in Polish złoty, based on our own rate benchmark for the Polish market, with indicative US dollar values at 3.70 PLN per USD.

What are managed QA services and what exactly do you buy?

Managed QA services (also called managed testing services) are a delivery model in which an external provider owns the testing process and is accountable for an agreed quality outcome. The provider plans testing, builds and runs the team, selects and maintains tools and automation frameworks, reports on release readiness and continuously improves the process. You pay for the service, not for individual people’s hours.

In practice, you buy four things:

• A managed team. The provider decides who is on the team, how many people are needed in a given release, how work is split between manual and automated testing, and replaces people when necessary — without your involvement.
• A process. Test strategy, risk-based planning, entry and exit criteria for each test phase, defect triage rules, regression approach and reporting. In a well-run service these are documented and agreed, not improvised.
• Assets. Automated test suites, test data sets, test environments configuration, test cases and documentation. These are created during the service — and the question of who owns them decides how painful exit will be.
• Accountability. KPIs and SLAs with consequences: reporting, escalation paths, service reviews and, in some contracts, part of the fee at risk.

What you do not buy is ownership of your product’s quality as a business outcome. A provider can be accountable for how well it tests what was agreed. It cannot be accountable for what your company considers “good enough” for customers — that stays with you, and we come back to it below.

How do managed QA services differ from QA staff augmentation, project outsourcing and crowdtesting?

The four models are often lumped together as “QA outsourcing”, which is the root of many failed contracts. They differ in who manages the work, who is responsible for the result and how you pay.

Criterion	QA staff augmentation	Project QA outsourcing	Managed QA services	Crowdtesting
Who manages the testers	You	Provider	Provider	Platform / provider
Who owns the test process	You	Provider, for one project	Provider, continuously	You define scope per test cycle
Accountability	For availability and skills	For deliverables of the project	For KPIs and SLAs over time	For number and quality of reported issues
Typical pricing	Hourly or daily rate	Fixed price per project	Monthly fee, per release or partly outcome-based	Per test cycle, per device or per validated bug
Duration	Months to years	Weeks to months	Usually 12–36 months	Days to weeks per cycle
Best for	Filling gaps in a team you manage	A defined release or migration	Continuous testing of a product with regular releases	Real-device and real-user coverage, localisation, usability
Your management effort	High	Medium, concentrated at milestones	Low to medium, focused on governance	Medium per cycle

Staff augmentation is the right model when you have a working QA process and a capable QA manager, and you need more hands or specific skills. We described the trade-offs between the models in general terms in our comparison of staff augmentation, managed services and outsourcing.

Project outsourcing fits a bounded effort with a clear end: testing a migration, certifying a release, building an initial automation suite.

Managed QA fits a product with a steady release rhythm where you want a stable, improving testing capability without managing it day to day.

Crowdtesting complements the other three rather than replacing them. It gives you breadth — hundreds of devices, locales and real users — but not depth in your domain, not a regression suite and not continuity.

When do managed QA services make sense — and when do they not?

Managed QA is not a universally better version of staff augmentation. It is a different contract with different preconditions. From our experience, it works well when most of the following are true:

• The product has a predictable release rhythm — every one to four weeks — so the provider can plan capacity and measure trends.
• The scope can be described. Applications, platforms, critical business flows, integrations and environments are known and relatively stable.
• You want to reduce management load, not only headcount. The goal is that your engineering leaders stop scheduling testers.
• There is a regression burden that grows with every release and needs a structured automation strategy.
• You can define what “good quality” means — at least which flows must never break and what defect level is acceptable in production.

It usually does not work, or should not be the first step, when:

• Requirements change daily and the product is still searching for product–market fit. A managed contract will spend its energy on renegotiating scope.
• Testing is inseparable from development in a small team practising pairing and continuous delivery, where “the tester” is a role inside the squad.
• Nobody can say what good quality means. Outsourcing responsibility for an undefined outcome creates a contract nobody can fulfil. In that case, first assess your current process — our in-house QA vs outsourced testing decision framework is a good starting point.
• Critical domain knowledge exists only in a few people’s heads and cannot be transferred in a reasonable transition period.

What does the scope of a managed QA service include?

A mature managed QA service covers more than “running tests”. When comparing proposals, check which of the following areas are in scope, which are optional and which are missing:

• Test strategy and planning. A documented, risk-based strategy: which flows are critical, which test levels cover them, what is automated and what is tested exploratorily. Reviewed at least quarterly.
• Functional and exploratory testing. Structured testing of new features and exploratory sessions that look for what scripted tests miss. Exploratory testing is where experienced testers add most value that automation cannot replace.
• Test automation. Building and maintaining automated suites at API and UI level, integrated into CI/CD, with a stated target for stability. Our article on how much test automation costs explains the investment curve.
• Regression management. A regression suite that is pruned as well as extended, with a target cycle time.
• Performance testing. Load, stress and soak tests before major releases or seasonal peaks — often as a capacity pool rather than a permanent role.
• Security testing. At minimum, integration of automated scanning and coordination with specialist penetration testers; full security testing is usually a separate engagement.
• Accessibility testing. Increasingly mandatory: the European Accessibility Act has applied since 28 June 2025 to many digital products sold in the EU, and automated tools find only part of the barriers.
• Test data management. Creating, masking and refreshing test data, especially when production data contains personal information. See our test data management strategy guide.
• Environments and devices. Who provisions test environments and pays for device clouds and test management tools.
• Reporting and release readiness. A clear recommendation before each release — go, go with known risks, or no-go — backed by data.

AI is increasingly part of the scope, too. According to the World Quality Report 2025-26 by Capgemini, Sogeti and OpenText, 89% of organisations are piloting or deploying generative-AI-augmented quality engineering workflows, but only 37% have them in production and 15% have scaled them enterprise-wide. Respondents reported an average productivity gain of 19%, while a third saw minimal gains. Ask providers where exactly they use AI — test case generation, test data, defect analysis — and how they verify its output.

What must stay on your side even in a managed model?

This is the most important section for anyone signing a managed QA contract. A provider can take responsibility for how well it tests. It cannot take responsibility for what your company considers acceptable quality. Five things must stay with you:

1. The definition of quality. Which business flows are critical, what defect severity blocks a release, what level of production incidents is acceptable. The provider can help formulate it, but the decision is yours.
2. Release decisions. The provider recommends; your product owner or engineering leader decides whether to ship with known risks.
3. Product knowledge ownership. Requirements, acceptance criteria and domain rules come from your side. A provider testing against vague requirements will produce vague results.
4. Governance. Someone on your side — typically a QA or engineering manager at a fraction of their time — reviews KPIs monthly, runs quarterly service reviews and owns the relationship.
5. Access and cooperation. Environments, test accounts, developer availability for defect clarification. Many SLA breaches are caused by the client, and a good contract says so explicitly.

Companies that hand over the definition of quality together with the testing tend to end up with a contract that measures activity — test cases executed, hours logged — instead of outcomes. The provider meets every SLA, and customers still find bugs.

How are managed QA services priced?

Providers use four pricing models, often in combination. Each shifts risk differently between you and the provider.

Fixed monthly fee. The most common model. The provider commits to a scope — applications, platforms, release frequency, test types — and a set of KPIs for a monthly fee. Capacity inside the team is the provider’s problem. It gives you budget predictability; the risk is that scope is defined too loosely and every new platform or integration becomes a change request.

Price per release or per test cycle. Useful when release frequency varies. The price of a standard release is agreed, with surcharges for major releases and discounts for hotfix-only cycles. It aligns cost with activity but can create an incentive to push for more, smaller releases.

Outcome-based pricing (fee at risk). Part of the fee — typically 10–20% in contracts we have seen — depends on meeting KPIs such as defect leakage or regression cycle time. This is the strongest form of accountability, but only works when KPIs are measured objectively, baselines are known and the client’s own contribution (environment availability, requirement quality) is accounted for.

Hybrid: capacity plus service. A core team is priced as a managed service, while peaks — performance testing before Black Friday, a major migration — are added from a capacity pool at hourly rates. In our experience this is often the most practical model for mid-sized products.

Whatever model you choose, check three details: what exactly is included in scope (and what counts as a change), who pays for tools and device clouds, and how the fee changes when the product grows — new platforms, new markets, higher release frequency.

How much does a managed QA service cost — a worked example?

Let us put numbers on the scenario from the introduction: a SaaS product with a web application and two mobile apps, releases every two weeks. The team needed to test it well:

Role	FTE	Rate (PLN/h)	Monthly cost
QA lead	0.5	240	PLN 19,200
Senior SDET (automation)	1	215	PLN 34,400
Automation engineer (mid)	1	165	PLN 26,400
Exploratory / manual tester (mid)	2	120	PLN 38,400
Total capacity	4.5		PLN 118,400

The rates are midpoints of the ranges in our body leasing rate benchmark for 2026 (mid manual tester PLN 100–140 per hour, automation engineer PLN 130–200, senior SDET PLN 180–250); the QA lead rate is our assumption above the senior SDET range. We assume 160 billable hours per full-time equivalent per month. For US readers: PLN 118,400 is about USD 32,000 a month — consistent with the ranges in our QA outsourcing rates overview for Poland and CEE.

Staff augmentation: PLN 118,400 a month for capacity. The client manages the team.

Managed service, fixed monthly fee: the provider adds tools and a device cloud (we assume PLN 6,000 a month) and a premium for taking on responsibility, SLAs and replacement risk (we assume 12%). The monthly fee is PLN 139,328 (about USD 37,700) — 17.7% more than staff augmentation.

That comparison is misleading, though, because staff augmentation has costs the invoice does not show. The client pays for the same tools (PLN 6,000) and spends management time: a QA or engineering manager at about 30% of their time scheduling, reviewing and reporting — at an internal cost of PLN 180 per hour, that is PLN 8,640 a month. The true comparison is PLN 133,040 versus PLN 139,328: the premium for transferring responsibility is PLN 6,288 a month, or under 5%.

Price per release: with two releases a month, PLN 69,664 per standard release (about USD 18,800).

Outcome-based variant: 85% of the fee fixed (PLN 118,429) and 15% at risk (up to PLN 20,899), paid according to three KPIs. If the provider meets two of the three in a month, the fee is PLN 132,362.

Over a year, the managed service in this example costs about PLN 1.67 million (about USD 452,000). Whether that is good value depends less on the premium and more on what it buys: whether your engineering leaders get their Mondays and Thursdays back, and whether customers stop finding bugs first.

Which KPIs and SLAs should a managed QA contract include?

KPIs are the heart of a managed contract. Good KPIs measure outcomes and are hard to game; bad ones measure activity and are easy to meet without improving anything.

Outcome KPIs:

• Defect leakage — the share of defects found in production out of all defects found in a period. If testing finds 188 defects before release and customers report 12 after it, leakage is 6%.
• Defect removal efficiency (DRE) — the inverse: the share of defects removed before release (94% in the same example). Capers Jones, who popularised the metric, estimated the average for US software at about 85% and found that best-in-class projects exceed 99% — but only by combining testing with inspections and static analysis. A realistic contractual target depends on your baseline; set it after measuring, not before.
• Severity-weighted escapes — number of critical and high-severity defects reaching production. One critical escape matters more than ten cosmetic ones.

Process KPIs:

• Regression cycle time — how long a full regression takes, from build to report. In our scenario, the goal is to go from three days to under one.
• Automated test stability — the share of automated test failures caused by the tests themselves (flaky tests). Unstable suites are ignored by developers, which makes them worthless.
• Risk-based coverage — the share of critical business flows covered by automated tests, not the raw number of test cases or code coverage.
• Release-readiness reporting on time — a go/no-go recommendation delivered before the agreed cut-off.

SLAs define response times: how fast a critical defect is triaged, how quickly the team scales for an unplanned release, how fast a departing team member is replaced.

How should targets be set? We recommend three rules. First, measure for two to three release cycles before any KPI becomes binding — the parallel run described below is the natural moment. Second, agree on trends, not only thresholds: “defect leakage reduced by a third within two quarters” is fairer and more useful than an absolute number pulled from a benchmark. Third, tie each outcome KPI to a client-side dependency: if test environments are unavailable for more than an agreed number of hours in a release cycle, the regression-time SLA for that cycle is suspended. Without that clause, the provider carries risks it cannot control and will price them in.

For fee-at-risk contracts, keep the mechanics simple. Three KPIs with equal weight, measured monthly, with the result visible in a shared dashboard, work better than a dozen weighted indicators that nobody can recalculate. In the example above, each KPI met releases one third of the variable part of the fee. Some clients add a bonus above 100% for exceeding targets; in our experience this makes sense only after the first year, when the baseline and the provider’s real capability are well understood.

Two KPIs to avoid as primary measures: number of test cases executed and number of defects found. Both reward volume. A provider paid for defects found has no interest in helping you prevent them. For a broader overview of test metrics, see our glossary entry on software quality assurance.

How does the transition to a managed QA provider work?

The first weeks of a managed service decide whether the rest works. A structured transition usually has four phases:

1. Discovery (2–3 weeks). The provider studies the product, existing test assets, defect history and release process, interviews developers and product owners, and measures the baseline: current leakage, regression time, automation stability.
2. Knowledge transfer and shadowing (2–4 weeks). The new team works alongside the current testers or developers, takes over test execution under supervision and documents what was undocumented.
3. Parallel run (1–2 release cycles). The provider runs testing, while the client’s team still validates results. KPIs are measured but not yet binding.
4. Steady state. KPIs become contractual, service reviews start, and the improvement roadmap — typically automation of the regression suite — begins.

Transition has a cost. If productivity during a six-week transition averages 50% while the full fee is paid, the value “lost” in our example is about PLN 104,500 (about USD 28,200). Some providers discount the transition period; others include it in the price. Either way, it should be visible in the proposal, not discovered later.

The most common transition mistake is starting KPIs on day one. Without a baseline, targets are guesses — and a provider forced to accept guessed targets will price in the risk.

How do you plan the exit before you sign?

Every managed service ends — because the product changes, the company builds in-house capability or the relationship does not work. The time to plan the exit is before signing, when you still have negotiating leverage.

A sound exit plan in the contract covers:

• Ownership of test assets. Automated test code, test cases, test data scripts, documentation and environment configuration created during the service should belong to you, stored in your repositories, not the provider’s.
• Tool independence. If automation depends on the provider’s proprietary framework or licences, exit means rewriting everything. Prefer open frameworks and tools licensed in your name.
• Exit assistance. A defined period — typically one to three months — during which the provider supports knowledge transfer to your team or a new provider, at an agreed price.
• Documentation standards. Test strategy, risk register and runbooks kept current throughout the service, not produced in a rush at the end.
• Notice periods and termination rights that match your risk: long enough for an orderly handover, not so long that you are locked in.

Two legal points deserve attention. First, intellectual property in the test code. Automated test suites are software, so a general statement that “assets belong to the client” may not be enough — the contract should assign the rights explicitly or grant a broad, irrevocable licence. Otherwise you may have the code in your repository but not the right to modify it freely or hand it to another provider.

Second, personal data in testing. If the provider accesses production data or copies of it, and your company processes data of EU residents, you need a data processing agreement under Article 28 of the GDPR, and the exit plan should state how and when the provider deletes or returns the data. The safest option remains masked or synthetic test data, so the provider never works on real customer records. This article is not legal advice — review these clauses with counsel before signing.

A provider unwilling to agree on asset ownership and exit assistance is telling you something about how it plans to keep your business.

How do you choose a managed QA provider?

Price comparisons between managed QA proposals are almost meaningless unless scope, KPIs and asset ownership are comparable. The scorecard below helps evaluate proposals consistently. Score each criterion from 0 (absent or unclear) to 2 (strong, evidenced):

Criterion	What “2” looks like	Weight
Understanding of your product and risks	The proposal names your critical flows and risks, not generic test types	3
Test strategy	Risk-based strategy with a clear split between exploratory and automated testing	3
KPIs and SLAs	Outcome KPIs, baseline before targets, client obligations stated	3
Transition plan	Phased plan with parallel run and visible transition cost	2
Asset ownership and exit	Assets in your repositories, open tools, defined exit assistance	3
Automation approach	Maintainable framework, stability targets, CI/CD integration	2
Team stability and seniority	Named key people, replacement SLA, low attrition evidence	2
Reporting and governance	Release-readiness report sample, monthly and quarterly reviews	2
AI and tooling	Specific, verified uses of AI; tools licensed transparently	1
References in similar products	Contactable references with comparable release rhythm and domain	2

Multiply scores by weights; the maximum is 46. In our experience, a proposal below about 30 points usually hides the gaps that later appear as change requests. Ask every shortlisted provider to walk you through a real release-readiness report and a real defect-triage session from another client (anonymised). How a provider talks about a missed release tells you more than its sales deck.

What are the red flags in managed QA proposals?

Across the proposals we have reviewed for and with clients, the same warning signs recur:

1. KPIs based on activity. “We will execute 1,500 test cases per release” is a promise of effort, not of quality.
2. Targets without a baseline. A provider promising “defect leakage below 2%” before seeing your defect history is either guessing or planning to redefine what a defect is.
3. No client obligations. If the contract does not state what you must provide — environments, requirements, developer availability — every SLA breach will be disputed.
4. Proprietary automation frameworks with licences in the provider’s name and no clear exit terms.
5. Automation promises without maintenance costs. Automated suites need continuous upkeep; a proposal that shows only build costs underestimates the total by design.
6. A team presented only as roles. Managed does not mean anonymous. Key people — at least the QA lead and senior automation engineer — should be named and their replacement governed.
7. “We test everything.” Risk-based testing means deliberately not testing some things deeply. A provider that does not ask what matters most has not understood the job.
8. No transition cost. Either it is hidden in the fee or the provider plans to learn your product at your customers’ expense.

Each of these can be fixed in negotiation — but only if you notice them before signing.

How do you prepare to buy managed QA services?

The best managed QA contracts start with homework on the client’s side. Before you send a request for proposal:

• Measure your baseline. Defect leakage over the last three to six months, regression duration, number of hotfixes per release, automation coverage of critical flows. Even rough numbers are better than none.
• Write down your definition of quality. Critical flows, severity definitions, release criteria. Two pages are enough to start.
• Inventory your assets. Existing test cases, automation code, test data, environments — and who owns them today.
• Decide your governance. Who on your side will own the relationship and how much time they will spend on it.
• Choose the pricing model deliberately. Fixed fee for predictability, per release for variable rhythm, fee at risk for strong accountability — or a hybrid.

If you are unsure whether managed QA or staff augmentation fits your situation, our comparison page staff augmentation vs managed services summarises the decision in one view.

Key takeaways:

1. Managed QA transfers responsibility for the testing outcome, not for your definition of quality. Keep the latter on your side.
2. The visible premium is misleading. In our example it is 17.7% on the invoice but under 5% once tools and management time are counted.
3. KPIs must measure outcomes. Defect leakage, DRE, regression cycle time and test stability — not test cases executed.
4. Baseline first, targets second. Binding KPIs from day one without measurement create disputes and risk premiums.
5. Plan the exit before signing. Asset ownership, open tools and exit assistance protect you whatever happens.

At ARDURA Consulting we have been delivering software testing for clients in Poland, Europe, the Middle East and the USA for more than ten years — both as QA specialists within client teams and as managed testing services with agreed KPIs. We start every engagement by measuring the baseline and agreeing on what quality means for the product, because without that no SLA is worth signing.

If you are considering managed QA for your product, or want to check whether your current QA outsourcing contract measures the right things, see our software testing services or talk to our team.