Testing Center of Excellence vs Managed Testing vs QA in Product Teams: How to Choose

A testing center of excellence (TCoE), managed testing, and quality assurance (QA) engineers in product teams are three ways to organize software testing. Each answers a different question about who owns the test strategy, automated tests, and release decisions.

Each model puts that ownership in a different place:

• TCoE. One central team sets testing rules and tools for everyone.
• Managed testing. An outside company does the testing for you.
• QA engineers in product teams. Testers work with developers on each team.

Deciding who owns testing is important because it shapes how fast you ship and whether your code waits in a queue for regression testing.

This question usually comes up when the number of product teams grows, and regression testing becomes the bottleneck before each release. Published research pulls in opposite directions here.

In the 2025 World Quality Report, a vendor survey found that 67% of organizations still rely on central QA or testing teams. Research by DevOps Research and Assessment (DORA) links better software delivery to the opposite setup, where developers write and maintain their own automated tests.

That is why we wrote this guide. The difference is easiest to see in practice, so we show it on our own work with MasterControl and Kin Insurance.

We compare the models on the same criteria and show when each one wins and when it fails. By the end, you will know which model is the best for your case.

What Is a Testing Center of Excellence (TCoE)?

A testing center of excellence (TCoE) is a central team that decides how the whole organization tests and builds shared assets for every product team.

In some companies, the TCoE has its own testers who run the tests for every product. In other companies, the TCoE writes the testing rules and builds the tools, and developers and testers on each product team use them to test their own product.

This is what sets a TCoE apart from a QA department. A QA department may only run tests, but a TCoE owns many things for multiple teams, from standards to shared tools.

The TMMi model (Test Maturity Model integration) describes the same idea under the name “test competence center.” Its version 2.0 lists the typical tasks of such a center as setting up, managing, and improving test processes, defining a test automation strategy, and giving projects and teams people with testing experience and skills.

You will also see the term “test center of excellence,” which means the same thing. Some companies give the center a narrower scope, such as a “test automation center of excellence” that owns only the automation framework, or a center focused on performance or mobile testing.

What a TCoE owns and what it gives you

A typical TCoE owns these areas for all teams:

• Standards and governance. The test policy, quality gates, and the definition of done for testing.
• Shared test automation framework. One framework that every team builds its tests on. We describe how product teams took over test ownership on such a framework in a separate article.
• Tools and licenses. One set of tools, bought and maintained in one place.
• Test data and environments. Shared setups that teams don’t have to rebuild.
• Training and onboarding. Guidance for new testers and for developers who write tests.
• Metrics and reporting. One view of quality across all products.
• Specialist testing. Performance, security, and accessibility testing that no single team can staff alone.

The main benefit of a TCoE is that all your teams follow the same testing rules and use the same framework. A test result then means the same thing across products, and teams don’t waste time building a test environment another team already has.

This is also why central testing teams stay popular. The authors of the World Quality Report explain this as the need for consistent standards, specialized skills, and efficient resource use.

Testing Center of Excellence vs Managed Testing vs QA in Product Teams

The main difference between a testing center of excellence, managed testing, and QA engineers in product teams is who takes responsibility when a test fails before a release. Depending on the model, a central team, an outside provider, or your own product team fixes the test, and the release decision stays on your side.

For years, companies framed this choice as a centralized vs embedded QA team debate, asking whether testers should sit in one central team or inside each product team. Managed testing adds a third option, where an outside provider takes over a defined testing workstream and reports the results to you.

Another useful way to compare the models is test independence, how far the tester is from the person who wrote the code.

The Foundation Level syllabus from the International Software Testing Qualifications Board (ISTQB) describes four levels of independence:

• No independence. The author tests their own code.
• Some independence. Peers from the same team test it.
• High independence. Testers from outside the team, but inside the organization, test it.
• Very high independence. Testers from outside the organization test it.

In our reading, each model lands on a different level. QA engineers inside a product team check the work of their own teammates, which counts as some independence.

A central TCoE team that runs tests belongs to your company but not to the product team, so it gives high independence. A managed testing provider works for a different company, which gives very high independence.

Higher independence helps catch blind spots, but it also puts the tester further from the product. We come back to this trade-off when we look at how to choose a model.

The table below compares the three models on the same criteria. Each row is a question you will face, and each column shows how one model answers it. You can copy it into your own decision deck and mark which answers fit your teams.

Many organizations combine models, for example, a small central team that owns standards and the shared framework, with QA engineers in every product team. This setup is called a federated TCoE, and we look at it in the section on TCoE models below.

Is the Testing Center of Excellence Obsolete? What the Survey Data Shows

The testing center of excellence isn’t obsolete, and current survey data shows central testing teams are still the most common setup. Companies plan to move away from them, but slowly.

This question comes up because guides on the topic tell two opposite stories. One test tool vendor, Katalon, writes that Agile made the traditional TCoE obsolete, and another vendor, Tricentis, wrote in December 2024 that the TCoE is making a comeback.

The 2025 World Quality Report gives a more measured picture. It is a vendor survey by Capgemini, Sogeti and OpenText, companies that sell testing services and tools, based on 2,000 interviews with senior IT executives in 23 countries in June and July 2025.

One question asked how quality engineering (QE), the report’s term for testing and quality work, is organized for Agile projects. The table below shows how 994 respondents answered. Each row is one answer option with its share, so you can see which setup is most common and where your own company fits.

The report counts the first two answers together as centralized approaches, which gives 67%. Its authors read this as a sign that TCoEs still play a role, although the answer options never use the term TCoE.

Respondents expect only a modest change. They plan to reduce centralized approaches from 67% to 62% within two years, and 15% expect quality engineers to be fully embedded in Agile teams by then.

On average, respondents said 25% of their quality engineers work inside Agile teams today, and they expect that share to reach 35% in two years. These are plans, so treat them as direction and not as measured change.

The report’s analysts recommend moving gradually from central structures to embedded or federated models, where testers sit in product teams, and a small central team maintains shared rules.

So the real choice is which work your central team keeps and which work it hands to product teams, and the next section shows the shapes this can take.

Testing Center of Excellence Models: Centralized, Federated and Hybrid

The main testing center of excellence models differ in where the testers work and how much the center owns:

• Centralized TCoE. The center has its own testers, and they test every product.
• Federated TCoE. Testers work in product teams, and a small center sets the rules.
• Hybrid TCoE. Testers work in product teams, and the center also keeps specialist testing, such as performance or security, as a shared service.

Names vary between sources, so read the table below as our working definitions. Each row is one model, and the last two columns show when it fits and what to watch for, so you can see which risks you are ready to manage.

For high-risk and regulated work, sources point in different directions:

• Embed testers where the risk is. The author of the World Quality Report chapter writes on Sogeti’s blog that the most effective organizations embed quality engineers selectively in high-risk or regulated areas and keep shared services for specialized testing.
• Keep testers independent. ISTQB notes that safety-critical work may need a high level of test independence.

We recommend deciding this area by area, based on each product’s risk.

How federated and hybrid TCoEs divide the work

A federated or hybrid TCoE helps when you have many product teams and a central testing queue would slow them all down. Many companies hesitate here because they assume a maturity model requires a separate test department.

The TMMi model, in its version 2.0 released in June 2026, addresses this directly:

• It says that reading its Test Organization area as a demand for a separate test department is a common mistake, and it names a test competence center as another valid setup that is much preferred in Agile work.
• It notes that a tester typically works day-to-day in an Agile or DevOps team and also belongs to a test competence center or a test guild, a community of testers from different teams.

One practitioner quoted in the World Quality Report describes this setup at Euroclear Sweden. Every product squad there has its own testers, testing skills are gathered in a guild, and separate teams support infrastructure and tooling.

In our view, the split between the center and the teams can stay simple:

• The center decides what must be true for every team, such as quality gates, the shared framework, and test data rules.
• Each team decides how it tests its own product.

Case study: MasterControl’s shared test automation framework

Challenge. At MasterControl, manual and inconsistent testing slowed releases, and software development engineers in test (SDETs) had become a bottleneck. Application teams also lacked the tooling to own their test development.

What we did. A team of 3 Zoolatech engineers built one test automation framework that covers everything from static analysis to performance testing. We connected it to the company’s continuous integration and continuous delivery (CI/CD) pipeline in GitHub and trained the application teams to use it.

Result. Test ownership moved to the development teams, and the SDET bottleneck disappeared. Application teams now build and maintain their own automated tests within the shared framework, and the reusable framework keeps new technical debt from piling up as teams grow.

This is the core idea of a federated TCoE, where the center owns the framework and teams own their tests. The details are in our case study on MasterControl’s shared test automation framework.

When a Testing Center of Excellence Becomes the Bottleneck

A testing center of excellence becomes the bottleneck when every release has to wait for it. This usually happens when the center writes and maintains the tests for all teams, owns the test environments, and signs off each release by hand.

The cost goes beyond waiting time. DORA notes that when groups other than developers own test automation, test suites are frequently broken and developers write code that is hard to test. DORA explains that developers who don’t test their own code find it hard to learn how to write code that is easy to test.

ISTQB describes the same risk from the tester’s side. Independent testers can become isolated from the development team, developers may stop feeling responsible for quality, and testers may be seen as a bottleneck or blamed for late releases.

Watch for these signs that the center has turned into a queue:

• Product teams file test requests and wait for their turn.
• Teams can’t fix a broken test without the center’s help.
• The center’s headcount grows with every new product.
• Release dates depend on when the center has a free testing window.

Testing center of excellence best practices that prevent it

Five practices keep the center useful without turning it into a gate for every release:

• Let teams own their tests. Product teams write and maintain their automated tests, and the center owns the framework they build on.
• Pair testers with developers. DORA calls this good practice for creating and evolving automated test suites, and it spreads testing skills across the team.
• Publish quality gates. Write down the checks every release must pass, so teams can verify them without waiting for a manual sign-off.
• Keep specialist testing shared. Keep performance, security, and accessibility testing with the center, because few teams can staff them alone.
• Review the center’s scope every year. Check what the center still owns and hand over the work that teams can now do themselves.

Some companies solve the same queue problem differently and move testing outside the company, which brings us to managed testing.

Managed Testing: What You Hand Over and What You Keep

With managed testing, you hand a defined testing workstream to a provider that plans the testing, runs it and reports the results to you, often against agreed service levels. You keep the release decision and share the product knowledge the provider needs to test the right things.

Providers that sell managed testing, such as Hexaware, describe it as the provider owning the test process end to end, from strategy to reporting, under service-level agreements (SLAs). Some providers call the same offer managed QA services. Be careful with TCoE guides that use “Managed Testing” as the name of a maturity stage, because that is a different idea.

Managed testing works well in these situations:

• The work has a fixed scope. Testing that stays the same from sprint to sprint, such as regression testing, is the easiest to hand over.
• You have no one to manage testers. Zoolatech’s own guidance on engagement models says that if you need full delivery ownership with no internal management responsibility, managed delivery is the right model.
• You need an outside check. A provider gives very high independence in ISTQB terms, which helps when you want to verify software built by your teams or by other vendors.

It works poorly in these situations:

• QA is already a core competency. DeviQA, a managed testing provider, says that if software quality is central to your product’s competitive advantage and your team has deep testing expertise, outsourcing brings more risk than it removes.
• You want to control every test. The same provider warns of friction when stakeholders want to approve every test case or direct testers daily.
• The provider owns your automated tests. In our reading, a provider that writes and maintains your automated tests is one of the “other groups” DORA warns about. ISTQB adds that independence does not replace product familiarity.

In our view, these things should stay in-house whatever provider you choose:

• Approval of the test strategy and acceptance criteria.
• The release decision.
• Test code and pipeline configuration in your own repositories.
• Access to the people who know the product.
• A dated plan for taking the work back, which we cover in the section on switching models.

The concern about handing testing away is not new. In 2014 and 2015, the Thoughtworks Technology Radar put testing as a separate organization on Hold and argued that a team cannot outsource testing, although the item no longer appears on the current Radar.

If you want a partner to own a whole workstream, testing included, see how our managed delivery model works. If you are still weighing contract models, we compare staff augmentation vs managed services in a separate guide.

QA Engineers in Product Teams: When the Whole Team Owns Quality

With QA engineers in product teams, testers work inside each product team, test alongside the developers, and help them write and maintain automated tests. This model follows what ISTQB calls the whole team approach, where any team member with the right skills can do any task, and everyone is responsible for quality.

DORA’s research looks at who owns the automated tests, without comparing QA models by name. It shows improved performance when developers primarily create and maintain automated test suites and can quickly fix failing acceptance tests.

DORA also says testers and QA teams still play an important role. In this model, they bring testing skills to the team and work with developers on the test suites.

QA engineers in product teams are a strong choice in these situations:

• You release often. Testers in the team check each change as it is built, so testing doesn’t hold up the release.
• Your product has deep domain logic. Testers who work with the same product every day learn its rules and edge cases.
• Teams already own their pipelines. They can run and fix their own tests without waiting for another group.

The model struggles in these situations:

• Test automation is thin. In the 2025 World Quality Report, the two barriers to embedding quality engineers in Agile teams that respondents named most often were “not automated enough” (59%) and quality engineers lacking the skills Agile projects need (55%). Another barrier, quality engineering not being a strategic priority, was named by 46%.
• The product is safety-critical. ISTQB notes that the whole team approach may not always fit, and safety-critical work may need a high level of test independence.
• Teams have no shared rules. Without common standards, each team tests differently, and practices drift apart.

If your QA engineers come from a partner, someone on your side still has to direct them. Zoolatech’s own guidance for team extension says this model needs a technical lead on the client’s side who manages the engineers directly.

Case study: QA engineers and SDETs inside Kin Insurance’s product teams

Challenge. Kin Insurance needed to grow the product teams behind its digital insurance platform, including QA engineers and SDETs who could work inside its existing Agile teams.

What we did. Zoolatech backend, frontend, full-stack, QA, and SDET specialists joined Kin’s product teams as regular team members. Our engineers joined daily standups, retrospectives, and planning, just like the client’s own engineers.

Result. Our QA engineers and SDETs strengthened Kin’s QA and automation capabilities, working alongside the developers in its product teams. They supported testing activities, defect investigation, automation opportunities, regression testing, and quality assurance processes. You can read more about QA engineers and SDETs in Kin Insurance’s product teams in our case study.

The same model can grow with the client. In a broader engagement with MasterControl, our team grew from 2 engineers to approximately 60 working inside product teams, and a 60-engineer delivery organization was in place within about 18 months. QA automation was one of several areas in that work.

Our team extension model is built for this setup, with QA engineers joining your product teams and working under your technical leads.

How to Choose Your QA Operating Model

Decide who will own the automated tests as part of that choice, because DORA links better delivery performance to developers who own their test automation.

Match the model to the main problem your teams have today:

• Teams test in different ways. A TCoE or a hybrid gives every team the same rules and the same framework.
• You have no one to manage testing. Managed testing lets a provider run a defined workstream for you.
• Feedback is slow, and testers don’t know the product. QA engineers in product teams keep testing close to the code and to the people who know the domain.

These questions help you narrow the choice:

1. How many product teams share the same platform and standards? Many teams point to a TCoE or a hybrid.
2. Who will write and maintain the automated tests? If the answer is developers, a federated TCoE or QA engineers in product teams fit best.
3. Do you have leads who can direct testers every day? Without them, managed testing is the safer option.
4. How much independence does the risk call for? ISTQB notes that safety-critical work may need a high level of independence, such as testers from outside the team.
5. Can the domain knowledge move to an outside team? If it can’t, keep testing in-house.
6. Is the software used in a regulated process? If it is, read the section on regulated software below.

The World Quality Report quotes an IT director at Medica, a US health plan, who describes the trade-off well. He says central teams risk becoming a staffing service, and a decentralized setup can create fragmentation and accountability gaps, so his company is moving toward a hybrid model.

Each model can also win where it usually loses:

• A TCoE wins when many teams build on one platform and need the same quality gates and specialist skills.
• Managed testing wins when you need an independent check of software built by several vendors.
• QA engineers on product teams can work on regulated products when you add an independent verification layer.

ISTQB supports this kind of mix and says that for most projects it is usually best to test with multiple levels of independence. If you decide to bring in an outside partner, our list of software testing companies can help you build a shortlist.

Regulated software

If your software is used in medical device production or in a quality management system, check the nonbinding Computer Software Assurance (CSA) guidance from the U.S. Food and Drug Administration (FDA), issued on February 3, 2026. It lets manufacturers use validation work done by others, such as developers and suppliers, and it does not cover device software functions.

Manufacturers remain responsible for deciding which assurance activities they need. In our reading, any of the three models can work under this guidance, and an outside provider does not take over the manufacturer’s responsibility.

We explain what FDA’s CSA guidance changes for software vendors in a separate article.

What each model costs you

Each model brings its own cost items:

• TCoE. Central staff, tool licenses, environments and training, plus the time product teams spend waiting for the center.
• Managed testing. Provider fees, onboarding and knowledge transfer, contract management, and the cost of leaving the provider.
• QA engineers in product teams. QA engineers in every team, the time your leads spend directing them, and tools that several teams buy separately.

We recommend comparing the total cost over the whole life of the setup, because hourly rates hide most of these items.

When none of the three fits

If your product has little test automation or code that is hard to test, a new structure will not help much. DORA suggests starting with a skeleton deployment pipeline that builds and deploys the code, then adding tests step by step. It also notes that code written without testing in mind is hard to test later.

With one or two product teams, a full TCoE is usually more than you need. In our view, a QA lead and a shared framework cover most of the work at that size.

We work in two of these models. Our QA engineers and SDETs can join your product teams, or a Zoolatech team can run testing as a managed workstream, and every engagement includes a dedicated delivery manager, a live risk register, and a formal QA checkpoint.

Switching QA Models Without Losing Your Tests

Switching QA models goes wrong when the tests, tools, and product knowledge stay with the old owner. Before you move, make sure the test code lives in your repositories, someone on your side can run and fix it, and the outgoing team writes down what it knows.

Check that these assets move with you:

1. Test code and framework

The automated tests and the framework they run on live in your repositories, and your team can work with them without outside help.

2. Pipeline configuration

You own the setup that runs tests on every change, so a new team doesn’t have to rebuild it.

3. Test data and environments

You have the scripts and instructions to create test data and environments from scratch.

4. Risk lists and exploratory notes

The outgoing team hands over its notes on risky areas of the product and what it learned from manual testing.

5. Runbooks

Common tasks, such as rerunning a test suite or fixing a test that fails at random, are described step by step.

6. Knowledge transfer plan

You agree on handover dates at the start of the engagement, so nobody has to improvise at the last moment.

The 2025 World Quality Report makes a similar point in its advice on adopting AI in quality engineering. It says external experts should help transfer knowledge to internal teams, “building capability rather than dependency.” We apply the same rule to any outside QA partner.

Our MasterControl project followed this rule. The application teams were trained and empowered to take full ownership of test development and maintenance.

Testing Center of Excellence Strategy: First Steps If You Build One

A testing center of excellence strategy should start with the center’s mandate, because a center that hires people before anyone agrees on its role can turn into the queue we described earlier.

Write down what the center owns, what product teams own, and how you will know the center helps. Then pilot the shared framework with one or two teams and expand only when those teams maintain their own tests.

The table below breaks this into five steps. Read each row from left to right, and use the last column as a simple check before you move to the next step.

The pilot decides the outcome. When product teams own their tests, a testing center of excellence framework has to work for them without the center’s help, and the pilot shows whether it does.

In our view, the center needs a lead, one or more test architects or framework engineers, and an owner for test data and environments.

The size of each role depends on how many teams the center supports, and the numbers you collect in the baseline step tell you whether the setup works, as the next section explains.

How to Measure Whichever Model You Choose

Whichever model you choose, measure it with the same yardstick, one application or service at a time. Track how your software delivery performs, who writes the tests and where bugs are found, because a working model catches more bugs early, when they are cheaper to fix.

For delivery, DORA’s current guide uses five software delivery metrics:

• Change lead time. How long a code change takes to reach production.
• Deployment frequency. How often you release.
• Failed deployment recovery time. How quickly you recover from a failed release.
• Change fail rate. The share of releases that need immediate fixing after they go out.
• Deployment rework rate. The share of releases made only to fix problems in production.

This five-metric model replaced DORA’s original four keys, and failed deployment recovery time replaced mean time to recovery (MTTR). DORA also notes that the metrics work best for one application or service at a time.

For testing itself, DORA suggests three more measures:

• Who writes the tests. The share of tests written by developers, testers, and other groups.
• Where bugs are found. Bugs found in acceptance testing, exploratory testing and production, with more of them caught in the cheaper phases over time.
• Time spent on failing tests. Time teams spend fixing acceptance test failures, which should decrease.

The same numbers tell a different story in each model. The table shows what to watch in each one and what a good trend looks like, so you can review the results with your teams.

Final Word

Choosing between a testing center of excellence, managed testing and QA engineers in product teams takes time. You need to look at how your teams test today, talk to the people who maintain the tests, and agree on who makes the release decision.

This effort pays off. The wrong model shows up later as a release queue, tests your team can’t fix, or product knowledge that leaves with a provider, and each of these problems is harder to undo than to prevent.

Many companies end up with a mix of a small central team for shared assets, and QA engineers inside product teams, and TMMi notes that it is common for a tester to belong to both. Whatever model you pick, keep the automated tests with the people who change the code.

Start with the decision questions in this guide, pilot the change with one or two teams, and measure the results before you roll it out across the organization. If you want a partner’s view before you decide, we are ready to discuss your setup and show how our software testing services can support the model you choose.