What to Do When You Don’t Have Time to Test Your Microservices
In the course of modern times, we are all busy with tickets piling up and bugs that need fixing, not to mention the deadlines to be met. We all know there are things that are left for later or for when we have the “time.” Sadly, software testing is often seen as one of those things — saved for later and not given the amount of attention it needs.
This is especially true for Kubernetes and in the microservices architectures, where implementing tests at scale comes with a high degree of complexity. There are many different testing tools that companies can use, depending on the test automation approach, maturity, and sensitivity to quality. Each test automation tool integrates differently with a CI/CD pipeline and addresses various needs — frontend, API, load, data integrity, security testing, etc.
Knowing where to put your effort when it comes to testing your applications is paramount.
Let’s look at how to use your precious time effectively and where to focus your efforts when it comes to testing. We’ll discuss what you should prioritize and review examples of what you should and should not test.
How Do I Prioritize Testing?
Here’s a formula to help you decide what tests your team should prioritize:
Priority = Risk x Criticality / Complexity
Let’s go through each of the variables.
- Complexity represents how complex it is to test a component. In this context, it includes the test automation part using your CI/CD, plus how complex it is to create tests using your available testing tools and/or language.
- Criticality relates to the effect that an issue that’s working incorrectly in your system will have on your business.
- Risk is how likely a bug or incident will happen on a certain component. Do you think that component is robust or that it’s a flaky system that is prone to stop working?
Prioritizing tests at an early stage of your product is very important since development speed and quality are things that will be crucial for your success. When you finish creating your Kubernetes clusters to deploy your applications and set up the first steps of your CI/CD pipelines, it is important to have a plan in place to test your applications. It may be a good exercise to get with your team, make a list of things you should test and use this formula to prioritize. You could use a scale of 1 to 10 for each of the variables.
Things You Should Not Test
This may seem obvious, but I’ve seen developers invest effort into edge cases that are unlikely to happen. They have minimal impact on a product, yet people spend a considerable amount of time creating tests for them. Or how about testers creating tests for components that rarely change or have minimal impact on the business, especially if they require a nontrivial amount of time to implement.
Side comment: Encourage your business people, developers and testers to talk more to each other.
Things You Should Test
For any product, I’m sure your product manager or the person leading your project has figured out the user journey(ies) that 80% of your users will take. This includes the so-called “happy path.” Try to understand what that path is, because bugs there will have the biggest impact on the success of your product. Try to understand what would be the likelihood of a user encountering a bug when using the most-used features.
For example, you know that 100% of your registered users have gone through the user registration flow. Therefore, you must be sure it’s working. Figure out the most important actions that your users are going to do when using your product. What’s something that your users will rarely do? Avoid starting with those.
The likelihood of bugs appearing in a certain component directly correlates with the number of changes that component goes through.
That’s why you should test components that change often and not the ones that are more static.
Is frontend the most critical part of your software? Are you iterating over it to figure out what the best user experience is? You could consider using Cypress to test your frontend. Perhaps your application is very API heavy and you are using Postman or SoapUI. If the latency and performance is critical for your business, using k6 or JMeter could be a way to create some tests.
The next big question would be how to orchestrate and bring it all together in the context of Kubernetes or a specific cluster — dev, staging, production, etc. This is where Testkube would come in to orchestrate and execute various test-authoring tools into your cloud native software or GitOps life cycle.
Share Your Thoughts
I’ve spent the past year talking with dozens of testers and QA engineers while building Testkube, which is a testing framework that allows you to orchestrate and execute any type of test in Kubernetes. It allows you to use any testing tool, such as Cypress, Postman, K6, JMeter, etc.
The insights I’ve written here are a collection of reflections and thoughts I gathered from my experience as a software engineer and as the product leader of a testing framework. I would love to hear your thoughts on this. If you are running any kind of application in Kubernetes, you should try Testkube. Check out our live demo here.
Feel free to reach out, or just say “Hi,” in Testkube’s Discord server, or email me directly at bruno@kubeshop.io. I look forward to hearing from you!
