A testing centre of excellence (TCoE) works when it is built around outcomes, not structure: shared standards, reusable tooling and clear ownership that make every delivery team’s testing better, faster and cheaper. It fails when it becomes a central gatekeeper that slows teams down and owns quality it cannot influence.
Most organisations that build a testing centre of excellence start with an org chart. The ones that succeed start with the problem they are trying to fix.
What a testing centre of excellence is for?
A TCoE is a function that sets how testing is done across an organisation and helps teams do it well. The aim is consistency and leverage: the same standards, tools and practices applied across many teams, so that each team does not have to solve the same problems alone.
Done well, it delivers:
- Consistent quality practice across teams, products and suppliers.
- Reuse of frameworks, test assets, environments and test data.
- Better tooling decisions, made once rather than team by team.
- Visible quality metrics that leadership can trust and compare.
- Capability growth, so testers have a clear career path and a place to learn.
Why many TCoEs underdeliver?
The pattern is familiar. A TCoE is set up to cut cost or tame inconsistency. It writes standards, builds a process library and starts reviewing other teams’ work. Delivery teams experience it as another approval step. They route around it, and the centre ends up measuring compliance with a process rather than the quality of the product.
The common causes:
- Central control without accountability. The TCoE dictates how testing is done but is not responsible for release quality, so neither side owns the outcome.
- Process before problem. Templates and governance arrive before anyone has agreed what is going wrong.
- Distance from delivery. Central testers who no longer work on real products lose credibility with the teams they advise.
- Cost as the only goal. A TCoE justified purely by headcount savings tends to cut the capability that makes testing effective.
- No operating model for agile and DevOps. A model designed for large, infrequent releases does not fit teams shipping weekly.
Choose the right model first.
There is no single correct structure. The three models most organisations choose between:
- Centralised. One team provides testing services to all projects. Strong consistency and tooling, but risk of bottlenecks and distance from the product.
- Federated or hub-and-spoke. A small central core sets standards, owns shared tooling and coaches, while testers sit in delivery teams. Better fit for agile, though it needs strong community and clear standards.
- Advisory or enablement. The centre acts as internal consultancy: guidance, frameworks, training and assurance, with teams owning their own testing.
For most product organisations shipping frequently, a federated or enablement model works better than a central service desk. Regulated sectors often need stronger central assurance on top of that. Decide this from your delivery model and risk profile, not from what another company did.
What actually works?
Start with two or three measurable problems. Defect leakage, slow regression cycles, inconsistent environments or duplicated tooling are real problems with real numbers. Define the baseline first, then show the TCoE moving it.
Make it a service teams choose to use. Offer things delivery teams cannot easily build themselves: a maintained automation framework, stable test data, shared environments, performance and security test capability. When teams pull the service in because it saves them time, adoption follows.
Keep the centre close to real work. Rotate testers between the centre and delivery teams, and have the TCoE’s leads stay hands-on. Advice from people who still test is credibly received.
Set standards that are light and few. A short set of principles, with clear entry and exit criteria and a definition of done for testing, will be followed. A large process manual will not.
Own the tooling and the data. Tool sprawl and unstable test data are the most expensive hidden costs in most test estates. Central ownership of both, with a clear support model, produces some of the fastest returns.
Publish metrics that matter. Report outcome measures such as defect escape rate, time to feedback, automation stability and maintenance effort alongside activity measures. Be open about what the numbers show.
Build the people model. Define roles, skills and career paths for testers, including test engineers and specialists in automation, performance and security. Capability is the TCoE’s real asset.
A realistic way to start.
- Diagnose. Review how testing is done today across a few representative teams. Look at tools, practices, metrics, skills and where defects escape.
- Pick the model that fits your delivery approach and risk profile.
- Pilot with one or two teams. Prove value on a real programme before scaling.
- Build the shared services that the pilot shows are most valuable, usually automation framework, test data and environments.
- Measure and publish the improvement against the baseline.
- Scale deliberately, adding teams as the service proves its worth, and revisit the model as delivery practices change.
Where AI fits?
Used carefully, AI can strengthen a TCoE by helping maintain test suites, generate and prioritise test cases, and analyse failures. The same rule applies as for any tooling: pilot it, measure it, and keep experienced testers in charge of judgement. AI amplifies a well-run test function; it does not replace the need for one.
The practical starting point.
Before designing a structure, take an honest baseline of where your testing stands: where defects escape, where effort is duplicated, how much time goes on maintenance, and where teams disagree on standards. That assessment will tell you which model and which first services will pay back fastest.
If you want an independent view of where your test function stands, our Pro-Check QA Assessment is built for exactly that starting point. Learn more about Pro-Verify and the wider solutions we provide.
Considering a testing centre of excellence, or fixing one that isn’t delivering? We help leaders assess where they are and design a model that fits. Get in touch.