Being able to define tests, run and monitor their execution through Testkube's integrated platform is a valuable proposition from the QA and Site Reliability point of view.
Testkube looks like a great alternative to more known approaches for test automation runs as it doesn’t require maintaining CI agents or configure complex CI
Table of Contents
Funxtion is a B2B SaaS Platform that helps gym operators with the challenging task of keeping their members engaged. Founded in 2011 by fitness industry experts Mendel Witzenhausen and Ernst de Neef, Funxtion is used by gyms, hotels, wellness apps, and corporate businesses around the world to customize and deliver the digital fitness content their members want to engage with. We work with major brands including Fitness First Germany, GoodLife Canada, PureGym UK, and Life Fitness Group Australia.
Currently, our Scrum team composition is our Product Owner, UI/UX Designer and a few Software Engineers, DevOps Engineers and QA Testers.
The Background
We first discovered Testkube when we started to look into more modern implementation approaches for our QA processes tailored to a Kubernetes environment, which was the new direction in which we were moving towards.
In this period, we were also starting to adopt a GitOps philosophy when it comes to implementing our infrastructure specifications, QA and release strategies. We found that Testkube and its Helm Chart project fit perfectly into our technology stack and vision.
The Challenge: From Monolith to a Microservices Architecture
In 2022, we were moving from a monolithic application architecture running on premise infrastructure towards a public cloud infrastructure running completely in Kubernetes with a microservices-based architecture.
Before working with Testkube, some of our QA testing processes were done within CI pipelines or arbitrary scripts run from multiple places. We lacked the ability to perform testing natively within our Kubernetes clusters in a unified manner. We were also relying sometimes on manual QA testing for those scenarios that were not fully automated yet. The reporting and notification from QA processes were quite scattered as well, as there were multiple places required to visit depending on the type of test executed.
With all that mentioned, we were looking into how we can integrate better all these testing elements into a unified platform.
The Solution: Testkube Adoption
We started using Testkube v1.6.72 around December 2022.
As mentioned, one of the motivating factors in adopting Testkube was the new architecture which we were starting to move towards.
In addition, we also wanted to implement our QA processes in a way that was friendlier to a Kubernetes-native environment and to allow our QA engineers to work in what they do best: testing. This saves them from being too caught up in infrastructure or Kubernetes aspects.
Another factor for its adoption was the willingness of the team to adopt something new which leverages automation, modern best practices, and the fact that the project is open source with a high frequency of contributions together with the awesome release notes done regularly.
Our starting point with Testkube was to automate our API load tests (making use of the k6 executor) to make sure that when making new releases we guarantee API performance metrics to be under specific threshold values. After that, we started to move our End-to-End tests into the cluster to fully exploit Testkube capabilities.
The Impact
By adopting Testkube we acquired some of the following benefits:
• We now have a centralized place for reporting and logging natively run tests that are triggered automatically by Kubernetes deployments or any other arbitrary criteria.
• We decoupled some QA testing processes from CI pipelines since now we can run things natively within K8s clusters.
• We can define which QA tests to run in different environments in a declarative fashion following a GitOps philosophy.
• API load testing is automated on deployment and visualization of results are displayed in a Grafana Dashboard, so we have a better assessment of performance aspects.
• Get slack notifications when API tests break quality API metrics when doing new releases.
As a result, we do not have to keep track anymore on manual execution of performance tests by a few engineers with required setup and knowledge. Instead, now the process is fully automated without extra costs on hardware and external systems. Now, we utilize the existing Kubernetes infrastructure to run tests inside the cluster when needed.
We also have more confidence in test results as they are running inside the development cluster, so there are no latency delays or network issues shown in the final test report.
In summary, adopting Testkube allows us to leverage QA automation a bit more, be more agile and speed up the QA feedback-loop, which results in higher team productivity and delivered product quality
The Future
In the future, we will keep expanding with more native testing and potentially make use of other Testkube executors.
Another interesting area that we believe will exploit more is Real-Time testing visibility. As our systems grow, we will increase the number of tests that will be running periodically or on demand for some user flows or system-to-system interactions.
We think that being able to define these tests, run and monitor execution in an integrated platform is a valuable proposition from the QA and Site Reliability point of view.
About Testkube
Testkube is a test execution and orchestration framework for Kubernetes that works with any CI/CD system and testing tool you need, empowering teams to deliver on the promise of agile, efficient, and comprehensive testing programs by leveraging all the capabilities of K8s to eliminate CI/CD bottlenecks, perfecting your testing workflow. Get started with Testkube's free trial today!