What is the role of QA in testing an application having MicroServices architecture?

Question

I have to test a software application which will be developed in Microservices architecture. What are the difference in testing an application developed using Microservices architecture rather than a traditional monolithic architecture?

Answer 1

Unlike a monolithic application where you have a single point of test (more or less) in microservice you will have to test each service separately. I would suggest to consider the following points when you plan microservices-based app:

• Test automation. There will be pretty challenging to test microservice-app manually since the number of services is usually large.
• Elaborate well requirements. Put more effort on requirement preparation phase. You have test the requirements to make sure each of the service's interface is well described
• Performance. Think about how you're going to test performance of the entire solution. Since the inter-services calls are usually performed over network, the network latency often impacts the overall performance
• Think about business continuity testing. Unlike the monolithic app, each service might be deployed on a single hosting so that might happen that some of the service go down.
• Design some compatibility tests so that you are sure there is backward compatibility introduced when the interface of some service changes.

Basically when you test microservices architecture you should think more like a programmer since a monolithic app is build of library function calls which are normally hidden from a tester but a microservices app is build of microservices calls which a tester usually can have access to.

Answer 2

Basically testing is testing is testing, the technicalities could be different but the overall approach is the same. From my experience microservices architecture presents some challenges, but also a lot of opportunities.

Testing at the system and at a single module (and below) level are more or less the same as in any other system, you just need to keep in mind the rest of the world.

Integration testing becomes more complex. The term integration testing refers to the actual integration between modules, but you need to consider it even when doing module and unit testing. The complexity of interactions between modules grows exponentially, it's not just about single message functionality, it's also about timing and long series's of messages.

This means that when you start to test within the system things not only get more complex but there are simply more combinations to check.

On the other hand microservice's concepts of decoupling services and making them as small as possible makes you life testing them easier. It's (usually) easy to mock other services, sometimes as simply as replaying the right messages.

You then have a relatively simple module to tests, allowing you to, for example, split testing between testers or simpler test automation software modules.

If you need a TLDR; then it's what I have started with, treat it as any other system where the architecture is secondary.

Answer 3

In general, any application developed in micro- services architecture, also has unit, integration, end to end, UI testing.

The exact role of QA depends (as in any typical monolithic application) on how deeply he/she knows internals of the system and involved upto what layer in the architecture.

One important testing one needs to perform w.r.t. micro- services is contract testing where one writes tests to ensure that the explicit and implicit contract of a microservice works as advertised( in the documentation).

Answer 4

The role is going to be two-fold:

1. Test UI components and systems that rely on the micro services (the UX)
2. Test the micro services themselves as not all of them may be testable through the UI.

For #2 we taught our QA SoapUI (the free one).

Postman is another option, offloading off your QA onto dev to write api tests (ex httpclient) is another one..

Answer 5

I have seen microservice scenarios where

• the developers of each microservice were concerned with meeting contract tests that focussed on syntax over semantics and
• the architects of the entire system focussed on drawing the architecture.

By default, that left the QA doing many of the integration checks. Say microservice A has a field called "name", and microservice B has a field called "name", and microservice C has a field called "name". There were automated tests how A and B connect, and how B and C connect, but somebody had to go to a complete staging environment and watch how a name entered in the frontend was rendered in the autogenerated mail a couple of services later. By that point the devs had made their check marks on "contract fulfilled" and gone on to the next task.