Study project about QA strategy for microservices projects

Complementing what I mentioned about the E2E tests above:

I tried to list which details could be identified in the E2E test, and not by the other tests, specifically for my context. I took as an example, the functionality to create a purchase order, where the “shop” module will perform a synchronous communication with the “inventory” module and an asynchronous communication with the “shipment” module.

  • Timeout in synchronous communication;
  • Inventory module is not running when creating the order;
  • Problem creating the topic in the Kafka queue;
  • Communication / configuration problems between the modules’ containers;

I see that the second and fourth points could be solved with a health check and more monitoring resources of the application. The third point also I imagine that we can have health check from the queue to ensure that there will be no failure at that point;

The first point (could be related to network fluctuations), could be partially solved with some retry policies and retry polling for this synchronous communication.

I also think that if I had an API gateway that intermediated all the direct communication to the modules, we could have an extra value with a possible E2E test (Another point of possible configuration and infrastructure problem);

My question is: Is there any other problem that the E2E test could identify that I did not listed there? Speaking specifically only of this context of my application, where we already have unit tests, integration and contract already well structured

3 Likes