Helm is one tool that has established itself as the de facto standard for Kubernetes application packaging and deployment. Still, organizations have yet to fully capitalize on Helm’s potential for standardizing and automating testing procedures.

In this blog post, we’ll examine integrating Testkube with Helm to create a unified approach to application development and quality assurance.

Understanding Helm

As the official “package manager for Kubernetes,” Helm enables developers to define, install, and upgrade applications through charts-packaged collections of pre-configured Kubernetes resources. These charts are templates customized through values files, allowing you to configure environment variables while maintaining consistency.

By abstracting away the complexity of raw Kubernetes yaml files, Helm allows teams to manage the application lifecycle more efficiently, track version history, and roll back to previous versions when necessary. This has allowed teams to create standardized deployments across multiple environments.

Testing your Helm Deployments

While Helm’s capabilities for application packaging and deployment are widely recognized, its testing potential remains largely unexplored. Implementing a robust testing approach for your Helm-deployed applications ensures they work as intended before promotion to production environments. Helm allows you to use the same templating, versioning, and dependency management features to create consistent, reproducible testing environments. This allows teams to treat tests as first-class citizens in their cloud native environment.

• Consistency across environments: Helm allows test configurations to be templated and parametrized, like application charts, ensuring tests run identically across development, staging, and production environments.
• Version Control for Test Configurations: It allows you to track changes to test setups over time with the same versioning as application deployments.
• Simplified Rollbacks: When new approaches prove problematic, you can easily revert to previous test configurations, maintaining testing integrity alongside application versioning.
• Integration with CI/CD Pipelines: Leverage existing Helm-based workflows to incorporate automated testing as part of the deployment process

What is Testkube?

While Helm provides an excellent foundation for packaging and potentially managing tests, Testkube elevates cloud native testing by offering a dedicated, cloud native test execution framework. Building upon the packaging and versioning capabilities discussed in the previous section, Testkube takes a specialized approach to testing that complements Helm’s strengths by offering:

• Kubernetes-Native Testing Architecture: Testkube runs tests directly in your cluster, leveraging the same infrastructure used for your applications. This ensures that tests accurately reflect real-world conditions.
• Multi-Framework Support: It seamlessly integrates with popular testing frameworks like Postman, K6, Cypress, and JMeter, providing flexibility without requiring complex configuration.
• Declarative Test Management: Define tests as Kubernetes custom resources that can be version-controlled alongside Helm charts, creating a unified approach to both application deployment and testing.

By integrating Testkube with Helm, teams can create a powerful synergy that addresses application packaging and testing needs within Kubernetes environments. By combining Helm’s robust templating and versioning capabilities with Testkube’s specialized testing framework, organizations can establish a unified approach to cloud-native deployment and quality assurance.

Integrating Testkube With Helm

To better understand the synergies, we’ll do a hands-on demo of integrating Testkube with Helm. We’ll use the online boutique microservices application. Create a k6 Test Workflow that will validate one service of the application. We’ll use Helm to deploy the application to the cluster and execute the k6 Test Workflow to validate our application.

The application is deployed in the default namespace, and Testkube is installed in its own testkube namespace. We have configured the Testkube agent to execute Test Workflows using a different namespace.

Prerequisites

• Kubernetes cluster — For this demo, we’ll be using a local Minikube cluster, but any Kubernetes cluster will work.
• Helm — Installed and configured on your local machine with access to your cluster.
• Testkube account — Sign up for a Testkube account to access the testing platform.
• Testkube agent — Properly configured and running on your Kubernetes cluster.
• Testkube credentials — Have your API Token, Organization ID, and Environment ID ready for configuration.
• kubectl — Configured with access to your Kubernetes cluster for verification and troubleshooting

To create the API token, refer to our API Token document. To find the Org ID and environment IDs, go to your Testkube Dashboard and click Settings from the menu bar.

Once you meet the prerequisites, you can start a target Kubernetes cluster using a Testkube agent setup. You also need to clone the online boutique microservices application as we need to add a Test Workflow to the helm charts.

Creating k6 Test Workflow

The Online boutique microservices application has many microservices, but we’ll focus on the ‘frontend’ service, which is responsible for the application’s front end. The k6 Test Workflow that we’ll create will validate the homepage and loading of the frontend service. You can refer to our guide on creating a Test Workflow to create a Test Workflow.

This K6 Test Workflow checks the frontend service’s status to HTTP 200. The response time is under 1000ms, and the body contains the text “online boutique.”

Once the Test Workflow is created, you can add it to Testkube through the dashboard and click on the Create button to save it, or you can use the Testkube CLI to create a Test Workflow.

Creating a Helm Test

After you’ve created the k6 Test Workflow, the next step is to create a helm test. To do that, you must create a new folder called tests inside the templates folder and add a test.yaml — /helm-charts/templates/tests/test.yaml.

apiVersion: batch/v1 kind: Job metadata: name: " {{ .Release.Name }} -testkube-test" annotations: "helm.sh/hook": test spec: template: spec: containers: - name: testkube-runner image: kubeshop/testkube-cli:latest env: - name: TESTKUBE_API_KEY valueFrom: secretKeyRef: name: testkube-credentials key: apiKey - name: TESTKUBE_ROOT_DOMAIN valueFrom: secretKeyRef: name: testkube-credentials key: rootDomain - name: TESTKUBE_ORG_ID valueFrom: secretKeyRef: name: testkube-credentials key: orgId - name: TESTKUBE_ENV_ID valueFrom: secretKeyRef: name: testkube-credentials key: envId command: [ "/bin/sh" , "-c" ] args: - | echo "Starting test job..." # Set up Testkube context with authentication echo "Setting up Testkube context..." testkube set context \ --api-key "$TESTKUBE_API_KEY" \ --root-domain "$TESTKUBE_ROOT_DOMAIN" \ --org-id "$TESTKUBE_ORG_ID" \ --env-id "$TESTKUBE_ENV_ID" # Get frontend service URL FRONTEND_URL="http://frontend.{{ .Release.Namespace }}.svc.cluster.local:80" echo "Target frontend URL: $FRONTEND_URL" # Run the testworkflow echo "Running testworkflow online-boutique-service..." testkube run testworkflow online-boutique-service --config appUrl=$FRONTEND_URL # Save the result RESULT=$? echo "Result code: $RESULT" if [ $RESULT -eq 0 ]; then echo "Test passed!" exit 0 else echo "Test failed with status code: $RESULT" exit 1 fi restartPolicy: Never backoffLimit: 0

The above file:

• Creates a Kubernetes job that we can execute using helm test command.
• Add a helm.sh/hook: test annotation, which is mandatory to execute the helm test.
• Add secrets for Testkube tokens and IDs to set the Testkube context.
• We’ll use the Testkube CLI to execute the online-boutique-service Test Workflow.
• Save the result and share the output based on the result.

Deploying and Testing the App

Now that the file is created and saved, you can install the Online Boutique Microservices application.

You can validate the application by navigating to the URL of the frontend or frontend-external service.

You can execute the test using the helm test command.

helm test online-boutique NAME: online-boutique LAST DEPLOYED: Thu Mar 13 11:43:07 2025 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: online-boutique-testkube-test Last Started: Thu Mar 13 12:38:11 2025 Last Completed: Thu Mar 13 12:38:24 2025 Phase: Succeeded NOTES: Note: It may take a few minutes for the LoadBalancer IP to be available.‍ Watch the status of the frontend IP address with: kubectl get --namespace default svc -w frontend-external‍ Get the external IP address of the frontend: export SERVICE_IP=$(kubectl get svc --namespace default frontend-external --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo http://$SERVICE_IP

While the test executes, you can use the kubectl logs command to check the status of the job.

kubectl logs job/online-boutique-testkube-test Starting test job... Setting up Testkube context... Your config was updated with new values 🥇‍ Your current context is set to cloud‍ Organization : Atulpriya Sharma-personal-org (tkcorg_f512345678905) Environment	: local-minikube (tkcenv_c61234567890) API Key : tk*********************************45 API URI : https://api.testkube.io Namespace :‍ Target frontend URL: http://frontend.default.svc.cluster.local:80 Running testworkflow online-boutique-service...‍ Context: cloud (2.1.113) Namespace:	Org: Atulpriya Sharma-personal-org Env: local-minikube -------------------------------------------------------------------------------------------------‍ Test Workflow Execution: Name: online-boutique-service Execution ID: 67d284658a39eb7e9328700c Execution name: online-boutique-service-20 Execution namespace: Execution number: 20 Requested at: 2025-03-13 07:08:20.623179958 +0000 UTC Disabled webhooks:	false Running context: Interface: Type: cli Actor: Name: noreply@testkube.io Email: noreply@testkube.io Type: user Status: queued‍ $ Watch test workflow execution until complete \ kubectl testkube watch twe 67d284658a39eb7e9328700c $ Use following command to get test workflow execution details \ kubectl testkube get twe 67d284658a39eb7e9328700c Result code: 0 Test passed!

You can validate this by visiting the Testkube dashboard and checking the status of the Test Workflow.

With Testkube and Helm successfully integrated, you now have a powerful framework for cloud native testing that leverages the best of both technologies. This approach streamlines your testing process and ensures consistency and reliability across your deployment pipeline.

Get Started with Testkube and Helm

In this post, we saw how this combination leverages Helm’s powerful packaging and templating capabilities alongside Testkube’s testing framework to create a comprehensive solution for quality assurance in Kubernetes environments.

For architects and technical decision-makers, this integration streamlines workflows by treating both application deployment and testing as version-controlled, declarative resources within the same ecosystem. By adopting this approach, organizations can achieve greater consistency across environments, faster feedback cycles, and improved confidence in their cloud-native applications.

Get started today and discover how Testkube can transform your testing strategy. You can also join our Slack community to start a conversation or read Testkube documentation to see how Testkube can enhance your testing workflow, ensuring seamless, efficient, and automated testing within the Kubernetes environments.‍

Originally published at https://testkube.io.

Testkube with Helm for Easier Test Management | Learn was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Simply put: you can’t test Kubernetes-native apps with yesterday’s tools. Legacy testing approaches struggle to keep up with the CI/CD pipelines, pull requests, and dynamic production environments that define Kubernetes. Today, testing must be continuous, automated, and built into your development and testing workflows from the start.

In this article, we’ll explore the testing challenges Kubernetes presents, how traditional methods fall short, and how tools like Testkube are helping teams embrace a new, more effective approach.

The New Challenges of Testing in Kubernetes

Deploying software in a Kubernetes cluster is radically different from a traditional monolith on a static server. With containers spinning up and shutting down constantly, maintaining stability and visibility during a test run can feel impossible without the right tooling.

Here are some of the most common issues that developers and testers face:

• Ephemeral test environments: A test environment in Kubernetes might only exist for a few minutes. That makes manual setup unreliable and unsustainable. Testing tools must work seamlessly with these short-lived environments.
• Service dependencies: You often can’t test one microservice in isolation. You might need to spin up other services to support a single test case.
• CI/CD integration complexity: In a pipeline that deploys multiple times per day, your testing process must be automated and trigger reliably with each pull request.
• Observability gaps: Distributed systems often lack the centralized logs and metrics needed to debug failures quickly.
• Resource management: A poorly tuned performance testing job can monopolize resources and bring down other workloads.

These challenges are exactly why more teams are investing in Kubernetes-native testing tools that can integrate tightly with their CI/CD pipelines and scale as their infrastructure grows.

Why Legacy Testing Tools Fall Behind

Traditional testing platforms were never designed for dynamic, container-based environments. They often rely on static assumptions-like long-lived VMs, fixed IP addresses, and human-triggered test runs.

Some common pitfalls include:

• No cluster awareness: Legacy tools don’t know how to detect or respond to changes in your Kubernetes cluster.
• High setup overhead: Installing agents or configuring environments manually defeats the purpose of fast-moving DevOps workflows.
• Limited CI/CD compatibility: Integrating these tools into modern pipelines often requires complex workarounds.
• Poor observability: With no access to real-time logs or metrics, understanding test failures becomes guesswork.

Modern testing needs to be automated, observable, and Kubernetes-aware. And that’s where Kubernetes-native platforms like Testkube come in.

What Is Kubernetes-Native Testing?

Infographic highlighting key benefits of Kubernetes-native testing: environment parity, test orchestration, CI/CD integration, and observability.

Kubernetes-native testing means running and orchestrating your software tests directly inside your cluster. It involves using Kubernetes resources like Jobs, Pods, and CRDs to run and manage your test cases.

It also means that your tests live as part of your infrastructure-they can scale, fail, restart, and be versioned just like any other part of your application.

Benefits of Kubernetes-Native Testing

• Environment parity: Run your unit tests, integration tests, and performance tests in the same cluster where your app lives.
• Orchestration and automation: Schedule, version, and monitor tests as Kubernetes-native workloads.
• CI/CD compatibility: Tests are easily integrated into your pipelines, ensuring every pull request is validated before merging.
• Observability: Collect real-time logs, test history, and performance metrics for debugging and optimization.

Explore more about Kubernetes-native testing.

Introducing Testkube: Testing Designed for Kubernetes

Testkube is a testing framework purpose-built for Kubernetes. It runs your existing testing tools (Postman, JMeter, k6, Cypress, and more) as native Kubernetes workloads-no special setup needed.

Testkube integrates directly with your CI/CD pipelines, GitOps tools, and development workflow to support all types of tests: from unit to integration to load testing.

• Explore supported test types
• Learn about test execution options
• Set up GitOps-based test management

What can you do with Testkube?

• Run test jobs as native Kubernetes resources
• Manage test definitions and configs in Git
• Trigger tests via API, CLI, UI, or GitOps events
• View detailed logs and test results in a centralized dashboard

Real-World Testing Scenarios in Kubernetes

Here are a few ways teams are using Testkube to modernize their testing:

• Post-deployment smoke tests: Run quick UI or API tests after a Helm or ArgoCD rollout.
• Isolated integration tests: Use to spin up dedicated test environments per pull request.
• Shift-left testing: Run critical test suites before merging changes to catch bugs early in the CI/CD pipeline.
• In-cluster performance testing: Launch distributed load tests from inside the Kubernetes cluster for realistic performance insights.

Best Practices for Kubernetes Testing

To get the most from your testing workflows in Kubernetes:

• Automate as much as possible, as early as possible
• Keep test environments as close to production as you can
• Use GitOps to manage and version your tests
• Embed testing into your CI/CD pipelines and track failures over time

Check out our full CI integration guide and test metrics dashboard to level up your approach.

The Future of Software Testing Is Kubernetes-Native

As more organizations move to microservices and Kubernetes-based delivery, the demand for scalable, flexible, and fast testing workflows will only grow.

Kubernetes-native testing is not just a nice-to-have-it’s quickly becoming the new standard.

With tools like Testkube, you can reduce the time to release, boost developer productivity, and improve test coverage across every stage of development.

Get started with Testkube at https://testkube.io/get-started‍

Originally published at https://testkube.io.

Kubernetes + Software Testing was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the modern software development landscape, delivering high-quality web applications rapidly is paramount. Continuous integration and continuous deployment (CI/CD) practices demand automated testing to ensure functionality, prevent regressions, and maintain user satisfaction across a multitude of browsers and platforms. Selenium has emerged as the de facto open-source standard for web browser automation, providing a comprehensive suite of tools to meet these critical testing needs. This report delves into the world of Selenium, exploring its core concepts, history, components, and the evolution towards scalable test execution, culminating in how Testkube revolutionizes Selenium testing within Kubernetes environments.

What is Selenium?

Selenium is not a single tool but rather an umbrella project encompassing a range of libraries and tools designed specifically for automating web browser interactions. It empowers developers and quality assurance (QA) professionals to write scripts that simulate user actions, such as clicking links, filling forms, and validating content, across various web browsers. A key strength of Selenium is its flexibility; it supports numerous popular programming languages for writing test scripts, including Java, Python, C#, JavaScript, Ruby, and more. Furthermore, Selenium tests can be executed across different operating systems like Windows, macOS, and Linux. Being open-source under the Apache 2.0 license, Selenium is free to use and benefits from a large, active community that contributes to its development and provides support. This combination of cross-language, cross-browser, and cross-platform compatibility, coupled with its open-source nature, has made Selenium a cornerstone of web application testing strategies for organizations worldwide.

The structure of Selenium as a suite, rather than a monolithic application, reflects its evolutionary development. Different components emerged over time to address specific requirements or overcome limitations encountered with earlier iterations. For instance, technical constraints like the browser’s “Same Origin Policy” influenced the development of certain components, while the desire for more direct and stable browser control led to significant architectural shifts. The open-source model facilitated contributions from various individuals and organizations, each tackling specific problems, resulting in the versatile, albeit sometimes complex, suite of tools available today.

Importance of Testing in Selenium

Automated web testing is indispensable in modern software development for several fundamental reasons. It verifies that web applications function as intended, ensuring a positive user experience and maintaining brand reputation. Automation significantly reduces the manual effort required for repetitive testing tasks, freeing up human testers to focus on more complex exploratory testing or usability assessments. Crucially, automated tests act as a safety net, catching regressions — defects introduced in previously working parts of the application — early in the development cycle. This early detection drastically reduces the cost and effort required for fixes and enables faster, more confident release cycles. Common types of testing facilitated by automation include functional testing (verifying features work correctly) , regression testing , cross-browser testing (ensuring compatibility across different browsers like Chrome, Firefox, Safari, Edge), and user experience testing (simulating user flows).

Selenium plays a pivotal role in achieving these testing goals. It allows testers to write scripts that programmatically mimic user interactions with web elements. One of its most powerful features is the ability to run tests in parallel using Selenium Grid, which dramatically speeds up the execution of large test suites. Selenium tests are designed to be reusable, saving time and effort in script creation and maintenance across different test cases or projects. Furthermore, Selenium integrates seamlessly with CI/CD pipelines (using tools like Jenkins, GitLab CI, GitHub Actions) , allowing tests to be automatically triggered upon code changes. This integration provides rapid feedback to developers, ensuring that quality checks are an inherent part of the development process.

The capabilities of Selenium make it far more than just a tool for clicking buttons; it is a critical component supporting modern software development methodologies like Agile and DevOps. These methodologies emphasize rapid iterations, continuous feedback, and reliable deployments. Selenium’s ability to provide fast, automated validation of application quality and its tight integration into CI/CD workflows make it fundamental for implementing automated quality gates. Without robust automation tools like Selenium, achieving the speed and reliability demanded by Agile and DevOps would be significantly more challenging.

History of Selenium

Selenium’s journey began in 2004 at ThoughtWorks in Chicago. Jason Huggins, an engineer working on an internal time and expenses application, grew frustrated with repetitive manual testing. He created a JavaScript-based tool, initially called “JavaScriptTestRunner,” to automate browser interactions for this application. The name “Selenium” reportedly originated from a joke Huggins made, suggesting it as an antidote to Mercury poisoning, mocking a competitor product, Mercury Interactive’s QuickTest Professional. This initial tool, later open-sourced and renamed Selenium Core, showed promise but faced a significant limitation: the browser’s “Same Origin Policy,” which prevented JavaScript from controlling a browser if the script originated from a different domain than the application under test.

To overcome this hurdle, another ThoughtWorks engineer, Paul Hammant, conceived Selenium Remote Control (RC), also known as Selenium 1. Selenium RC introduced a server that acted as an HTTP proxy. Test scripts, now writeable in various programming languages, sent commands to the RC server, which then injected Selenium Core (the JavaScript program) into the browser, bypassing the Same Origin Policy restrictions. Around the same time (2006), Shinya Kasatani in Japan developed Selenium IDE as a Firefox browser extension. IDE provided a simple record-and-playback interface, making it easier for beginners to create basic tests without extensive programming knowledge. After a period of inactivity, Selenium IDE was revived and updated in 2018, adding support for Chrome.

A major architectural shift occurred around 2006–2009 with the creation of WebDriver by Simon Stewart (then at Google). Unlike RC’s reliance on JavaScript injection, WebDriver aimed for more direct and stable control by using the native automation APIs provided by each browser vendor. This approach promised faster execution and more reliable interactions. Recognizing the advantages of WebDriver, the Selenium project decided to merge it with Selenium RC. This merger resulted in Selenium 2, released in 2011, with WebDriver becoming the new core API.

Further refinement came with Selenium 3 in 2016. A landmark development was the standardization effort culminating in the W3C WebDriver Protocol, which became the standard in Selenium 4. This protocol defined a common language for communication between the client libraries (test scripts) and the browser-specific drivers, ensuring greater consistency and compatibility across different browsers.Concurrently, to address the need for running tests at scale, Patrick Lightbody developed Selenium Grid, enabling parallel test execution across multiple machines and browsers.

This historical progression reveals that Selenium wasn’t conceived with a single, fixed design. Instead, it evolved iteratively, driven by the need to overcome specific technical obstacles like the Same Origin Policy or the limitations of JavaScript injection. Each major component represented an attempt to improve upon its predecessors, aiming for greater speed, stability, cross-browser compatibility, and eventually, standardization through the W3C protocol. This journey from an internal script to a globally recognized standard reflects both the ingenuity of its contributors and the growing importance of robust web automation.

Types of Selenium Testing (Components)

As established, Selenium is a suite comprising several distinct components, each serving a specific purpose within the web automation landscape. Understanding these components is crucial for selecting the right tools for a given testing task.

Selenium IDE

Selenium Integrated Development Environment (IDE) is implemented as a browser extension, available for both Chrome and Firefox. Its primary function is to record user interactions within the browser — clicks, typing, selections — and translate them into Selenium commands, which can then be replayed as automated tests. It offers a relatively simple graphical user interface and includes basic debugging features.

Selenium IDE serves as an excellent starting point for individuals new to Selenium, allowing them to quickly create simple test cases and learn the basic Selenese command syntax without needing deep programming knowledge. It can also be useful for rapid prototyping of test ideas.

However, Selenium IDE has significant limitations that make it unsuitable for building comprehensive, maintainable test suites. It struggles to handle dynamic web elements (elements whose attributes change on page load), lacks robust support for complex logic like loops or conditional statements, and cannot easily perform data-driven testing (running the same test with multiple data sets). Furthermore, it offers limited error handling capabilities, cannot interact with databases or non-web elements, and lacks built-in features for generating detailed test reports. Because record-and-playback tests are inherently brittle and tend to break easily with minor UI changes, IDE is generally not recommended for serious, large-scale regression testing. While a valuable introductory tool, its constraints prevent it from being a scalable solution for the complexities of real-world web application testing.

Selenium RC (Remote Control)

Selenium RC (Remote Control) holds a significant place in Selenium’s history as the tool that first enabled cross-language and broader cross-browser testing.Architecturally, it consisted of a server (typically written in Java) that acted as an HTTP proxy between the test script and the browser. When a test script (written in languages like Java, C#, Python, etc.) sent a command, the RC server intercepted it and injected a JavaScript program, known as Selenium Core, into the target browser. This injected JavaScript then executed the command within the browser’s context.

Despite its historical importance, Selenium RC is now officially deprecated and has been superseded by Selenium WebDriver. Several factors led to its deprecation. The reliance on JavaScript injection and the proxy server introduced latency, making RC significantly slower than WebDriver. Its API was considered more complex and sometimes contained redundant commands compared to WebDriver’s cleaner, object-oriented interface. RC also faced limitations in interacting with modern browser features and had no native support for headless browser testing. Fundamentally, the indirect method of controlling the browser via JavaScript injection proved less stable and reliable than WebDriver’s approach of using native browser automation APIs.

Selenium RC was a vital evolutionary step, successfully addressing the limitations of Selenium Core and paving the way for multi-language test automation. However, its architectural design, while clever for its time, ultimately presented performance and reliability challenges that were better solved by the direct control model introduced by Selenium WebDriver.

Selenium WebDriver

Selenium WebDriver is the modern core and the de facto standard within the Selenium suite It provides a well-defined, object-oriented programming interface (API) that allows test scripts to interact directly and programmatically with web browsers. Unlike Selenium RC, WebDriver does not rely on injecting JavaScript into the browser for every command. 16

The architecture of Selenium WebDriver facilitates this direct communication through several key components:

1. Selenium Client Libraries (Language Bindings): These are the language-specific libraries (e.g., selenium-java, selenium-python, selenium-dotnet) that testers use to write their automation scripts. They provide the classes and methods representing WebDriver commands.
2. W3C WebDriver Protocol: Since Selenium 4, communication between the client libraries and the browser drivers adheres to the official W3C WebDriver standard. This protocol defines a standardized way to represent browser automation commands and their responses, typically using JSON format transmitted over HTTP. This standardization ensures consistency across different browsers and drivers. It replaced the older, non-standard JSON Wire Protocol used in Selenium 3.
3. Browser Drivers: These are intermediary executable servers, developed and maintained by the browser vendors themselves (e.g., ChromeDriver for Google Chrome, GeckoDriver for Mozilla Firefox, EdgeDriver for Microsoft Edge). Each driver acts as a bridge, receiving the standardized W3C protocol commands from the client library and translating them into browser-specific, native automation calls that the browser understands.
4. Browsers: These are the actual web browser applications (Chrome, Firefox, Edge, Safari, etc.) being automated by the WebDriver scripts.

This architecture offers significant advantages over Selenium RC. The direct communication path, bypassing the JavaScript injection layer, results in considerably faster test execution and increased reliability. WebDriver provides a more accurate simulation of real user interactions by leveraging native browser events. Its architecture is simpler for basic test execution, as it doesn’t require a separate intermediary server like Selenium RC running constantly. WebDriver also readily supports modern browser capabilities and headless execution (running tests without a visible browser UI), either through specific drivers like HtmlUnit or by utilizing the built-in headless modes of browsers like Chrome and Firefox.

The development of WebDriver marked a crucial advancement in browser automation technology. Its shift towards direct browser control via vendor-supplied drivers addressed the inherent speed and stability issues of the proxy-based JavaScript injection method used by RC. The subsequent adoption and standardization through the W3C protocol further solidified WebDriver’s position, promoting consistency and reducing the flakiness often associated with cross-browser testing in earlier automation tools. This robust, standardized approach is what makes WebDriver the powerful and widely adopted core of Selenium today.

Selenium Grid

While WebDriver provides the mechanism for controlling a single browser instance, Selenium Grid is the component designed specifically to address the challenge of scaling test execution. Its primary purpose is to enable the parallel execution of WebDriver tests across multiple machines, operating systems, and browser types simultaneously.

The core benefit of using Selenium Grid is a significant reduction in the total time required to run comprehensive test suites. Instead of running tests one after another, Grid allows distributing them across numerous environments, executing them concurrently. This is particularly crucial for large regression suites or extensive cross-browser and cross-platform testing scenarios, where sequential execution would be prohibitively time-consuming.

The traditional architecture of Selenium Grid follows a Hub-and-Node model:

• Hub: This acts as the central coordinator and entry point for the Grid. WebDriver test scripts connect to the Hub, specifying their desired capabilities (e.g., “Chrome browser on Linux,” “Firefox version X on Windows”). The Hub maintains a registry of available Nodes and their capabilities. It receives test commands from the client script and intelligently routes them to a suitable, available Node that matches the requested capabilities.
• Nodes: These are the individual machines (physical or virtual) where the actual browser automation occurs. Each Node runs one or more WebDriver browser driver instances. Nodes register themselves with the Hub, advertising the browser types, versions, and operating systems they can support. When the Hub assigns a test session, the Node receives the WebDriver commands, executes them against its local browser instance, and sends the results back to the Hub.

Selenium Grid 4 introduced enhancements to this architecture, particularly for better operation in containerized and distributed environments like Kubernetes. It features a more decomposed structure with components like a Router (entry point), Distributor (manages nodes and session queue), Session Map (tracks active sessions), New Session Queue (holds pending requests), and an Event Bus (for internal communication), aiming for improved scalability, observability, and resilience.

Selenium Grid effectively solves the problem of parallel test execution, which is essential for timely feedback in CI/CD pipelines. However, setting up and managing the Grid infrastructure itself — the Hub and numerous Nodes, along with their browser and driver dependencies — introduces significant operational overhead. While Grid 4’s architecture offers improvements for distributed environments, the fundamental requirement to manage this separate testing infrastructure persists. This management burden becomes particularly acute in dynamic, automated environments like Kubernetes, representing a key challenge that newer, Kubernetes-native approaches aim to address.

Table: Selenium Components Overview

The following table provides a concise comparison of the primary components within the Selenium suite:

Chart of Selenium Components

This overview highlights the distinct roles and architectural approaches of each component, clarifying their current relevance in modern test automation strategies. WebDriver forms the foundation for test script logic, while Grid provides the mechanism for scaling execution. IDE remains a useful entry point, and RC is primarily of historical interest.

Automate Selenium Testing using Kubernetes

As software applications grow in complexity and test suites expand, running automated tests sequentially becomes a significant bottleneck in the development pipeline. Parallel execution is essential to obtain timely feedback. Selenium Grid is the standard solution within the Selenium ecosystem for achieving this parallelization. Concurrently, Kubernetes has become the dominant platform for deploying, scaling, and managing containerized applications in modern cloud-native architectures.It’s therefore natural for development and operations teams to seek ways to run their testing infrastructure, including Selenium Grid, within the same Kubernetes environment where their applications reside. This consolidation promises unified management and potentially better resource utilization.

However, deploying and managing a traditional Selenium Grid setup on Kubernetes presents numerous challenges:

• Setup and Configuration Complexity: Getting Grid running smoothly in Kubernetes is often non-trivial. It typically involves using specific Helm charts or crafting custom deployment configurations for the Hub and Node pods. Configuring Kubernetes networking (Services, Ingress) correctly to allow communication between the test runner, Hub, and Nodes can be intricate. Ensuring Nodes reliably register with the Hub is a common pain point.
• Resource Management: Each browser instance running within a Node pod consumes significant CPU and memory resources. Managing these resources efficiently across potentially dozens or hundreds of browser pods is difficult. Inadequate resource allocation can lead to pod crashes and test failures, while over-provisioning wastes resources. The Selenium Hub itself can become a performance bottleneck under heavy load.
• Scalability and Reliability: Vanilla Selenium Grid does not integrate seamlessly with Kubernetes’ native Horizontal Pod Autoscaler (HPA). Effectively scaling the number of Node pods based on the actual test queue depth often requires integrating third-party tools like KEDA (Kubernetes Event-driven Autoscaling) or implementing complex custom scaling logic. Furthermore, Grid’s architecture struggles with the ephemeral nature of Kubernetes pods, especially when using cost-effective spot instances. When a Node pod running on a spot instance is preempted and terminated, any test running on it abruptly fails, impacting test suite reliability. Implementing robust self-healing mechanisms to automatically replace failed nodes often involves custom scripting that can feel brittle or “hacky”.
• Maintenance Overhead: A Kubernetes-based Grid requires ongoing maintenance. Browser versions, WebDriver executables, and Selenium Grid components need to be kept up-to-date across all Node configurations. Managing custom Docker images for Nodes, perhaps to include specific dependencies like SSL certificates, adds another layer of complexity. Dealing with “stale” or unresponsive nodes is a frequent operational task.

These inherent difficulties stem from attempting to overlay Selenium Grid’s traditional, relatively stateful architecture (with a central Hub managing Node registration) onto Kubernetes’ dynamic, often ephemeral, and predominantly stateless-oriented environment. Kubernetes excels at managing container lifecycles, scaling based on metrics, and handling network routing through its own primitives (Deployments, Services, HPA, etc.). Grid has its own internal logic for managing sessions and nodes. This impedance mismatch creates friction, requiring significant operational expertise and often custom tooling (like KEDA for scaling) to bridge the gap effectively. The considerable effort required to maintain a reliable and scalable Grid on Kubernetes often detracts from the core goal of efficiently testing applications. These challenges have spurred the development of alternative solutions like Selenoid, Zalenium, and various commercial cloud testing platforms, which aim to simplify browser automation infrastructure, though often still requiring management of a dedicated testing setup.

Using Testkube to bring Selenium Tests into the Existing Kubernetes infrastructure

Testkube represents a paradigm shift away from running Selenium Grid on Kubernetes towards running Selenium tests natively within Kubernetes. It is designed from the ground up as a Kubernetes-native test orchestration and execution framework. Instead of deploying and managing a separate, persistent Selenium Grid infrastructure (Hub and Nodes), Testkube orchestrates test execution directly using Kubernetes resources.

At its core, Testkube defines tests and test suites using Kubernetes Custom Resource Definitions (CRDs). When a test needs to run, Testkube’s control plane instructs its agent running within the cluster to launch the test execution. This execution happens within dedicated Kubernetes pods, typically managed as Kubernetes Jobs. Testkube utilizes ‘Executors,’ which are specialized container images designed to run specific types of tests. For Selenium tests, a Selenium-compatible executor would be used to run the WebDriver scripts. Testkube handles the lifecycle of these test execution pods, leveraging Kubernetes’ native scheduling, resource management, and isolation capabilities.

Crucially, this model eliminates the need for the intermediate Selenium Grid layer. There is no Hub to manage, and no pool of persistent Nodes to maintain. Testkube dynamically provisions the necessary resources (pods, potentially including browser containers managed as services) for each test execution on demand and tears them down afterward, integrating seamlessly with the Kubernetes environment. Furthermore, Testkube is vendor-agnostic, capable of executing tests from a wide variety of popular frameworks (like Postman, Cypress, k6, JMeter, Playwright, and Selenium) using the same underlying Kubernetes-native orchestration mechanism. Complex testing scenarios involving multiple steps, dependencies (like databases or other services), parallel execution, and setup/teardown procedures can be defined using Testkube’s Test Workflows feature.

By treating tests as first-class Kubernetes resources and leveraging the platform’s inherent capabilities for orchestration and execution, Testkube fundamentally simplifies the process of running Selenium tests at scale within a Kubernetes environment. It removes the operational burden associated with managing a separate, complex Grid infrastructure, allowing teams to focus on writing effective tests.

Benefits to automating Selenium using Kubernetes (with Testkube)

Adopting Testkube for running Selenium tests within an existing Kubernetes cluster offers several significant advantages over traditional Selenium Grid setups or external cloud testing platforms:

• Resource Consolidation & Cost Savings: Testkube leverages the compute and network resources already available within your existing Kubernetes cluster — the same infrastructure used to run your applications. This eliminates the need to provision, manage, and pay for a separate, dedicated infrastructure solely for Selenium Grid, whether that involves dedicated VMs or reserving specific nodes within the cluster. By running tests on demand using Kubernetes Jobs, Testkube ensures resources are consumed only when needed, improving overall cluster utilization and potentially leading to substantial cost savings compared to maintaining an always-on Grid or using pay-per-minute external testing clouds.
• On-Premise Execution for Compliance & Security: Because Testkube executes tests directly inside your Kubernetes cluster, the entire testing process remains within your organization’s controlled network perimeter if your cluster is hosted on-premise or within a private cloud (VPC). Test scripts interact with applications under test locally within the cluster, and sensitive test data does not need to leave your environment. This is a critical requirement for organizations operating under strict data privacy regulations (like GDPR, HIPAA) or security policies that forbid exposing internal systems or data to third-party cloud services. Testkube provides complete control over the test execution environment and data locality.
• Simplified Management & Scalability: Managing Selenium Grid on Kubernetes is operationally intensive, requiring expertise in Helm, Kubernetes networking, resource tuning, and custom scaling solutions. Testkube abstracts away much of this complexity by utilizing Kubernetes’ native mechanisms for scheduling pods, managing resources, ensuring reliability through ReplicaSets/Jobs, and potentially scaling test execution pods using standard Kubernetes practices. Defining tests as Kubernetes CRDs allows them to be managed via GitOps workflows, just like application configurations. This significantly reduces the operational burden, allowing QA and DevOps teams to focus on test development rather than infrastructure maintenance. Scaling becomes more aligned with familiar Kubernetes patterns.
• Improved CI/CD Integration & Flexibility: Testkube effectively decouples test execution orchestration from the CI/CD pipeline itself. Instead of the CI/CD tool being responsible for setting up the entire test environment, running the tests, and collecting results, it simply triggers a test or workflow execution within Testkube via its API or CLI. Testkube handles the rest within the cluster. This leads to simpler, potentially faster CI/CD pipeline configurations. It also increases flexibility, as tests can be easily triggered manually via the Testkube dashboard or CLI for debugging or ad-hoc validation, independent of a full CI/CD run. Furthermore, Testkube can initiate tests based on internal Kubernetes events, such as the deployment of a new application version, enabling event-driven testing workflows.
• Centralized Test Management & Visibility: Testkube provides a unified platform for managing and observing all types of tests running within your Kubernetes cluster, not just Selenium tests. It offers a centralized dashboard and CLI to define tests, trigger executions, view logs, access test artifacts (like screenshots or reports), and monitor results across different testing frameworks. This creates a single pane of glass for quality assurance activities within Kubernetes, simplifying analysis and tracking.

Leveraging these benefits allows for more robust and efficient functional testing. Functional testing, which validates that your application behaves as expected from a user’s perspective, is a prime use case for Selenium. For a deeper dive into leveraging Testkube for robust functional testing with Selenium, including practical workflow examples demonstrating parallel execution and simplified setup, check out our detailed guide to functional testing in Selenium.

Ultimately, Testkube’s advantages derive from its Kubernetes-native architecture. By embracing Kubernetes principles and treating tests as integral parts of the cluster state, it transforms Selenium testing from an external infrastructure challenge into a streamlined, efficient, and secure component of the cloud-native development lifecycle.

Conclusion

Selenium has undeniably revolutionized web application testing. Its evolution from a simple JavaScript runner to a comprehensive, multi-component suite centered around the powerful and standardized WebDriver API has made it an essential tool for ensuring software quality in the fast-paced world of web development. The introduction of Selenium Grid addressed the critical need for parallel execution, enabling teams to scale their testing efforts and reduce execution times significantly.

However, as development environments shifted towards containerization and orchestration with Kubernetes, running traditional Selenium Grid presented new operational hurdles. The complexities of setup, resource management, scaling, and maintaining reliability for Grid infrastructure within the dynamic Kubernetes ecosystem often became a significant burden, diverting focus from the primary goal of testing applications.

Testkube emerges as a transformative solution by offering a truly Kubernetes-native approach to test execution. It stands out by enabling Selenium tests (and many other test types) to run directly on existing Kubernetes infrastructure, eliminating the need for a separate, managed Selenium Grid. This native integration yields substantial benefits: significant cost savings through resource consolidation, enhanced security and compliance through on-premise or private cloud execution, dramatically simplified management leveraging Kubernetes primitives, and seamless integration into cloud-native CI/CD and GitOps workflows.

By treating tests as first-class citizens within Kubernetes, Testkube removes the traditional bottlenecks associated with scaling test infrastructure. It empowers QA and development teams to focus on building high-quality applications, backed by efficient, scalable, and integrated testing processes. For organizations leveraging Kubernetes, embracing a Kubernetes-native testing framework like Testkube represents the next logical step in modernizing their approach to Selenium testing, leading to faster feedback cycles, improved reliability, and more efficient software delivery.

‍

Originally published at https://testkube.io.

Mastering Selenium Testing with Kubernetes was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s a step by step guide to getting started with Testkube Open Source for cloud native test execution and orchestration.

Testkube is the go-to framework for developers, testers, and DevOps engineers to seamlessly integrate testing within their GitOps pipelines so that the applications are tested before deployment.

Testkube consists of two major components:

1. Testkube Agent is an open source component that manages Testkube resources, listens to Kubernetes Events, and performs the entire test execution along with collecting the results and relevant logs. This is managed via Testkube CLI.
2. Testkube Control Plane is a commercial solution that comes with a life-savior Dashboard to have better control over multiple testing environments. The control plane can be hosted by Testkube or in your existing infrastructure known as Testkube On-Prem.

In this blog post, we will explore the Testkube Agent as a standalone open source alternative for test execution and show how to get started with its deployment on a Kubernetes cluster, execute tests, and automate test execution using a CI/CD tool like GitHub Actions.

Testkube Agent

The Testkube Agent is 100% Open Source and comprises the core Testkube execution and orchestration engine for running tests in your Kubernetes infrastructure. You can deploy Testkube Agent in two modes:

Standalone Mode

In Standalone mode, the Testkube Agent can be managed directly through the Testkube CLI or directly with the agent API. This mode is free to use and is best suited for users who prefer to control their testing infrastructure without the need for an external control plane.

Connected Mode

Connected mode is commercial and connects your Agent to the Testkube Control Plane, enabling you to manage any number of Testkube Agents from a centralized dashboard. The mode synchronizes test results to the control plane, enabling centralized test management and better insights from analytics and reporting. The connected mode also enables features like complex test orchestration, parallel execution, parametrization, and spawning dependencies.

Features of the Testkube Open Source Agent

The Testkube Agent provides an extensive set of strong features that are aimed at improving your testing experience, thus making it a strong tool for Kubernetes-native testing. Here are some of Testkube Open Source’s features:

• Test Workflows: Manage workflows and templates, execute multiple tests concurrently, and integrate with CI/CD tools such as GitHub Actions, Jenkins, CircleCI, and Azure DevOps.
• Test Logs: Manage test logs generated during test execution and allow teams to gain insights into their testing processes and optimize their testing strategies.
• Webhooks: Supports real-time integration with third-party tools, enabling seamless interaction between Testkube and other tools, such as incident response and management systems, communication systems, and monitoring and observability tools.
• Test Triggers: Automates the running of tests based on the occurrence of particular events in Kubernetes resources. Provides concurrency policies that determine how multiple trigger runs are managed.
• Testkube CLI: Allows users to manage various Testkube resources. You can initiate test executions directly from the command line; also allows viewing the status and logs of test executions.

For further details on Testkube Agent features, see the Testkube documentation.

Deployment Architecture of Testkube Open Source

The deployment architecture of Testkube is built for effective test execution and orchestration in Kubernetes environments. A high-level deployment architecture of the Testkube Agent in the standalone mode is shown below:

‍

• Testkube namespace: A dedicated namespace where all the Testkube-related resources, such as Agent API, MongoDB, and CRDs are deployed.
• Agent API (Operator): The lifecycle of Testkube resources is handled by the Agent API or Kubernetes Operator.
• Test executions (K8s Jobs): When a test is triggered, the Agent API creates Kubernetes jobs to execute the tests. They are launched within the same Kubernetes cluster, taking advantage of the resources in the cluster to run the tests.
• MongoDB: The database employed here is MongoDB for storing metadata about tests, test runs, and other Testkube resources.
• MinIO: It is an object storage solution for storing test artifacts like reports, logs, and other data that are created when test runs are executed.
• Test/Workflows/etc (CRDs): Testkube relies on Custom Resource Definitions (CRDs) for specifying tests, test workflows, and other setups. The CRDs are monitored by the Agent API (operator) for initiating test runs.

Components of the standalone architecture:

For a more detailed description of the deployment architecture, refer to the Testkube documentation.

Installing the Testkube Agent in Standalone Mode

The Testkube Agent can be deployed on any Kubernetes or Openshift cluster, and there is also a Docker-version available. In this demo, we have set up a Kubernetes cluster on Minikube.

Let us deploy Testkube Agent using the following command and see the relevant outputs:

$ helm repo add kubeshop https://kubeshop.github.io/helm-charts "kubeshop" already exists with the same configuration, skipping This shows that Kubeshop repo already exists. You can run `helm repo update` to retrieve the latest versions of the packages. $ helm repo update Hang tight while we grab the latest from your chart repositories...... Successfully got an update from the "kubeshop" chart repository... Successfully got an update from the "testkube" chart repository Update Complete. ⎈Happy Helming!⎈

$ helm upgrade --install \ > --create-namespace \ > --namespace testkube \ > testkube kubeshop/testkube Release "testkube" does not exist. Installing it now. NAME: testkube LAST DEPLOYED: Mon Feb 17 18:17:48 2025 NAMESPACE: testkube STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Enjoy testing with Testkube!

This installation created the `testkube` namespace since it does not exist on the cluster.

$ kubectl get all -n testkube NAME READY STATUS RESTARTS AGE pod/testkube-api-server-7bb4bc55dc-tbcrj 1/1 Running 0 16m pod/testkube-minio-testkube-54f9847486-pvv69 1/1 Running 0 16m pod/testkube-mongodb-8584d5ff8c-sczhz 1/1 Running 0 16m pod/testkube-nats-0 2/2 Running 0 16m pod/testkube-operator-controller-manager-fccfbcdf-lbds4 1/1 Running 0 16m‍ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/testkube-api-server ClusterIP 10.96.164.55 <none> 8088/TCP,8089/TCP 16m service/testkube-minio-service-testkube ClusterIP 10.102.225.84 <none> 9000/TCP,9090/TCP,9443/TCP 16m service/testkube-mongodb ClusterIP 10.100.106.240 <none> 27017/TCP 16m service/testkube-nats ClusterIP 10.111.241.122 <none> 4222/TCP 16m service/testkube-nats-headless ClusterIP None <none> 4222/TCP,8222/TCP 16ms ervice/testkube-operator-controller-manager-metrics-service ClusterIP 10.98.254.127 <none> 8443/TCP 16m service/testkube-operator-webhook-service ClusterIP 10.101.235.142 <none> 443/TCP 16m‍ NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/testkube-api-server 1/1 1 1 16m deployment.apps/testkube-minio-testkube 1/1 1 1 16m deployment.apps/testkube-mongodb 1/1 1 1 16m deployment.apps/testkube-operator-controller-manager 1/1 1 1 16m‍ NAME DESIRED CURRENT READY AGE replicaset.apps/testkube-api-server-7bb4bc55dc 1 1 1 16m replicaset.apps/testkube-minio-testkube-54f9847486 1 1 1 16m replicaset.apps/testkube-mongodb-8584d5ff8c 1 1 1 16m replicaset.apps/testkube-operator-controller-manager-fccfbcdf 1 1 1 16m‍ NAME READY AGE statefulset.apps/testkube-nats 1/1 16m

With this installation, the Testkube API server is running on the cluster along with MongoDB for test results, Minio for artifact storage, and other CRDs for managing the TestWorkflows, Triggers, Webhooks, etc.

Running Tests with the Testkube Agent

Testkube provides Test Workflows as a declarative approach to defining how to execute your tests. For understanding purposes, we have taken the example from the quickstart documentation and kept it in a GitHub repository.

Install Testkube CLI

For executing the Test Workflow, you will need Testkube CLI. Install Testkube CLI on your machine and verify using the following command:

Create Test Workflow

Here is a Test Workflow that will execute a k6 test using Testkube on the cluster.

Save this configuration in a file `testworkflow.yaml` and create Test Workflow on the cluster using the Testkubde CLI as shown below.

‍

Since Workflows are regular Kubernetes CRDs, you can also create them by simply using kubectl apply -f testworkflow.yaml

Verify the deployment of the Test Workflow:

We have successfully deployed Test Workflow on the cluster. Here the `status` and `execution` are empty because we have not yet executed the Test Workflow. Let us go ahead and execute it.

Execute Test Workflow

Testkube CLI provide `run` command to execute a Test Workflow. Let us go ahead and execute the `ephemeral-test` Test Workflow.

Here we have queued the Test Workflow for execution. You can also watch the execution by passing the ` — watch` flag.

1. Initializes the environment.
2. Clones the GitHub repository.
3. Runs the shell command for the k6 test execution.
4. Uploads the artifacts if found.

Verify if the Test Workflow has been executed as shown below:

The Test Workflow has been successfully executed. Testkube performs the following steps in Test Workflow execution:

View Test Workflow execution logs

Testkube manages the logs and lets you access them via CLI. You can have a detailed view of the Test Workflow execution using the following command using the executionId shown in the terminal output above:‍

Head over to the Testkube Examples documentation for examples of how to run popular testing tools with Testkube, including Playwright, Cypress, Postman, and JMeter.

Automate Test Execution with GitHub Actions

1. Created a kind cluster.
2. Added the `kubeshop` Helm chart.
3. Installed Testkube on the cluster using Helm chart. For scenarios when you want to run your tests from inside your existing infrastructure it is recommended to have the Testkube Agent installed there (in a dedicated namespace) instead of provisioning it inside each execution of your Github Actions Workflow..
4. Checked the status of the Testkube API server, MongoDB, and MinIO pods.
5. Setup Testkube CLI
6. Created Test Workflow on the cluster using the `testworkflow.yaml` file.
7. Executed the Test Workflow.

Testkube provides “Setup Testkube CLI” action that can be directly used in the workflow to manage Testkube installation on a cluster. In this demo, we will automate the execution of the k6 test in the pipeline when a new Pull Request is raised using the following workflow.

1. Set up a GitHub repository, add the above manifest to the repository in `.github/workflows/main.yaml` file, the Test Workflow we used in the last section, and the k6 test you want to execute. Here is the sample repository.
2. Create a Pull Request and wait for the workflow to be triggered. In the following image, you can see workflow has been triggered.

In this configuration, we have defined the following steps:

Let us check how the above workflow executes and automates test execution.

Here you can see all the steps have been completed successfully.

In the workflow, you can view the entire execution details related to the k6 test and the Testkube Test Workflow. With this, you were able to automate the execution of a k6 test via GitHub Actions using the Testkube Open Source solution.

Conclusion

The Testkube Agent is Open Source and supports automated testing in Kubernetes environments, making it possible for developers and teams to execute tests at scale inside their clusters. Test execution can be scheduled through Testkubes CLI interface or REST API, making it easy to integrate with CI/CD tools such as GitHub Actions, where tests can be automatically run on code changes. Following the installation and configuration processes, you can start using the Testkube Agent in Standalone Mode and automate end-to-end testing in your workflows, and later connect it to the Testkube Control Plane if the need for more enterprise-grade functionality arises.

Sign up for Testkube today and explore the full potential of its Control-Plane functionality.. Visit the Testkube documentation and learn more about Testkube and its capabilities. If you have any questions, reach out to us on Slack.

Originally published at https://testkube.io.

Testkube Open Source Guide | Testkube Blog was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kubernetes has become the de facto container orchestrator that enables organizations to build scalable, available, and resilient apps that meet modern business demands. However, with this comes complexity. Infrastructure failures, from network routing to node failures and storage failures, can lead to significant business disruptions. A single misconfigured policy or resource quota can lead to a complete outage, directly impacting the revenue and customer trust.

That is where Infrastructure testing in Kubernetes becomes crucial. By validating Kubernetes components, teams can prevent downtimes, ensure compliance, and maintain high availability. Thorough testing of various components and layers helps identify issues before they reach production, reducing mean time to recover (MTTR) and improving overall reliability.

In this post, we’ll examine infrastructure testing strategies for Kubernetes and discuss ways and best practices for testing infrastructure to ensure production readiness.

Key Areas of Infrastructure Testing

When we talk about infrastructure testing in Kubernetes, we’re talking about the foundation that supports your entire application ecosystem. Beyond just checking if the pods are running, it involves comprehensive testing of cluster health, compute, networking, and storage resources. Such an all-around approach ensures that your infrastructure is ready to support your production workloads while keeping up with security and performance standards.

Cluster Availability and Health

This serves as the foundation for reliable Kubernetes operations. Effective testing requires validating the control plane components — API server responsiveness, scheduler functionality, and controller manager operations — and ensuring these meet the SLAs. You must also validate node readiness to confirm kubelet health and capacity for scheduling your workloads.

You should also focus on validating etcd to ensure that core configurations are intact to prevent data corruption. You should also check add-on services like CoreDNS, kubeproxy, and any other tool you use to identify warning signals early and avoid cascading failures.

Compute Resource Validation

Ensuring your cluster can effectively manage and distribute workloads is critical. It is important to verify the node capacity metrics including CPU, memory and storage while confirming the allocatable resources after system reservations. For specialized workloads like AI & ML, you need to validate device plugins and compatibility for GPU/TPU resources.

Resource quota enforcement testing ensures namespace level constraints, validating the limits during load conditions and ensuring appropriate throttling behaviors. It’s also important to validate node affinity and taint configurations for correct pod placement to maintain workload isolation and ensure critical workloads get adequate resources.

Network Validation

Testing networks is critical for application connectivity. DNS resolution tests must be done to confirm both internal kube-dns and external name resolution are working as expected with an appropriate timeout. Service resolution testing ensures ClusterIP, NodePort, or LoadBalancers services function correctly across namespaces.

Test your ingress to confirm correct rule processing, TLS termination, and backend service routing under various load conditions. Validate network policies for proper pod isolation. You should also check the load balancer configuration to ensure proper health probe functionality, session persistence, and correct traffic distribution.

Storage Validation

Validating storage ensures data persistence and availability for stateful workloads in Kubernetes environments. Storage class availability testing verifies provisioner functionality and validates reclaim policies across different storage backends. PVC provisioning tests must validate capacity limits, access modes and correct volume attachment to nodes.

Measuring throughput and latency under various load conditions is also critical for ensuring I/O profiles meet application requirements. This will also identify any bottlenecks during concurrent operations. Lastly, validating backups is critical for smooth operations. Check for snapshot creation capabilities, check restoring procedures with data integrity verification, and validate retention policy enforcement.

When To Run Infrastructure Tests

While we now know the importance of infrastructure testing in Kubernetes, knowing precisely when to execute infrastructure tests can reduce operational risks. Infrastructure failures can impact multiple workloads simultaneously. By knowing when to execute your infrastructure tests, you can prevent any cascading failures and reduce debug times.

Below are some strategic points when you should run your infrastructure tests:

• Pre-deployment: validate infrastructure and cluster health before workloads are deployed.
• Post-deployment: After the workload is deployed and there are any changes done using tools like Terraform or CloudFormation
• Post-upgrade: After the cluster is upgraded, verify compatibility.
• Scheduled intervals: Regular infrastructure tests to detect any configuration drift.
• Before critical releases: Conduct pre-flight checks before deploying critical workloads.

The scope of testing and frequency should align with your management practices along with a comprehensive testing plan.

Implementing Infrastructure Testing with Testkube

Infrastructure testing in Kubernetes requires validating multiple components across cluster health, compute, networking, and storage. This often demands multiple testing tools and methods, many of which weren’t designed for container environments. Traditional approaches create integration challenges and add to management overhead.

That’s where Testkube comes in. It addresses these challenges by providing a cloud-native testing framework that unifies infrastructure testing workflows. Let’s understand how Testkube helps.

Testkube is a cloud-native, vendor-agnostic test execution framework that makes testing in Kubernetes straightforward. Using Testkube, you can orchestrate and automate complex validation workflows using different testing tools while maintaining Kubernetes-native operations.

Benefits of Using Testkube For Infrastructure Testing

Testkube enhances infrastructure testing by integrating seamlessly with Kubernetes, allowing teams to leverage their full potential. Here are a few benefits of using Testkube:

• Orchestrate Complex Test Workflow: Test Workflows enable sequential and parallel test executions that mimic real-world scenarios without complex scripting, giving you better control over infrastructure validation.
• Seamless integration: Testkube effortlessly articulates with CI/CD platforms like Jenkins, GitLab CI, and Argo CD, allowing for automated infrastructure testing as part of the deployment process.
• Integration with Testing Tools: Testkube works with popular testing tools like k6, Curl, and Postman, allowing you to combine different approaches for comprehensive infrastructure validation.
• Single pane of Glass: All test results, logs, and artifacts are in one place, no matter how tests are triggered, and they provide streamlined test troubleshooting and powerful holistic reporting

Thanks to its flexibility and alignment with cloud-native technologies, Testkube allows you to execute test workflows at various strategic points in your application’s lifecycle:

Infrastructure testing using Testkube

By orchestrating tests that leverage familiar tools like Curl, Pytest, and K6, Testkube eliminates integration challenges without compromising text execution. Below are a few examples demonstrating how Testkube makes complex infrastructure testing accessible and efficient for production environments.

Using Curl for Cluster Health Checks and Resource Validations

Testkube makes it easy to implement comprehensive cluster health checks using simple HTTP-based tools like Curl. This validates control plane components, etcd health, and node readiness in a Kubernetes-native way.

This workflow validates critical cluster components by sequentially checking API server responsiveness, confirming node readiness status, verifying etcd health, and ensuring CoreDNS is working as expected.

Using cURL for Network Testing

Network testing requires validating critical communication paths in your Kubernetes cluster. Here’s a simple example using cURL to verify ingress controller health:‍

This workflow focuses on validating your ingress controller’s health — a critical component for external traffic routing.‍

Using Node Selectors for GPU Test‍

Hardware validation ensures that specialized workloads have the resources they need. This example tests GPU availability and performance.‍

The above test workflow has a single step that executes a Docker image which does matrix calculations using CUDA. The test will fail if the Pod running it does not run on a Node with a GPU or if the CUDA Toolkit is not installed.

What we saw here were a few examples of how you can use Testkube for Infrastructure testing in Kubernetes. You can build more complex workflows to suit your requirements. Check out our blog posts to learn more about building complex workflows using Testkube.

Summary

Infrastructure testing in Kubernetes is complex due to the presence of multiple components, resources, networking, and storage. Effective validation of all of these requires a comprehensive approach using multiple tools, each targeting different aspects of infrastructure testing.

Testkube addresses this complexity by providing a cloud-native and vendor-agnostic testing framework that unifies different tools into cohesive workflows. It helps teams implement thorough infrastructure validation with minimal operation overhead.

We would love to hear all about the custom test workflows that you created using Testkube for infrastructure testing. If you face any issues, remember that the entire Testkube team, plus a vibrant community of fellow Kubernetes testers, are on Slack. We’re just getting started in building the most comprehensive cloud-native testing framework for Kubernetes so feel free to follow us on Twitter @testkube_io.‍

Originally published at https://testkube.io.

Infrastructure Testing in Kubernetes | Testkube was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cloud native deployments move fast, but testing lags behind, causing bottlenecks. Continuous testing ensures reliability by integrating tests throughout development.

The modern cloud native stack excels at automation and control, enabling automated deployments for faster and more reliable releases. In today’s landscape, where a single deployment can impact millions of users, the stakes for quality have never been higher. We version control our infrastructure, applications, and even documentation, but the tests are scattered across the CI pipeline, local machines, or shared environments.

We’ve built sophisticated cloud native platforms that can automatically scale, heal, and update themselves. Yet, our testing practices are stuck in the past and often prove to be bottlenecks in our delivery pipelines. This disconnect between traditional testing practices and modern deployment capabilities hinders business velocity.

In this blog post, we’ll look at the challenges with traditional testing practices in the cloud native era and understand the need for continuous testing.

Testing Challenges When Going Cloud Native

The mismatch between modern deployment practices and legacy testing methods can create several challenges. Let’s examine some of them.

Current Challenges

Testing in most organizations is a reactive process triggered by code commits or scheduled runs. This approach leaves significant gaps between deployment and validations. When tests are executed in isolation, issues arise late in the deployment cycle, making fixes costlier and more complex to implement.

Microservice architecture leads to environment inconsistencies. For instance, the production environment would leverage Kubernetes and GitOps practices, while the testing environment often relies on manual configuration. This leads to configuration drift between developers’ local setups, CI pipelines, staging, and production.

Modern observability tools provide deep insights into applications and infrastructure, but test coverage often remains opaque and disconnected. This poor visibility affects the team’s ability to track which microservices were tested adequately, which is a challenge, especially as the number of microservices grows.

The “works on my machine” syndrome is amplified in cloud native scenarios, as a test passing locally might fail in CI due to differences in environments, such as containers, networks, and security policies.

Business Impact

These challenges are technical; however, they can adversely impact business outcomes.

Your releases can be delayed when the test environment doesn’t accurately reflect the production setups. In such situations, teams struggle to resolve environment-specific issues, which also affects their overall productivity.

Further, your engineers spend hours debugging tests that arise due to environment inconsistencies rather than actual code. A simple deployment that should have taken a few minutes can stretch for a few days as teams figure out the reasons for the failure of the tests.

This adds to your costs as organizations maintain multiple test environments-development, staging, QA, and pre-production-each with its own configuration, adding to the maintenance overhead. The costs also multiply with every new service added to the ecosystem.

This ripple effect first affects the team’s confidence in testing, which means the team either delays deployment to conduct extra tests or releases them with reduced coverage, which eventually adds to the technical debt. This debt compounds over time, making the test suite unreliable.

Continuous Testing: A Strategic Necessity

As cloud native becomes the default way to build and deploy applications, it introduces more complexity, and traditional testing no longer suffices. Applications are broken down into smaller pieces which are deployed on cloud-hosted infrastructure and loosely coupled via event driven architectures. That’s where continuous testing becomes a strategic necessity to ensure continued integrity of your applications functionality.

Continuous testing adds validation to every phase of the development cycle. Instead of treating testing as a phase, it becomes part of every stage. For instance, when an interface definition changes, API contract tests run automatically. At the same time, organizations can leverage chaos testing practices to continuously verify system resilience in Kubernetes clusters.

Integrating testing earlier in the development cycle-shift left-ensures that developers run integration tests locally by setting up ephemeral environments. At the same time, automated security scans can validate the dependencies during code commits. Simultaneously, you can extend testing to production using canary deployments to ensure real-world validation of microservices behavior.

Take The Shift Right Advantage

Early testing helps you catch many issues, but production environments present unique challenges that can only be validated under real-world conditions. Progressive delivery practices enable safe testing in production, complementing the shift-left approach.

Techniques like canary route a small percentage of traffic to a new application version, allowing teams to validate the performance with actual user behavior. You could use feature flags for fine-grained control that enables teams to perform A/B testing in real-world scenarios and gradually enable new functionality.

Such practices provide insights that are difficult to discover in staging environments. Utilizing these practices with monitoring and chaos engineering guarantees reduced deployment risks and shorter feedback loops between development and real-world usage.

Implementing Continuous Testing in a Cloud Native Infrastructure

Treating test suites with the same rigor as production workloads is key to successfully implementing continuous testing. With Kubernetes powering most of the cloud native applications today, you want your traditional tests to be converted to Kubernetes resources so that each of them is versioned and follows a declarative manifest that can be deployed and managed like any other Kubernetes resource.

From API tests to end-to-end system tests, all must be version-controlled alongside the application code to enable GitOps practices for managing tests. This approach ensures that test environments are reproducible and mimic the production environment.

Provisioning your environment must be code-driven and use Infrastructure as Code to spin up isolated test environments that mirror production configurations. These ephemeral environments, provisioned for test execution, are torn down, eliminating any configuration drift and reducing costs and maintenance overheads.

Testkube brings all of these practices together in a Kubernetes environment. It transforms your existing tests from tools like Cypress, Postman, or k6 to Kubernetes resources, making them deployable through standard Kubernetes tools.

With Testkube, teams can:

• Orchestrate test execution across different environments
• Configure the execution of tests and their dependencies in a single yaml file — as a Kubernetes resource
• Get consolidated test results and metrics with a built-in dashboard
• Integrates with CI/CD tools like GitHub Actions, Jenkins, and ArgoCD, also with CI tools like CircleCI

‍

Testkube provides a standalone Open Source Agent that is deployed in your Kubernetes infrastructure for vendor-agnostic test execution and a commercial Control Plane that can be used to manage multiple agents with additional features for parallelization, orchestration, RBAC, centralized troubleshooting and reporting, etc.

Business Case For Continuous Testing

Every minute of downtime not only impacts customers but also impacts your revenue. Hence, continuous testing becomes a competitive advantage and a business differentiator that is just a technical practice.

With continuous testing, organizations can reduce time-to-market while maintaining high quality standards. By detecting issues early in the development cycle, organizations can reduce the fix costs up to 100% compared to fixing issues in production. At the same time continuous feedback loops help prevent defect leakage to your customers.

Further, instead of running the entire test suite for every change, you can implement risk-based testing to execute only relevant tests. This effectively utilizes your cloud resources, as environments are spun up only when needed and scale based on test demands. This can help reduce testing infrastructure costs by up to 50%.

With quicker feedback loops, developer productivity boosts. When developers receive test results in minutes rather than hours, they can fix issues immediately, speeding up the development process and improving code quality.

To sum up, continuous testing is a strategic need and not just another technological adoption. As organizations continue to build and deploy on cloud, those who implement continuous testing will be positioned to deliver high-quality applications faster and more reliably.

Reach out to us to discover how Testkube can help you implement continuous testing. You can also join our Slack community to start a conversation or read Testkube documentation. The question isn’t about whether to adopt continuous testing, but rather how quickly you can begin your journey.

Originally published at https://testkube.io.

Continuous Testing for the Cloud Native Era | Testkube Blog was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

By introducing continuous testing into CI/CD workflows, teams can create high-quality software in shorter periods, reduce risks, and address issues ahead of time. Our previous blog posts discussed integrating Testkube with CI/CD tools like GitHub Actions, Jenkins, Azure DevOps, Bitbucket, and CircleCI.

In this blog post, we’ll look at utilizing TeamCity build pipelines and Testkube to continuously deploy test cases as part of the CI/CD pipeline.

What is TeamCity?

TeamCity is a robust build management and CI/CD server developed by JetBrains. It automates the build, test, and release processes, ensuring your application remains deployable. TeamCity’s web-based interface allows you to configure and manage builds and review and evaluate build logs and statistics.

The TeamCity build pipeline is a series of automated processes that monitor application development, testing, and deployment. It is a component of the CI/CD practices that TeamCity facilitates.

It streamlines the development process by continuously updating the application’s status. This real-time feedback allows developers to quickly detect, evaluate, and address issues before they escalate into major ones. Its compatibility with a wide range of version control systems, build tools, and testing frameworks makes TeamCity an ideal choice for CI/CD pipelines.

TeamCity offers multiple installation methods, including Docker and TeamCity Cloud. Your specific requirements and infrastructure determine your preferred installation method. Refer to the TeamCity Cloud documentation to learn more about the installation process.

We’ll use TeamCity Cloud to integrate with Testkube for this blog post.

Benefits of Using Testkube with CI/CD Pipelines

Testkube is a cloud native testing control plane that helps with test orchestration and execution. Integrating this capability with various CI/CD pipelines yields multiple benefits, as outlined below:

• Integration with Various CI/CD Tools: Easy integration with well-known CI/CD tools like GitHub Actions, Jenkins, Azure DevOps etc.
• Test Execution and Reporting:Perform tests effectively and generate comprehensive reports.
• Enhanced Security: Testkube ensures that your tests run securely by preventing unnecessary exposure in the CI/CD pipeline, which improves overall system security.
• In-depth Insights: Testkube captures and analyzes data from your executed tests. It leverages this information to generate detailed insights and dashboards, offering a clear view of test performance and trends.

Now, let’s learn how to integrate Testkube and TeamCity build pipelines for a consistent and effective testing process.

Integrating TeamCity Build Pipelines with Testkube

We will integrate Testkube with TeamCity to streamline and optimize the testing process. For this demo, we will store a test workflow in a Git repository and configure the TeamCity build pipeline to automatically run whenever a new pull request (PR) is created in the repo. As a result, the test workflow will be deployed and executed on a target Kubernetes cluster, ensuring seamless integration and efficient testing within the CI/CD pipeline.

You can find the test workflow in this repo, which we’ll use for this blog post.

Prerequisites

Once you meet the prerequisites, you can start a target Kubernetes cluster using a Testkube agent setup. You should also have a GitHub repository with the k6 test workflow configured.

To create the API token, refer to our API Token document. To find the Org ID and environment IDs, go to your Testkube Dashboard and click Settings from the menu bar.

For security reasons, you must store these IDs and credentials as variables in the Parameters section of TeamCity to ensure their secure access and utilization during pipeline execution. Refer to the TeamCity documentation for additional details.‍

Creating a Test Workflow in Testkube

Testkube allows you to create Test Workflows, which are an easy and quick way to define and run tests within a Kubernetes cluster. With these YAML-based specifications, the test and any associated images, artifacts, and resource parameters can be defined in a single file.

It gives you more flexibility and control over the tests and lets you build multi-step workflows that manage requirements end-to-end.

Discover and learn more about Test Workflows, which enable you to perform efficient and seamless testing in Kubernetes frameworks.

The first step is to create a test workflow. Here’s an example of how to create a test workflow:

• Log in to your Testkube dashboard and navigate to the Test Workflow section.
• Click the “Add New Test Workflow” button.
• A “Create a Test Workflow” dialog box appears, and you can build the sample workflow by selecting the “Start from an Example” option.

Here’s a sample Test Workflow we created for k6:

‍

We’ll save this k6 test workflow configuration as a yaml file in our GitHub repo and configure TeamCity’s build configuration to refer to this repo.

Configuring TeamCity Build Pipelines

• Manually
• Using one of the listed tools
• Providing a repository URL

After logging into your TeamCity account, you can create a project either:

Here, we’ll choose from a repository URL option

Enter the details required to create a project from the URL, then click Proceed.

On the “Create a Project from a URL” page, enter the project name “Testkube Demo” and other details, then select the Proceed button.

After creating the project, the Build Steps page will automatically detect the build steps and their settings by scanning the specified VCS repo. This auto-detection will work only if a build file is in the repo. If the repo does not have a build configuration, the auto-step will not work. In this case, you can set up the build steps manually.

Since our repo doesn’t have a default build configuration, we will manually create a new build step. You can add a new build step to the build configuration by selecting a runner from the list or searching for it directly. Here, we’ll use “Command Line” as a runner to execute shell commands or scripts.

When you select the Command Line runner, a “New Build Step: Command Line” page displays, which allows you to create a build configuration.‍

Enter the details required for configuring and running the build step, including the Step name, Step ID, Custom script, etc., and then click Save to add it to the configuration. Click on “Show advanced options” to configure additional settings.

Let’s take a look at the custom script:

echo "Execute Test Workflow" # Setting Testkube Context testkube set context --api-key $TESTKUBE_API_TOKEN --org-id $TESTKUBE_ORG_ID --env-id $TESTKUBE_ENV_ID # Verify Testkube CLI installation testkube version # Run Testkube command to validate the connection testkube create testworkflow --name testworkflow-actions -f k6-basic.yaml testkube run tw testworkflow-actions

• Configures the Testkube CLI context to use the specified environment by setting the context with the provided API key, organization ID, and environment ID..
• testkube version: Verifies that Testkube CLI has been installed correctly and is operational.
• testkube create testworkflow — name testworkflow-actions -f k6-basic.yaml: Creates a new test workflow in Testkube named testworkflow-actions and the -f k6-basic.yaml flag specifies the configuration file for the test workflow, which defines the workflow steps and parameters.
• testkube run tw testworkflow-actions: Executes the test workflow

The mentioned workflow carries out the following actions:

After configuring your build steps, click on the “Triggers” section to configure the existing VCS Trigger. Once configured, TeamCity will detect changes in the VCS whenever they occur on the repo and add them to the build queue for execution.

To save your changes, click the Save button.

‍

After configuring the Triggers section, click on the “Build Features” section to add features that extend the build process, such as connecting external tools, managing resources, and pushing statuses to VCSs.

We want TeamCity to publish the build status to the GitHub PR for our use case.

‍

Click “Add Build Feature” and choose “Commit Status Publisher”.‍

In “Publisher,” select the repo for publishing the build status. From the drop-down menu, select GitHub.

Select “Access Token” from the drop-down menu under Authentication Type to authenticate with the repo.

• Repo: status for repository-level status updates.
• public_repo for public repositories or repo for private repositories.

To obtain an access token, a GitHub personal access token with specific permissions is necessary, including:

Refer to the GitHub documentation to create a Personal Access Token for your GitHub repo.

You can verify the configuration by connecting to the given VCS repository by clicking the “Test Connection” button.

‍

Once the build feature is configured, click the Save button to apply the changes. The build feature will be added to the list.

‍

You can add environment variables to the Parameters section by clicking the “+Add new parameter” button. Configuring environment variables before configuring build steps, triggers, or other settings is generally recommended.‍

By following these steps, we have successfully configured your TeamCity pipeline to integrate with Testkube. This setup ensures that your build steps are properly defined and the VCS trigger is configured to monitor changes in your repo.

Triggering Testkube Test

Once you have configured your pipeline, make some changes to the repo and commit them by raising a pull request to trigger the pipeline.

‍

Once the pull request is created, the configured VCS Trigger in TeamCity automatically triggers the pipeline. The pipeline begins executing the steps defined in the build configuration file.

On TeamCity, navigate to the project and click on the “Build” option to view the build execution status and build log.‍

Based on the configuration, we can see that the pipeline is triggered with each new PR. It connects to our target Kubernetes cluster, deploys the k6 test defined in the repo, and runs the test workflow using Testkube.

Monitoring the Test Workflow

You can use the Testkube CLI or the Testkube dashboard to monitor and report on the workflow’s progress. Let’s look at how to use the dashboard to monitor the status of the Test Workflow.

Navigate to the Test Workflows page to see the k6 test workflow named “testworkflow-actions,” which was deployed via the pipeline.

Click on a step to see the status of the test workflow.

Testkube collects all artifacts upon execution, providing a stats report containing all outputs and results.

You can also verify the status of the pipeline execution on GitHub PR. This is because of the Build Feature that we configured, which enables TeamCity to update the build status for the GitHub PR.

The example above shows how easy it is to configure Testkube with TeamCity. You can execute advanced scenarios by modifying the workflow and setting repositories to meet specific requirements.

Summary

Continuous testing is paramount in the modern software development industry, as it optimizes the efficiency of test practices, thereby improving the testing experience. We automated the testing process by seamlessly integrating TeamCity build pipelines’ automation capabilities with Testkube’s testing capabilities while creating a robust CI/CD pipeline framework.

We demonstrated the process by successfully implementing a k6 test using Testkube and executing it through TeamCity build pipelines, resulting in a practical workflow that improves testing efficiency and reliability.

So, now that you’ve learned about these two powerful tools-TeamCity and Testkube-and how they can be seamlessly integrated to help with testing, take your CI/CD pipeline experience to the next level by leveraging their combined strengths to deliver reliable releases quickly and effectively.

Reach out to me to discover how Testkube can transform your testing strategy. You can also join our Slack community to start a conversation or read Testkube documentation to see how Testkube can enhance your GitOps testing workflow, ensuring seamless, efficient, and automated testing within the Kubernetes environments. The future of software testing is here. Are you ready to be a part of it?

Originally published at https://testkube.io.

Master Continuous Testing with TeamCity and Testkube was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this blog post, we’ll take a look at how to use Bitbucket Pipelines and Testkube to continuously deploy test cases in the Kubernetes cluster environments as part of the CI/CD pipeline.

What is Bitbucket?

Bitbucket is a code hosting and collaboration tool based on Git that assists development teams in efficiently building, testing, and deploying software. It includes powerful features such as Bitbucket Pipelines, an integrated CI/CD service allowing automated builds, testing, and deployments from within your repositories. Bitbucket simplifies the development lifecycle with its robust integration capabilities and seamless workflow management, making it an ideal choice for teams implementing DevOps practices.

By integrating Bitbucket Pipelines and Testkube, you can utilize test automation and make sure that every change to the code is tested before it goes live, making things faster and more reliable.

Benefits of Using Testkube with CI/CD Pipelines

The integration of Bitbucket Pipelines and Testkube offers several benefits. Below are listed a few benefits:

• Automated Testing: Run the tests automatically on every push, lowering the risk of any error.
• Seamless Integration: Improve the CI/CD workflow by seamlessly integrating the Testkube and Bitbucket pipelines.
• Improved Code Quality: This integration makes it feasible to identify bugs beforehand, which substantially enhances the quality of the code.
• Enhanced Security: Testkube ensures that your tests run securely by preventing unnecessary exposure in the CI/CD pipeline, which improves overall system security.

Read more about the benefits of using a tool like Testkube to run your tests from your CI/CD pipeline in the Stop Running Tests with your CI/CD

Let’s now understand how to integrate Bitbucket Pipelines with Testkube for a reliable and smooth testing process.

Integrating Bitbucket Pipelines with Testkube

• Create a repo with a test workflow file. In this case, we’ll use the k6 test workflow.
• Configure a pipeline with this repo and trigger it when any new pull request is created.
• Add our Testkube target cluster’s configuration values in this pipeline.
• The pipeline then deploys the k6 test to our configured Kubernetes cluster and executes it.

Testkube’s integration with any CI/CD tool aims to make the testing process more seamless and efficient. Below is a high-level overview of the actions that we’ll perform:

Prerequisites

Once the prerequisites are met, you should be able to launch a target Kubernetes cluster with a Testkube agent setup and configure a Bitbucket pipeline to deploy and run a k6 test workflow on the target cluster.

To create the API token, refer to our API Token document. To find the Org ID and environment IDs, log in to your Testkube Dashboard and select Settings from the menu bar.

In addition, these IDs and tokens must be stored as variables in Bitbucket to ensure their safe access and use during pipeline execution. For more information, refer to the documentation on Bitbucket variables and secrets.

Creating a Test Workflow in Testkube

Testkube Test Workflows are an easy and quick way to define and run tests within a Kubernetes cluster. These YAML-based specifications enable the test to be defined in a single file containing the test, images, artifacts, and resource parameters.

It allows you to create multi-step test workflows that thoroughly manage end-to-end requirements while offering you more freedom and control over the tests.

Discover and learn more about Test Workflows, which enable you to perform efficient and seamless testing in Kubernetes frameworks.

• Login to your Testkube dashboard and navigate to the Test Workflow section.
• Click the “Add New Test Workflow” button.
• A “Create a Test Workflow” dialog box appears, and you can build the sample workflow by selecting the “Start from an Example” option.

The first step is to create a test workflow. Here’s how you can create a test workflow using an example:

Here’s a sample Test Workflow I created for k6:‍

We’ll save this k6 test workflow configuration as a YAML file in our Bitbucket repository and configure a Bitbucket pipeline.

Configuring Bitbucket Pipelines

Log in to your Bitbucket account and create a repository containing the test workflow file.

Once your repo has been created, go to Repository Settings and enable Pipelines. It will generate a sample `bitbucket-pipelines.yml` file with some basic configuration.

‍

We’ll go ahead and configure the pipeline to trigger whenever a new PR is created.

• Sets up a job to connect to the Testkube cloud using the Testkube API key, organization, and environment ID.
• Creates and runs the k6 test workflow named testworkflow-actions.
• testkube version: Checks whether the Testkube CLI is properly installed.
• Runs the test workflow

The file should contain the pipeline configuration, which includes the image to be used, the build steps, and any necessary environment variables or custom configurations.
Let’s look at a bitbucket-pipelines.yml file.

The workflow described above performs the following actions:

Note: The — update flag in the run test workflow command ensures that the test workflow is updated with the latest changes and execution history is preserved

Triggering Testkube Test

Make changes to the bitbucket-pipelines.yml file in the repository, and commit the changes by raising a pull request to trigger the pipeline.

Once the pipeline is triggered, Bitbucket Pipelines will execute the test steps specified in the configuration file.

‍

‍

On the Bitbucket interface, click the Pipelines option to view your pipeline’s status, detailed information about the log generated during its execution, and other relevant information.‍

Based on the configuration, we can see that the pipeline triggers with every new PR; it connects to our target Kubernetes cluster, deploys the k6 test from the repo, and executes the test.

Monitoring the Test Workflow

You can monitor the workflow’s progress and report in the Testkube dashboard or using the Testkube CLI. Let’s see how to check the status of the Test Workflow using the dashboard.‍

After the execution, Testkube collects all artifacts, including a stats report with all outputs and results.

The above example demonstrates how simple configuring Testkube with Bitbucket Pipelines is. One can execute advanced scenarios by modifying the workflow and configuring repositories according to their specific requirements.

Summary

We have learned how to set up the Testkube testing workflow with Bitbucket pipelines and how it enhances our testing experience. By integrating the automation capabilities of Bitbucket Pipelines with the testing capabilities of Testkube, you have not only automated the testing process but also created a robust testing framework for the development pipeline. Additionally, this integration not only allows a seamless and efficient testing process but also ensures consistency and reliability in the CI/CD workflows.

So, what are you waiting for? Go one step further and use the collective power of these two to scale your testing processes and deliver reliable releases more quickly.

‍ Reach out to me to discover how Testkube can transform your testing strategy. You can also join our Slack community to start a conversation or read Testkube documentation to see how Testkube can enhance your GitOps testing workflow, ensuring seamless, efficient, and automated testing within the Kubernetes environments. The future of software testing is here. Are you ready to be a part of it?

In today’s fast-paced world of software development, every build and new feature must be thoroughly tested to ensure a seamless experience and an efficient delivery. Continuous testing enables teams to automate test execution at all stages, detecting issues early and confidently delivering reliable updates. Integrating testing with your CI/CD tools ensures that every code submission triggers the necessary tests, accelerating development while allowing you to focus on other vital tasks.

Originally published at https://testkube.io.

Unleashing the Power of CI/CD Testing with Bitbucket and Testkube was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Test Execution in the STLC

In our previous article The software testing life cycle (STLC) is a well-established step-by-step breakdown of testing activities in the software development life cycle (SDLC). At a high level, the STLC consists of the following steps:

• Requirements analysis: Understand what needs to be tested.
• Test planning: Plan how the requirements will be tested.
• Test case development: Write actual test cases.
• Test environment setup: Prepare your test environments.
• Test execution: Execute your tests in your test environment.
• Test cycle closure: Ensure that all testing activities are completed.

As you can see, test execution is a specific step in this life cycle, and it in itself is a rabbit hole to delve into. Let’s do just that.

A 5-Step Framework for Test Execution

Executing tests and consequently managing execution results in a scalable and efficient manner turns out to be a complex undertaking as the number of testing tools, CI/CD systems, engineers and applications grows in your organization. Let’s start by breaking down test execution into five steps to help decide how to execute tests in a way that can grow correspondingly.

1. Define: How will you define the execution of your tests?
2. Trigger: How will you trigger your test executions?
3. Scale: What scalability needs or constraints do you have for test execution?
4. Troubleshoot: How can you effectively troubleshoot your (failed) test executions?
5. Report: What reporting do you need to plan your (future) testing activities?

Let’s dig into each of these steps in a little more detail to help you understand what questions you might need to answer within your team.‍

• Define — How are you going to run your tests in a consistent way, considering:
• From CI/CD tooling as part of your build and deploy processes?
• Your existing (and future?) testing tools and versions
• Input data for data-driven testing
• Test orchestration: for instance, execution of multiple tests in a coordinated way, possibly across multiple/remote environments
• Trigger — How will you trigger the execution of your tests?
• From CI/CD tooling as part of your build and deploy processes?
• Scheduled execution at regular intervals? (For example, “Run our security tests on a daily basis.”)
• Based on external/internal asynchronous event triggers or webhooks? (“Re-run end-to-end tests whenever these components are updated in our infrastructure.”)
• Ad hoc or manually?
• Custom integrations via APIs/CLIs?
• Scale — As you ramp up your testing activities, make sure you’ve assessed:
• How many tests do you anticipate to be running at “peak testing time”?
• Do you have shared/stateful infrastructure that is shared across tests? Do you need to constrain test execution accordingly?
• Do you have very-long-running tests that either need to be:
• Parallelized to cut down on execution time?
• Scheduled asynchronously instead of run for every build?
• Should tests be running inside and/or outside your infrastructure (or both)?
• For load-testing specifically:
• How much load do you need to simulate?
• Can you use your existing/internal infrastructure?
• How can you coordinate with other (testing) activities?
• Troubleshoot — Troubleshooting failed tests can be a pain in a complex application infrastructure:
• Are the logs and artifacts from your testing tools sufficient, or do you also need logs and metrics from the application that is under test?
• Do the right people have access to logs/infrastructure to troubleshoot?
• Can all troubleshooting be done in one place or are there multiple points of access?
• For how long do you need to keep results around?
• Do logs or artifacts contain sensitive information? Do they need to be stored securely?
• Report — Ask yourself:
• What metrics do you need to track over time, and at what granularity? For example pass/fail ratios, total number of tests, etc.
• Could or should you aggregate results from different test executions and testing tools into common reports?
• Access control: Do the right people have access to reports?
• Can reports/metrics be analyzed by required dimensions, such as team/application, etc.?
• Do test execution results need to be pushed to external systems? For example: reporting, incident management, issue tracking
• How should reports be distributed internally and be accessed over time — ephemeral/long-lived URLs? PDFs? etc.

Test Execution Assessment Criteria

Apart from the somewhat tactical approach to test execution outlined above, we can define a number of criteria that need to be assessed and planned for to scale accordingly with the needs of your team and your application.

• Consistency — Getting consistent test results is key to building trust in quality metrics and downstream activities, and to that end, your test execution environments should be as homogenous as possible, given the context of your applications.
• Decoupling — Test execution should not be tightly coupled to any other specific framework or pipeline in your infrastructure. The need to run tests will shift both strategically and tactically over time, and your tests should be available for execution whenever needed.
• Centralization — While your tests might execute in multiple places in your infrastructure, managing these executions and their results in one place gives you a holistic view of your testing activities, making it possible to assess, analyze and control test execution consistently as your testing scales with your applications and infrastructure.
• Integration — Test execution commonly needs to be integrated — but not tightly coupled! — with your existing workflows and pipelines.
• The execution of tests needs to be triggerable from a variety of sources.
• Notifications of test executions or failures needs to be integrated into collaboration platforms and incident/issue tracking.
• Test results or metrics might need to be captured by external monitoring or reporting tools.

Scalability- Running test at scale is one of the most common challenges for teams embracing a proactive approach to test execution

• The need to scale individual tests horizontally to improve execution times or cover more test scenarios
• The need for multiple teams to run their tests using a constrained resource (infrastructure, shared database, etc.)
• The need to scale load tests to generate the required load to ensure the performance and stability of your applications and infrastructure
• Who should be able to run tests, see results, etc.?
• If your infrastructure needs to be configured specifically for test execution, does that have any security implications?

Charting the Course for Test Execution

Neither of the above sections is meant to be exhaustive or conclusive in their respective approach. Each application infrastructure is unique, and so will your team’s needs be on how to run tests. The main point is to make you think about test execution further than “run my playwright test in Jenkins” — as that will surely hit a dead end and stop you from scaling your testing activities in line with the evolution of your applications. A hands-on approach could be:

• Break down your testing activities into the different steps of the STLC. How are you performing each of these steps? Who is responsible? What needs do you have?
• Break down test execution into the five steps above and ask yourself again: What are your needs, who is responsible, etc..
• Factor in the test execution assessment criteria outlined above into your test execution strategy. Make sure you have at least discussed them all, even if your course of action is “ignore.”
• Make sure the right people are involved in all of these discussions (in no specific order):
• QA leads/managers
• DevOps/platform engineering
• System architecture (if needed/applicable)
• Product ownership (if needed/applicable)

Testkube for Test Execution

Perhaps not surprisingly, I’m writing this article not only to share insights into test execution, but also to show you how Testkube can help.

Put simply, Testkube is an orchestration platform for test execution in line with many (but not all) points discussed above. The five steps outlined for test execution above are cornerstones for how to work with Testkube:

• Define your test execution using a powerful Test Workflow syntax that supports any testing tool or script you might be using.
• Trigger your tests however you might need to; CI/CD, events/webhooks, CLI, API, etc..
• Scale any testing tool horizontally or vertically to ensure your applications are tested consistently and at scale.
• Troubleshoot test results using Testkube results and log analysis functionality.
• Report on test results over time to guide you in your testing efforts and activities.

And although Testkube can’t solve for every issue discussed above, it provides a grounded starting point. Try it out at testkube.io/get-started.

Originally published at https://testkube.io.

Test Execution: A 5-Step Framework for Success was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.

However, simulating production-like conditions often requires running load tests in a distributed setup, generating load from multiple sources, which is resource-intensive and requires careful orchestration of tests and resources. Thus, you need specialized tools to make that process simpler.

In this blog, we will show how Testkube can be leveraged together with JMeter to simplify the distributed load-testing process, resulting in efficient resource allocation, horizontal scalability, and simplified orchestration of tests.

Distributed Testing with JMeter

Distributed testing is executing tests concurrently from multiple machines or environments. The load is distributed across multiple nodes to more closely simulate real-life usage scenarios. This method is beneficial for testing complex systems, cloud-native, and large-scale applications like banking or e-commerce websites.

In this section, we will discuss JMeter, a distributed load-testing tool, dig deeper into its distributed systems testing architecture, and understand the associated challenges.

JMeter

Apache JMeter is an open source software for distributed, performance, and load testing of applications. JMeter supports protocols like HTTP/HTTPS, FTP, SOAP, JDBC, TCP, UDP, and much more, allowing it to support the testing of different applications. It enables distributed testing with master-slave configuration, spreading the load across multiple nodes. This enables an extensive test of an application’s behavior under heavy traffic. Let us understand the master-slave architecture supported by JMeter for distributed testing.

JMeter Master-Slave Architecture

In the master-slave architecture of JMeter, multiple users are simulated across various machines. This type of setup helps test such applications where you need to generate significant loads but have hardware limitations.

Here is an overview of each component in this architecture:

• Target: An application, service, or server under test.
• Master [Controller Node]: A controller that manages the execution of the test. It initiates the test execution, distributes the load, and collects the results from the slave.
• Slave [Worker Nodes]: A load generator that takes requests from the master, generates the load, and executes the test on the target.

How does JMeter execute a test on a target?

There is one master that handles the execution of tests using multiple remote slaves. For proper communication, the master, slaves, and target must be on the same network. The master communicates with the slaves using Java RMI(Remote Method Invocation). Each of these slaves generates a load and executes tests. The test execution by all the slaves on the target starts at the same time. The execution details are sent back by the slave to the master, who performs the result aggregation.

Challenges with distributed testing with JMeter

While this setup seems easy, there are some challenges associated with it:

• Resource allocation overhead: Even though the master-slave architecture distributes the load, which reduces the chances of over-utilizing a single slave, it is quite challenging to allocate resources to the slaves for optimum usage.
• Complex master-slave configuration: Ensuring the same version of JMeter on all the nodes, configuring the network to allow RMI traffic, and synchronizing time between nodes is complicated.
• Monitoring and debugging issues: JMeter requires configuring external plugins or tools for real-time analytics or monitoring. With a large-scale system setup and complicated configurations, this becomes more of an overhead for the team.

Thus, for performing distributed load testing on complex systems in a cloud-native environment, you require a tool to help with optimum resource allocation, easy configuration of master and slaves, scalability, and proper observability. The good news is that Testkube can do it all and gives you both a Dashboard and command line utility for test orchestration.

In the following section, we will take a detailed look at the features of Testkube that can help achieve better test orchestration for JMeter distributed testing.

Automate JMeter Distributed Testing with Testkube

Testkube is a test orchestration and execution platform that leverages the power of Kubernetes for testing cloud-native applications. It allows you to automate test execution irrespective of your testing framework, tool, or script using a powerful Test Workflows engine, and leverages a unified dashboard, for centralized test creation, execution, and result aggregation, helping you manage tests better and gain observability in overall testing.

How does Testkube automate JMeter distributed testing?

Testkube supports all popular testing frameworks, including JMeter, for distributed load testing. Testkube runs the test directly in your Kubernetes cluster, ensuring secure execution of your system or new features. Here are some of the benefits that Testkube offers when it comes to running distributed JMeter tests:

• Easy RMI configuration: Testkube simplifies the major challenge of configuring RMI in JMeter’s master-slave architecture by automating the network configuration needed, such as firewall and port setup. It also automates the installation of the same JMeter version on all nodes, saving time and reducing the risk of error. Testkube provides a sample configuration template that you can use to get started easily.
• Scalable system design: With Testkube, you can leverage Kubernetes native scaling capabilities and dynamically scale the number of slaves without changing your test scripts. Testkube utilizes the Kubernetes’ resource management to distribute load. This way, you can easily simulate a large amount of traffic to test your system or application without worrying about resource allocation.
• Centralized monitoring dashboard: While testing, it is important to have the ability to view the details of previous test executions and current ones for comparison. In the case of JMeter, you also need test execution details, errors, and performance metrics per slave. The Testkube Dashboard aggregates all the test executions in real-time and helps you track them for easy monitoring and debugging.

Testkube handles all the complexities of performing distributed tests in JMeter. This lets you focus on developing the application and testing rather than figuring out the infrastructure. Let us see in the coming section the JMeter distributed testing in Testkube.

How do you execute JMeter distributed testing in Testkube?

Using Testkube Test Workflows, we are going to execute the test with JMeter. We have created a JMeter test that runs on our Testkube website and performs the distributed test. Let us get started with the prerequisites and create a Test Workflow to execute the test.

Prerequisites

The basic requirements while configuring the master-slave architecture in JMeter with Testkube are as follows:

• A Kubernetes Cluster(We have used Minikube here.)
• A Testkube Pro account (free plan is fine)
• The Testkube Agent is installed on the cluster.
• A Testkube API token with Admin Access rights.‍

Once the prerequisites are in place, you should have a target Kubernetes cluster ready with a Testkube agent.

Creating a Test Workflow

In the Testkube Dashboard, we are going to create a Test Workflow.

1. Login to Testkube and select Workflows from the left menu bar.
2. Click on “Add a new Test Workflow” and select “Start from an example”.

In the Testkube Dashboard, we are going to create a Test Workflow.

3. Scroll to the right and select “Distributed JMeter”. Testkube loads an example YAML.

4. We are going to update this YAML to also process the JMeter artifacts. Provide the YAML given below:

kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: distributed-jmeter-example-config-artifacts
  namespace: testkube
spec:
  config:
    slavecount:
      type: integer
      default: 3
  content:
    git:
      uri: https://github.com/kubeshop/testkube
      revision: main
      paths:
      - test/jmeter/executor-tests/jmeter-executor-smoke.jmx
  container:
    workingDir: /data/repo/test/jmeter/executor-tests
  services:
    slave:
      use:
      - name: distribute/evenly
      count: config.slavecount
      logs: always
      timeout: 30s
      image: anasoid/jmeter:5.6-plugins-21-jre
      command:
      - jmeter-server
      - -Dserver.rmi.localport=60000
      - -Dserver_port=1099
      - -Jserver.rmi.ssl.disable=true
      readinessProbe:
        tcpSocket:
          port: 1099
        periodSeconds: 1
  steps:
  - name: Run tests
    run:
      image: anasoid/jmeter:5.6-plugins-21-jre
      shell: |
        jmeter -n \
          -X -Jserver.rmi.ssl.disable=true -Jclient.rmi.localport=7000 \
          -R {{ services.slave.*.ip }} \
          -t jmeter-executor-smoke.jmx \
          -j /data/artifacts/jmeter.log \
          -o /data/artifacts/report \
          -l /data/artifacts/jtl-report.jtl -e
    artifacts:
      paths:
      - /data/artifacts/**/*
status: {}

You can view the same running in the Testkube Dashboard as shown below.

Let us split the above file into parts to understand the changes specific to JMeter.

1. Defining the slaves to have a dynamic value: Here we have used `config` to define the slave count. The name of the field is set as `slavecount` of type `integer`. We have set the default value as 3. This will be updated with the value you provide at the time of execution. Testkube allows easy scalability without touching the test script.

spec:
  config:
    slavecount:
      type: integer
      default: 3

2. Path to the test that will run on target: Using the `content`, we have defined the Github repository path that has the test that will be executed on the target. In this test, the target is the Testkube website: `testkube.kubeshop.io`. With this, Testkube helps us version control the tests.‍

content:
  git:
    uri: https://github.com/kubeshop/testkube
    revision: main
    paths:
    - test/jmeter/executor-tests/jmeter-executor-smoke.jmx
container:
  workingDir: /data/repo/test/jmeter/executor-tests

3. Configuring the slave: Testkube creates JMeter slaves as Kubernetes pods. The number of slaves helps decide the number of pods to spin. Here, we have passed the JMeter image to be used while creating the containers in the pod. Also, we have defined the command that will run when each container spins up.

services:
  slave:
    use:
    - name: distribute/evenly
    count: config.slavecount
    logs: always
    timeout: 30s
    image: anasoid/jmeter:5.6-plugins-21-jre
    command:
    - jmeter-server
    - -Dserver.rmi.localport=60000
    - -Dserver_port=1099
    - -Jserver.rmi.ssl.disable=true
    readinessProbe:
      tcpSocket:
        port: 1099
      periodSeconds: 1

You can see here the minimal configuration that needs to be done which is already part of the example that loads in the Testkube Dashboard when you select to get started with an example. Testkube internally does the firewall configuration to ensure secure and seamless communication between slave and master.

4. Running test and processing the artifacts: The final step is to define the test. In the master-slave architecture, the master initiates the test execution on the slaves using the `jmeter` command with arguments that allow it to connect to the created slaves We also add arguments for generating a report for our execution, which we then capture using the artifacts configuration.‍

steps:
  - name: Run tests
    run:
      image: anasoid/jmeter:5.6-plugins-21-jre
      shell: |
        jmeter -n \
          -X -Jserver.rmi.ssl.disable=true -Jclient.rmi.localport=7000 \
          -R {{ services.slave.*.ip }} \
          -t jmeter-executor-smoke.jmx \
          -j /data/artifacts/jmeter.log \
          -o /data/artifacts/report \
          -l /data/artifacts/jtl-report.jtl -e
    artifacts:
      paths:
      - /data/artifacts/**/*

We used here the sample provided by Testkube to run distributed testing in JMeter and tweaked it to process the artifacts.‍

5. From the dropdown, select “Create” to create the test workflow.‍

‍

6. We have set the default slave count as 3. On the prompt, enter the number of slaves you want to be created and click on “Run”. We have entered the value as 6 here.‍

7. Testkube does the automatic resource allocation and creates 6 slave nodes along with performing the test execution as shown below.

After the test execution is completed successfully, you can view the execution logs of each slave by selecting slave in Testkube Dashboard. In the image below, we have shown the execution logs of slave #1.‍

Viewing the artifacts

Artifacts help with the analysis of an application under heavy load. Testkube integrates with JMeter and loads the UI which gives a detailed view of the application test. In the Testkube Dashboard, click on “Artifacts”.

From the artifacts dropdown, select report and click on index.html.‍

Testkube loads the JMeter Dashboard as shown below. This has a detailed view of the Application Performance Index, Requests Summary, Statistics, etc which you did not have to set up explicitly. Testkube configures all this for you, making it easier for you to gather results.

Testkube provides utilities to make testing easier for you so that you can focus on the application development better.

Executing the Test Workflow using Testkube CLI

Testkube provides the ability to connect to the Testkube account using the command line. In the previous section, we created and executed the Test Workflow from the Testkube Dashboard. We will learn here how to manage the Test Workflows using Testkube CLI. Install the Testkube CLI on your machine and configure the API Token. Once the context is set, you can view your Test Workflows and run them using the following command:‍

testkube run tw  --config

For our use case, here is how the execution from the CLI looks like:

$ testkube run tw distributed-jmeter-example-artifacts --config slavecount=4
Context: cloud (1.17.54)   Namespace: testkube   Org: SONALI SRIVASTAVA-personal-org   Env: SONALI SRIVASTAVA-personal-env
--------------------------------------------------------------------------------------------------------------------------
Test Workflow Execution:
Name:                 distributed-jmeter-example-artifacts
Execution ID:         66a2315f7fc8371cd690a9d3
Execution name:       distributed-jmeter-example-config-artifacts-2
Execution namespace:  testkube
Execution number:     2
Requested at:         2024-08-13 21:05:03.083826997 +0000 UTC
Status:               queued

You can view the same running in the Testkube Dashboard as shown below.‍

‍This level of automation, from creating to executing the Test Workflow, allows you to work on the test and leave the execution to Testkube. With Testkube, we could run the JMeter test with minimal configuration and view the application performance-related metrics.

Conclusion

JMeter is a commonly used tool for distributed load testing. Testkube abstracts the complexities associated with it and handles the network configuration, resource allocation, and processing of the artifacts. In this blog, we have seen, using an example available in the Testkube Dashboard, how we can easily set up the master-slave architecture for distributed testing of an application with JMeter.

Using the Testkube Dashboard, we were able to configure and execute distributed JMeter tests with so much ease, and Testkube helped us view the execution logs of each slave and an aggregated results report which helps debug issues quickly.

By leveraging the Kubernetes features, Testkube simplifies the process of configuring slaves and gives the power to dynamically set the number of slaves. Testkube also supports k6 for distributed testing. So, to standardize testing for you, we invite you to try Testkube today. Witness firsthand how Testkube simplifies and empowers your testing process with its Kubernetes-native test execution capabilities. Join our active Slack community for guidance and support.

Originally published at https://testkube.io.

Distributed Load Testing with JMeter in Testkube was originally published in Testkube on Medium, where people are continuing the conversation by highlighting and responding to this story.