Chandima Athapattu

First of all, did you ever thought of this topic as an employee who ensuring the quality of the product and worrying to release your product almost bug-free to UAT? Yes, I am talking about testers who think upside down when it comes to test planning in a new testing engagement.

“What is the architecture I am looking at?”

“It’s a microservices architecture… “

“So what it makes sense to me as a tester? Does that matter?”

If you came across with aforementioned answer you should read this else just don’t. But you might get crossed soon.

The identification of microservice architecture is clear. But testing is complex than you think. Testing a microservice architecture is still new for many testers in the industry even today. Why? Because even now, new development work starts mostly in a monolithic architecture. I am not an architecture but a professional tester. I’ll explain this the way all testers will understand.

Why are architects selecting microservices architecture?

Monolithic architecture is well known & well spread in the industry. It’s simply the whole code in one piece. There the whole system developed as a single box and deploying to production. It’s independent and interconnected. This is good sometimes excellent for small systems and as a startup. But this era it’s all about web applications and they evolving rapidly. So many of us

testing/tested systems with monolithic architectures. Companies like Amazon, eBay and google all shifted to microservices architecture. When your system expanding, old fashioned monolithic architectures cannot resist the load. Unable to plug

new technologies. Unable to utilize them in your CI/CD programs because even a little change/update to the system, you need to deploy the whole system to the production which is as you know is hectic to do continuously.

What is microservices architecture?

The solution is indeed microservices. What are these? Your system has broken down to different services without keeping everything together on the code level. For example, let’s look at an insurance system where you will identify claims, policy coverage, alerts & notifications, new businesses & renewals into different services. Then if we consider a single service, within that it will develop the way a monolithic architecture works. But the difference is there are connections in between other microservices so designers need to carefully plan that. With this, all the microservices not need to stick to one technology or database. Developers have space to design their services separately even in different technologies. But don’t forget still this is one system. I am not going to explain further as my objective is to showcase the testing side of this whole thing.

What are the testing challenges?

So what are the challenges? Why in terms of testing systems with microservices architecture getting more complex during designing test cases and execution? There are two reasons,

• Interconnections between microservices.
• Different technologies each microservice may use.

That’s all. Here, connections between microservices something we always have to deal with in a microservices architecture. Later, the different technologies each microservice will use is something may not always happen. There can be a system built in a microservices architecture that utilizes the same technologies across the application functionalities. So testers need to understand the architecture clearly.

Web services and microservices. Two different things

Now let’s focus on the topic. How you would test a system with such an architecture? Right now some of you who read this may conflict microservices against the web services. Let me clarify the later. Web services tell us how the communication between two devices/applications held over the world wide web (www). There are two architectural styles. Simple object access protocol or SOAP and Representational state transfer or REST. REST API uses advantages of URL exposure like @path(“WeatherService”) while SOAP API uses services interfaces like @WebService.

So now you may understand that the microservices architecture is one thing and web services and API testing is one thing. Connections I am talking about is which built inside the architecture. Communication among the microservices.

How to overcome the challenges in your strategy?

To address the first challenge which I was mentioned earlier (Connections which exists between microservices) performing an integration testing is vital. Here I should highlight that it’s very important and plays a big role in your overall test suite. You should find a way in your test suite to figure out to test the connections. It can be a manual test (front-end) or an API test. Understanding the dependencies is crucial. And in integration testing, I would say API testing is more efficient. Here too you should clarify two things. Microservices and APIs (endpoints).

A particular microservice may have one or more endpoints based on the design. Or maybe there may not any endpoints connected at all. Such a microservice should have a dependency on another microservice and the later should have one or more endpoints. Sometimes there can be a dependency chain I would say. When planning your API testing you should know the microservices tasks and their dependency (if any). This is something you may not face in a monolithic architecture where such design may not exist. When we say ‘Integration Testing’, various people say various terms. But what you need to know is to cover the integration among microservices. We can call this system integration testing as well. Whatever the name says, make sure to achieve the coverage.

The second challenge I mentioned, different technologies each microservice used is something may not always happen. But you should be prepared. You need to understand the complete microservice architecture and their database connections and external communications with other microservices. Knowing one microservice doesn’t mean you understood the architecture. So your API testing and test data preparation may get vary if two microservices in the same system use two different technologies. For example, one microservice may use SQL and others use an open-source database technology. So you need to figure out how you should design and execute these test cases which is vital and will save lots of time during the test execution.

So after all, the E2E (end to end) testing is the most critical testing type when you are testing a system with microservices architecture. This is where you should test the end to end journey. Business scenarios. In your test suite, you need to identify the E2E test cases carefully. And cover majority if not all of the microservices in the system. Why E2E is this important? This is because in a microservices architecture the two challenges I highlighted. You doing system integration to cover the connections. But end-to-end testing is where you cover business flows. While covering business flows, the different technologies involved in each microservice are covered and the external connections (dependent microservices and data stores).

The solution in brief,

The conclusion is that the classic thinking of integration testing is not part of QA is somewhat not applicable here. You have to consider integration testing while doing system testing we called it system integration testing. Then the E2E testing is critical. As highlighted before, the main reason I would say that is because microservices having an external connection. And you need to think about different technologies which involved in architecture as well. There’s a strong possibility that you might deal with multiple technologies.

The test design phase is vital. You need to plan your test suite carefully. And involving QA in architecture discussions during the design phase is crucial. And please make sure to prepare your test environment as same as in production which is very important here as well.

The trend is towards microservices architecture especially when we are talking about web applications. So hope you have taken all that I have mentioned. And keep this architecture in mind because sooner am repeating, you might get crossed if not already…