At Online TestConf, Liran Yushinsky shared how his team replaced brittle bash and kubectl tests with a unified Kotlin + Gauge framework. Using Fabric8, Terraform, and Ansible, they automated their test environments. Feedback loops dropped from hours to minutes, developers joined testing efforts, and shared ownership boosted quality and release speed.
Yushinsky mentioned that their testing landscape was fragmented, a mix of bash scripts, kubectl commands, and SSH-based checks for Kubernetes workloads. That made tests brittle and hard to maintain, he said.
Environments also drifted, tests would pass in one environment but fail in another, for example, staging versus QA test environment, Yushinsky said. Feedback loops were slow, running end-to-end checks could take hours. And since there wasn’t a unified framework, onboarding new team members was time-consuming, and flakiness was high, he added.
Yushinsky presented how they standardized their test environment:
We built a shared automation library in Kotlin using Gauge as the test runner. We replaced shell and
kubectlcommands with the Fabric8 Kubernetes client, which gave us more control and less flakiness.We also automated environment provisioning with Ansible and Terraform, so tests always run in reproducible conditions. In Jenkins, we wired up these tests to run automatically, with results posted to Slack and visualized in Grafana.
He mentioned that they also did internal coaching, lunch-and-learns, code reviews, and templates, to bring the whole company along.
They started with a pilot project on a non-critical service to prove the concept, and built a library of reusable steps so engineers wouldn’t have to reinvent the wheel, Yushinsky said. Next, they shared successes in internal demos, and gradually moved more services under the framework. They also automated the reporting so everyone could see test outcomes in real time on Slack and dashboards, which created trust in the system.
Yushinsky mentioned that people were used to their own scripts:
We overcame that by showing how much time was wasted on manual or flaky tests - some of our end-to-end checks used to take several hours and could block a deployment for half a day if they failed unpredictably - and how quickly the new approach caught regressions.
The learning curve for Kotlin and Gauge was steep, he said. They overcame that by providing templates, pairing on the first few test cases, and showing quick wins in CI:
You need to invest time in change management. Technology alone won’t make it succeed; you need to create visible wins, teach by example, and make it easy for others to contribute.
With the automation framework, the feedback loop has become much faster. They can run comprehensive end-to-end tests in minutes instead of hours, deployments are more reliable, and they are catching regressions earlier, Yushinsky said.
The readable scenarios turned tests into a shared asset, Yushinsky explained. Previously, only QA engineers touched them. With Gauge’s plain-language specs and Kotlin steps, developers now write and extend tests as part of their feature work, which is a big cultural change:
At first, some devs were skeptical about "owning tests," but once they saw how quick the framework was and how it helped them catch their own bugs before code review, they embraced it. New hires onboard faster because the step library doubles as living documentation. And with Slack alerts and Grafana dashboards we have full visibility into test health and trends.
Rolling out a new test framework is as much about people as it is about technology, Yushinsky said. Quick wins and incremental rollout build credibility, and shared ownership keeps the suite from becoming stale, he concluded.
InfoQ interviewed Liran Yushinsky about automated testing.
InfoQ: How did you involve people outside QA in the automated testing environment?
Liran Yushinsky: We invited developers, DevOps engineers, and even product owners to our lunch-and-learn sessions and internal demos. The goal was to show that these tests were not a "QA thing," but part of our shared delivery pipeline.
The sessions were well received because people could immediately see the pain points we were trying to solve - flaky tests, manual steps, long feedback loops. It also gave them a voice in shaping the framework.
InfoQ: What made you decide to use an automation framework?
Yushinsky: We wanted something readable by both QA and developers, but flexible enough to code serious tests. Gauge supports live documentation and tagging, integrates well with Kotlin, and can run in parallel, which solved our long execution times. Its reporting and plugin ecosystem also made it easy to hook into Jenkins, Pact, and Testcontainers, which we were already using.
Here is a snippet that illustrates how Gauge scenarios look next to Kotlin step definitions; a spec, a concept, and one matching step:
InfoQ: What were the challenges with flaky tests, and how did you deal with them?
Yushinsky: We built retry logic and used Testcontainers to isolate dependencies like K3s clusters, which cut those multi-hour runs down to tens of minutes and reduced random failures to rare edge cases. We also added pre-checks and upgrade-specific scenarios to catch version drift before it hit production, and we enforced naming and tagging conventions through code reviews to keep the suite maintainable.