Kubernetes is an all-in-one container orchestration tool that helps in the management, deployment, monitoring, and scaling of systems for containerized applications which are all packaged in one open-source system. If your organization works with containerized applications using Docker, then you would already know that things become tedious, and it becomes difficult to manage them when they scale up.
……………………………………………………………………………………………………
Classic QA Process:
Here, the end-user only interacts with the front-end user interface in both monolithic and containerized applications. Similarly, the traditional QA process can be used for containerized applications but should be seen as a subset of the QA process in the Kubernetes world. UI or API testing using tools like selenium or Rest- assured can be used for automation testing for applications running on Kubernetes, but this is a costly process that requires high investment in terms of time, money & resources. To overcome this, it requires us to look outside the box to find better solutions that can be paired up with these and provide better coverage right from the beginning. This would result in the scope of the QA process getting increased when applied to Kubernetes applications.
Enhanced QA Process (hybrid) for Kubernetes Applications:
Kubernetes applications are generally deployed using continuous integration and continuous delivery. To assist the developers in the release cycle, the traditional approach of creating end-to-end tests is not adequate and now requires QA to work very closely with developers on the tests so that it can be written quickly and executed swiftly.
……………………………………………………………………………………………………
The following are the new technologies that help in accomplishing the full potential of the QA process in the Kubernetes world.
- AB Testing
- Chaos Engineering
- Consumer-Driven Contract Testing
- Helm Tests
AB Testing:
The complexity of applications has increased vastly, and business requires constant UI updates and feedback based on the frontend changes. The business stakeholders hire marketing and research teams to attract more customers and convert more leads from different marketing campaigns.
Here Kubernetes gives us the power to leverage continuous feedback by using the customers as testers and present real-time statistics for businesses to make decisions in real-time
Chaos Engineering:
Chaos engineering tests the resilience and weakness of a system in production by creating expected chaos in the system to verify that none of the activities has affected the performance and stability of the system. This builds confidence that the system can handle unexpected situations and that any failures that exist can be addressed before the customers face the brunt. Since they get known to the QA team in advance, it gives them the opportunity to fix those unexpected outages before they actually affect large groups of users. Some examples can include scenarios like increasing load on a Microservice, introducing DNS failures, Mimicking hard drive failure, etc.
This can be achieved by using Free and open-source tools available depending upon the cloud provider on which the system is hosted. For example, one of the better-known tools is Chaos Monkey used by Netflix for cloud-hosted Kubernetes clusters.
Consumer-Driven Contract Testing:
Often times while working with microservices, creating full end-to-end integration tests are expensive and requires high execution time. Even if you hit failures, it is hard to figure out which service is causing the failure if the complexity of the system is high. We can create Consumer-Driven Contract Testing using Pact which is available in almost all languages. It makes it easy to write the integration tests and helps us to test consumer-provider rules using JSON files.
So, what is a pact? PACT is a binding contract between the consumer and the provider, which has to be always followed. In the world of microservices, the pact is based on the API call (consumer) and response (provider). It can be done using either a single isolated microservice (while mocking the other microservices) or on a real system with all microservices running.
Why use PACT when we can write end-to-end integration tests? Well, it helps us create tests before we move to write expensive integration tests and can provide us with the general sanity of all the microservices running in our system.
Helm Tests:
Most organizations use Helm charts to deploy Kubernetes resources on Kubernetes clusters. These charts are really powerful and often contain tests written in the chart which can be used to test if all the resources got deployed successfully to our Kubernetes cluster.
Since Helm tests use a scripting language to perform basic sanity checks on the deployed resource, we should leverage the tests provided by popular charts over the internet. In case, you are making in-house helm charts, then you might want to skip this for some better integration test since tests written in scripting language can be difficult to write and maintain.
……………………………………………………………………………………………………
With the fast evolution of the application architecture and introduction of DevOps culture, the traditional QA process is not able to provide the same value for money and is often seen as one of the bottlenecks when it comes to the release cycle. Hence, QA must design and plan their framework to provide a blend of fast test results and improved end-to-end integration tests. The role of QA is now changing from Quality Assurance to Quality Assistance. Since the QA process has to be optimized as per the AUT, this article hopefully has helped you in identifying the process of a robust end-to-end QA framework for applications running on the Kubernetes cluster.
……………………………………………………………………………………………………
The views and opinions expressed in this article are those of the author. To know more about our company, please click on Mindfire Solutions. For over 20+ years now, we have been the preferred Software Development Partner of over 1000+ Small and Medium-sized enterprises across the globe.