Your CI Pipeline Is Not a Testing Platform (and That's Why Feedback Takes 45 Minutes)

You push a commit. You open a PR. And then you wait.

The CI pipeline kicks off: build, lint, unit tests, maybe an integration suite if someone wired it up. Fifteen minutes pass. Twenty. You context-switch to something else. Forty-five minutes later, a red X appears next to your PR. You click through three layers of logs to find out a Selenium test timed out because the staging database wasn't seeded properly.

That's not a testing problem. That's an infrastructure problem disguised as a testing problem. And your CI pipeline, no matter how many YAML files you throw at it, was never designed to solve it.

CI pipelines are build tools, not test orchestrators

GitHub Actions, GitLab CI, Jenkins, CircleCI: these are excellent at building artifacts, running linters, and executing unit tests. They're designed to take code from commit to container. What they're not designed for is orchestrating complex test suites across multiple environments, managing test dependencies, or giving you meaningful feedback when something fails in a way that has nothing to do with your code.

The moment you start bolting on integration tests, load tests, or end-to-end suites to your CI pipeline, you're asking a build tool to do the job of a test platform. And the cracks show up fast.

Tests queue behind builds because runners are shared. Load tests can't run at realistic scale because the CI runner doesn't have the resources. End-to-end tests fail because the environment they're hitting isn't the environment your app actually runs in. And when something does fail, you get a wall of logs with no context about whether the failure was in your code, the test infrastructure, or the network between them.

TomTom's B2C IAM team ran into exactly this. Before they restructured their testing, they were running tests on three dedicated virtual machines with no version tracking. Test scripts were manually triggered. Integrating testing frameworks into their CI/CD pipelines was complex. And visibility into test results across their development, testing, acceptance, and production environments was limited.

Iakym Lynnyk, an Expert Systems Engineer at TomTom, led the effort to change that. The problem wasn't that they lacked tests. They had SOAP UI tests for functional validation, JMeter for load and stress testing, and Selenium-based UI tests built with Maven. The problem was that none of these ran in a way that gave developers fast, reliable feedback.

The feedback loop tax

Every minute your CI pipeline spends running tests is a minute you're not shipping. But the real cost isn't the clock time. It's the context switch.

Studies on developer productivity consistently show that interruptions destroy flow state. When you push a commit and the feedback takes 45 minutes, you've already moved on to another task. By the time the failure notification arrives, you've lost the mental context of what you were working on. Debugging becomes archaeology: you're digging through code you wrote an hour ago, trying to remember why you made that change to the auth handler.

Multiply this across a team of ten developers, each pushing three to five times a day, and you're looking at hours of accumulated lost productivity. Not because the tests are slow, but because the infrastructure running them wasn't built for this purpose.

This is what buyers on real sales calls describe when they say: "Our CI pipelines are taking 45 minutes and developers are just getting coffee."

What changes when tests run as Kubernetes jobs

TomTom's solution was to move testing out of the CI pipeline and into the Kubernetes cluster where the application actually runs. Iakym spearheaded the migration from standalone virtual machines to a cloud-based Kubernetes platform, with Testkube integrated across all four environments: development, testing, acceptance, and production.

The shift happened in phases. Functional tests (SOAP UI) moved first, covering authentication and authorization. Performance tests (JMeter) followed, handling load, stress, and soak testing. Then Selenium-based UI tests, built in Java with Maven, were integrated for automated browser validation.

The key difference: tests now execute as Kubernetes jobs inside the cluster, not as steps in a CI pipeline running on a separate machine. That means the test and the application share the same network, the same DNS, the same resource constraints. When a test fails, you know it failed because of your code, not because of a mismatch between the CI runner and the cluster.

TomTom initially triggered tests via Azure DevOps pipelines, and as they migrated to GitHub Actions, Testkube triggers moved with them. The test definitions didn't change. The execution context didn't change. Only the trigger did.

What developers actually get from this

Faster signal on what broke. When tests run inside the cluster, you eliminate the overhead of spinning up environments, configuring network access, and waiting for CI runners. TomTom integrated their test execution logs with a Prometheus stack, so engineers could trace issues from test execution directly to application logs. Troubleshooting time dropped because the debugging path went from "check the CI logs, then check the cluster logs, then check the app logs" to "check one place."

Tests that match production. The number one source of developer frustration with testing isn't slow tests. It's unreliable tests. Tests that pass locally, fail in CI, and then pass again when someone re-runs the pipeline. That unreliability almost always comes from environment mismatch. When tests run in the same cluster as the app, the mismatch disappears. You stop wasting time investigating failures that aren't real.

Use whatever tools you already know. TomTom runs SOAP UI, JMeter, and Selenium through the same orchestration layer. They didn't have to abandon their existing test suites or learn a new framework. Testkube is framework-agnostic: you bring the test, it handles the execution, scheduling, and results. If you write k6 scripts, those work too. If you prefer Cypress or Playwright, same story.

Trigger tests from wherever you work. Whether your team uses GitHub Actions, GitLab CI, Azure DevOps, or Argo CD, you can trigger Testkube test runs from any of them. TomTom migrated from Azure DevOps to GitHub Actions mid-adoption and the test layer came along without rewriting anything. Your tests shouldn't be locked to your CI provider.

The cost of not fixing this

TomTom's Iakym was direct about the alternative: without a Kubernetes-native test platform, they would have continued running tests on expensive, untracked virtual machines with manual triggers and no centralized visibility. The cost wasn't just infrastructure (three VMs with no version tracking). It was developer time spent waiting, debugging environment issues, and context-switching.

The company is now exploring Testkube's commercial version for advanced parallelization and execution optimization, and advocating for company-wide adoption beyond the B2C IAM team. That trajectory, from one team solving their own pain to an organization-wide standard, is common. It starts with a developer who's tired of waiting 45 minutes for feedback.

Where to start

If your CI pipeline is your test platform and feedback takes longer than it should, here's the shortest path to changing that.

Identify your slowest test suite. That's the one causing the most context switches and the most "I'll just re-run it" moments. For TomTom, the functional tests (SOAP UI) moved first because they were the clearest win.

Run that suite as a Kubernetes job. Not as a CI step. As a job inside your cluster, where it shares the network and resources with the application. If you're already on Kubernetes, this is a smaller change than it sounds.

Connect the trigger to your existing CI/CD. You don't have to rip out GitHub Actions or GitLab CI. You just stop asking them to run tests directly and instead have them trigger test execution inside the cluster. The pipeline still kicks things off. The cluster does the heavy lifting.

Look at the results in one place. TomTom integrated Testkube with Prometheus for monitoring and log aggregation. The goal is simple: when a test fails, you should know why within minutes, not hours. One dashboard for results and artifacts, not five tabs across different tools.

Stop waiting for your pipeline

Your CI pipeline was built to ship code, not to tell you whether your code works. Those are different jobs, and they deserve different tools.

TomTom moved testing out of VMs and into Kubernetes, kept their existing frameworks (SOAP UI, JMeter, Selenium), and gave developers a faster feedback loop without rebuilding their CI/CD from scratch. As Iakym put it: "You are the only Kubernetes-native testing platform. Especially with testing workflows. That's what I love."

Testkube runs tests as native Kubernetes jobs, supports any framework, and gives developers instant feedback where their code actually lives. Explore the architecture, start a Testkube trial, or trigger your first test from your CI/CD pipeline.