Microservices through the eye of the QA expert – testing microservices

4 min

read

In the recent State of Microservices 2020 report by The Software House, you have picked “maintenance and debugging” as the aspect of microservices that you find most challenging. It’s hardly surprising, as most of the problems we hear about regarding microservices come from poor handling of these very areas. And it’s really worth it to work on that. TSH’s Head of QA Dawid Krala and Head of Node.js Adam Polak explain why improvements in testing microservices is the low hanging fruit you can pick up to vastly improve your architecture and the whole software development process.

Have you already got familiar with our State of Microservices 2020 report? We asked software developers (mostly Lead and Senior devs), CTOs and others with knowledge of and interest in microservices, a total of over 650 people, about this trending architecture style. In addition to that, we also reached out individually to experts from companies such as DAZN, Cooperpress, ZEIT.

We found out why they use microservices, how they use it and what stops them from taking full advantage of the benefits of microservices. We learned a lot. The report was created based on all of these findings and just may be the most in-depth and up-to-date source of knowledge about microservices trends. We highly recommend you download it for free and check it out for yourself.

Testing microservices – challenge for all, problem for many

Today however, we would like to focus on just one issue raised by the report – testing microservices.

According to our report, the topic of maintenance and debugging microservices is the least enjoyed part of working with this architecture, scoring an average of 3.4 out of 5:

The Software House’s CTO confirms these findings in the report, saying: “For the last 2 or 3 years, more and more clients have approached us and asked us for help because their in-house development teams lost control over microservice-based projects.”

This loss of control can be attributed mostly to scalability issues that stem from poor handling of maintenance and QA from the start of the project – something quite difficult to make up for later in the project.

As for debugging itself, the good news is that most developers use some debugging solutions. The bad news is that as many as 27% of them use ONLY logs. It is also by far the most popular overall method of debugging:

Asto Digital’s CTO Thomas Boltze is highly critical of logs-only approach, saying that it is consistent with the easy-to-observe pattern of building microservices first and for getting about the “consequences of going all-in with the microservices, and getting the scope of a service right”.

That’s why our report has to say. And what about TSH’s Head of QA Dawid Krala and Head of Node.js Adam Polak? Let’s find out 🙂

Unique QA challenges for microservices architecture

Dawid believes that when it comes to microservices, there are several challenges that need to be managed by a well-defined QA strategy:

The first challenge is to define the microservice architecture in a project. Before we start development, we should think about:

  • services communication, 
  • cyclic dependencies of each service, 
  • distributed logging which may influence debugging, 
  • security of each service,
  • data consistency / synchronization, 
  • performance tracing,
  • failovers of each service.

Then, once the development is in progress, we may have an issue with microservices integration testing and debugging of such services.

When it comes to the environments and deployments, the DevOps team should be involved. They need to ensure the security of such an environment. Also, they need to have a well-defined monitoring of such systems.

When working in a team, we should also remember that communication is the key. Each developer can work on a separate microservice, hence good coordination of such work is the key factor to success.

The simple solution to overcome such challenges is to have a well thought-out QA strategy for such projects. Teams working with microservices should automatically apply an approach of writing and maintaining documentation for each service. When it comes to testing strategy, the good approach may be the “testing trophy”: start from static tests, then write optimal (not too many) unit tests. Developers should focus on integration tests to ensure that services communicate without any issues. The contract tests should be considered as an important part of their testing.

Testing microservices trends

Dawid believes that microservices greatly influenced the way QA specialists work on a daily basis and that without incorporating these changes, you can’t have a good microservices testing strategy:

The Microservices architecture definitely influenced the work of QA specialists. Because microservices are deployed typically in environments that use containers like Docker, this forces all QAs to learn how they can set up such a test environment.

When we talk about testing, they should apply a ‘shift-left testing approach’, which means they should focus more on unit and integration tests rather than end-to-end testing. The unit test and the integration test capability, of course, requires programming skills. QAs should focus on contract tests as an important part of their daily activities in such projects. In order to do that, they should be able to read service documentation (ex. Swagger). 

Security and performance of such services are also important and should be on the list of testing activities of QA engineers. They also should be able to monitor such microservices (for example, with the use of the Prometheus–Grafana combination).

Strategy for testing microservices

According to Dawid, the right strategy for testing microservices should incorporate a mix of functional tests and non-functional testing and tools that can be specific to each project, as well as some standard best practices:

The most important point is to define a thought out-testing strategy (the right level of functional tests as well as non-functional testing: failovers, recovery, performance, security). It’s also vital to adhere to standardized development practices. The role of DevOps in the team can’t be overstated to keep the maintenance and debugging in check at each and every stage of the project.

Testing microservices – best practices

Let’s now take a look at the best practices:

There are a couple of rules:

  1. Define and run the right level of tests:
    1. static code tests,
    2. unit tests to validate each function of a microservice,
    3. component tests to validate service itself,
    4. integration tests, especially contract tests.
  2. Verify the right security of services.
  3. Verify performance of the system.
  4. Test how your entire system behaves when one of the services is down (for example, using the Chaos Monkey tool).
  5. Test if your system is discovered automatically when it’s up,

Testing microservices – tools

There are many tools that can help you with your testing microservices strategy. TSH’s Adam Polak lists some of the best options out there:

  • Chaos Monkey – the previously mentioned resiliency tool from Netflix will help you with managing and preventing the consequences of random services instance failure and test the behavior of each service.
  • JMeter, Locust, K6 – some of the most common performance and load testing tools and other tools like these.
  • Pact – to facilitate your contract testing.
  • Mocha, Jest, Supertest or any other popular integration and unit testing tool and microservices testing framework.

Testing microservices – summary

The QA strategy for your microservices-based project should be decided on a project by project basis. Regardless of that, it should always be incorporated from the very start of the work to prevent serious scalability issues. Many developers seem to be uncomfortable with this particular aspect of microservices and rush to build. 

But the truth is that with the right strategy and tools, it’s quite easy and the only challenge is to actually care about it enough. And giving the topic the care it deserves is the best first step to mastering it and creating scalable and efficient applications with microservices.

Be sure to read the entire State of the Microservices 2020 report to find out even more about the best practices for building with microservices in 2020, including:

  • the programming language developers choose to use most often,
  • the way developers deploy microservices to maximize their benefits,
  • the impact of the serverless approach to software architecture on microservices,
  • continuous delivery and integration,
  • trends in the consumption of APIs,
  • micro frontends,
  • and more!

You can find even more free quality resources on the latest in software development on The Software House’s website.

What do you want to achieve?





You can upload a file (optional)

Upload file

File should be .pdf, .doc, .docx, .rtf, .jpg, .jpeg, .png format, max size 5 MB

Uploaded
0 % of

or contact us directly at [email protected]

This site is protected by reCAPTCHA and the Google
Privacy Policy and Terms of Service apply.

Thanks

Thank you!

Your message has been sent. We’ll get back to you in 24 hours.

Back to page
24h

We’ll get back to you in 24 hours

to get to know each other and address your needs as quick as possible.

Strategy

We'll work together on possible scenarios

for the software development strategy in sync with your goals.

Strategy

We’ll turn the strategy into an actionable plan

and provide you with experienced development teams to execute it.

Our work was featured in:

Tech Crunch
Forbes
Business Insider

Aplikujesz do

The Software House

CopiedTekst skopiowany!

Nie zapomnij dodać klauzuli:

Kopiuj do schowka

Jakie będą kolejne kroki?

Phone

Rozmowa telefoniczna

Krótka rozmowa o twoim doświadczeniu,
umiejętnościach i oczekiwaniach.

Test task

Zadanie testowe

Praktyczne zadanie sprawdzające dokładnie
poziom twoich umiejętności.

Meeting

Spotkanie w biurze

Rozmowa w biurze The Software House,
pozwalająca nam się lepiej poznać.

Response 200

Response 200

Ostateczna odpowiedź i propozycja
finansowa (w ciągu kilku dni od spotkania).

spinner

Webinar for CTOs: How to update your company’s legacy software

Sign up