What Does Kubernetes Mean for Software Testing?

Kubernetes has changed the way we think about running containers at scale. So far, developers and operations teams enjoy working with it as it enables agile, resilient delivery of their applications in the cloud and beyond.

But what does it really mean to have Kubernetes as a container management system for the QA team, and how can they make the best use of this technology?

In this article we will respond to those questions. More specifically, we will explain what has changed and what's different in terms of testing workflow. We will see that in essence, software testing hasn’t really changed, but the execution model has gone to the next level, so testing teams need to adapt and move forward with a new mindset.

Software testing provides an objective view of how software behaves in real time and how much it aligns with business requirements. Note that this description does not mention anything about containers or container orchestration systems (or cloud or any similar term), and there is a reason for that.

As previously discussed, containers do not change functionality, so subsequently, any container management system that works on top of containers maintains that truth.

What has changed is the execution model of the different types of testing. As each type of testing (unit, integration, system) requires different setups and environment and configuration parameters, it takes time and effort to automate those stages. However, with Kubernetes, we can have a platform that scales based on our needs and demands. We can leverage that to incorporate more advanced testing scenarios such as chaos engineering or A/B testing on real production sites, so as to reduce risk and make our systems more resilient to failure.

Kubernetes helps with software testing in many ways. I’ll explain the most useful ones.

First and foremost, as Kubernetes allows us to spin up a number of container instances with different scaling policies, it’s a perfect candidate for CI/CD jobs and activities, and it’s widely used in production. For example, in our environment, we created pods that run Jenkins slaves for every commit or PR submitted, and at the end of each job, they are terminated. Kubernetes makes it easy to submit jobs (and let it find the way to complete them).

So if you have a suite of automated tests and scripts, they can be packaged in containers and run as part of a build pipeline against your deployment containers, thus producing more consistent results. In addition, tests can be tagged based on specific parameters such as headless:firefox and headless:chrome for running headless testing scenarios on Firefox and Chrome respectively. These can be run in parallel using Kubernetes jobs, thus reducing their running time.

QA teams are more than happy to have identical production environments at their disposal for testing purposes and automation. With Kubernetes' advanced container orchestration capabilities, we can create whole test environments that share the same manifests with the production sites.

For example, in our line of work, we keep up several environments, such as validation, pre-production, release-user-acceptance, and so on. Not all of those environments are up all the time, and in the past, when we needed to commit changes to production, we manually provisioned them using scripts and migrated a portion of production data to test the latest requirements. Now, using Kubernetes and Terraform, we apply the production manifest, and we can spin up a new cluster for running validation tests with no interruptions. At the end of each iteration, we destroy them, cleaning up residual files and assets.

There is an ongoing need to push testing functionality toward the earlier phases of development so that serious issues are identified and resolved before we push to production. This is where things can get tricky.

You see, the development teams have their own workflow that dictates how well a particular piece of technology can help them with their work. If we want to impose a particular workflow, such as a new testing phase to run after each commit, then it’s best if it offers instant feedback and has detailed information about the issue. The developer’s ability to reproduce an issue accurately is the first crucial step towards understanding it and fixing it.

Kubernetes here can help with the right purpose and scope. Maybe running a full Kubernetes cluster in a local machine would not be practical, but if testers and developers have a shared cluster that is tailored for easy debugging and testing, then they can both benefit from it. When a tester logs an issue, then the developer can instantly connect with the cluster and have all the information to attempt to fix it with confidence—so the QA and Dev team need to have common ground.

As new tools like Kubernetes come into play, QA and validation engineers need to incorporate them more efficiently into their automation workflows, and tackle bottlenecks. Yes — in the beginning, it will take more time and effort to migrate to that environment, especially towards shift-left testing. However, at the end of the day, the cost that we pay upfront can be regained with time savings and enhanced communication between developers and testers, so it’s totally worth it.

Theo Despoudis is a Senior Software Engineer and an experienced mentor. He has a keen interest in Open Source Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration.