Scenario: One shared service for every team

This is a fictional but representative engineering organization. It is not a customer, nobody in it is a real person, and nothing in it is a quote. The numbers about the organization are arithmetic, with the inputs shown.

Thirty teams, thirty ways of running tests

Two things were true at once.

First, across the company, nobody could say what the agents had tested. Three months into the AI program, an inventory showed teams using open source agent frameworks nobody had reviewed, models nobody had approved, and tests running wherever the framework happened to put them: a vendor's sandbox, a laptop, a CI container, and in a few cases a shared staging cluster with credentials pasted into a config file. Each team had its own results store, or none.

Here's the math: 30 teams with 30 ways of running tests are 30 places to look when a regulator or an incident review asks what was tested. If each team spends a fifth of an engineer keeping its own tooling alive, that is six engineers maintaining thirty copies of roughly the same thing.

Same tests, same place, whoever asked, in whichever team. Costs time and compute per change, and a platform team now owns the service.

Second, inside the teams that already tested every pull request in its own cluster, verifying every change properly did not fit in the day. The team would not treat an agent's own pass as enough for code that moves money. The architect had read the research: coding agents have been measured rewriting, hard-coding or special-casing tests to make them pass. And the full regression suite is 1,400 tests and takes about 25 minutes as a block.

At 40 pull requests a day, that is roughly 17 hours of suite time if nothing runs in parallel. Running it in parallel is a compute bill. Grouping changes into larger releases makes batches bigger, which is what makes releases less stable. So engineers were choosing which tests to run by hand, per pull request, and the auditor had started asking how those choices were recorded.

What they did

The architect had three options: a central mandate with gate reviews, which slows every team and which teams route around; a policy document for the federated model, which changes nothing without something to enforce it; or a shared service given to every team before each one built its own, the way the company had once standardized on a single browser-testing framework. They chose the third.

1. One shared service, provided ahead of time. Testkube ships in the team onboarding package. A new team gets it on day one and does not build a wrapper.
2. The same runtime for every caller. Coding agents call it over MCP; each team's pipeline calls it at the pull request gate; engineers call it from the CLI. The same tests run the same way regardless of who asked, so a pass means the same thing in every team.
3. Tests run in the company's own infrastructure, including inside each pull request's cluster. When a pipeline brings a PR's virtual cluster up, Testkube runs the tests as native jobs inside it, against that change's real dependencies, with the frameworks the team already trusted: Playwright for the UI, k6 for load, pytest for the services. Testkube does not create the environment; the pipeline does.
4. Selection by people, recorded with the run. For each service area, people defined which tests run for a change to that area. The agent chooses among those definitions rather than assembling its own set, so what runs does not drift from one run to the next, and the choice is logged with the run. A change to the profile service runs the profile tests and the checkout tests that render the profile name; it does not rerun the full payment suite.
5. A nightly backstop. The full suite runs once a night, so anything a human-defined set misses is caught a day late rather than not at all. The sets are reviewed quarterly, because they go stale.
6. One execution history across every team. Who ran what, from which team, which agent or person, against which environment, with logs and artifacts.
7. Teams keep their autonomy above the line. Each team still chooses its coding agent and model from the approved list. What they share is the layer underneath.

What changed

The platform team now runs a service with an availability commitment it did not have before. Six teams had already built their own tooling and did not want to move; two were allowed to keep theirs for a year on the condition that their results feed the shared record.

In the teams that test every pull request in its own cluster, a change no longer triggers all 1,400 tests. It triggers the set people defined for its service area, inside the cluster the pipeline already created for it. How much suite time that saves depends on how narrow the changes are, so the teams read it from execution history rather than estimate it. No figure is claimed here.

When the auditor asks how test selection is decided, the answer is the recorded definition and the run log: this is what ran, this is who or what triggered it, this is the evidence, this is why these tests and not those. And the architect's question changed from how to stop thirty teams to how quickly the service could be made easy enough that a new team would take it on its first day.

If this is you

One place for every team's tests.

The same tests, the same way, whoever asks, inside your own clusters, with one record across teams.

Start free trial