Is it easy to open a box, or how to test more than 10 services at once

What can you come up with here and how to make the already busy life of testers easier? When testing new releases, we use all classic types of testing: load, functional and their automation, destructive, tests with consumers. But we wanted more! “How to increase the speed of testing and reduce labor costs for this?” – this question stuck in our heads. And so, after some time, we came up with an idea – to develop a Synthetic Platform V application.

What is Synthetics?

The definition from the documentation states that a Synthetic Application is “a set of tools for testing platform services that implements integration business scenarios that simulate a real consumer”. In fact, our Synthetics is a small application deployed in the cloud. Everything here is classic: OpenShift for containerization, Egress/Ingress for organizing traffic and all the other necessary entities.

How does she test?

To test the services, we developed a large integration scenario, which includes basic banking operations: opening an account, transferring funds, statements, payments and others. Synthetic scenarios emulate consumer requests as much as possible and use several platform products at once.

As part of fulfilling the request, we turn to certain Platform V services that have already been integrated with our application. For example, in the “create an account” scenario, the Synthetic application calls about 10 services in one request, similar to how real consumers of the platform would do it.

Here are some of the services involved:

  • DataSpace is a service for working with data (similar to Hibernate).

  • Audit is a service for recording and long-term storage of information security events.

  • One‑Time‑Token is a tool for access control.

  • Archiving is a service for archiving and transferring data to an analytical platform.

It is clear that it is impossible to check all the functionality of the service during the execution of one request. Therefore, our scenarios test the functionality of the main, basic functions of the product.

What are the advantages of this approach?

Among the advantages of our Synthetics are the following:

  1. Atomicity. Many services can only exist within consumer products. Such components cannot be installed without an application using them – they cannot exist atomically. Such client modules are often difficult to test manually. And our application is the optimal solution for checking them.

  2. New testing layer. Since we, like real consumers, roll out in our own space, we have our own CI/CD process in which we can catch installation defects that arise.

  3. Integration. In addition to all of the above, we check direct inter-service interaction: authorization module, data replication services.

But it's not that simple…

In fact, the section about problems is the most painful for us 🙂 We are one of the first to receive updates and connect new platform services as a consumer. That is, we collect all errors, shortcomings, and typos in full. These include problems with documentation, installation problems, and differences in environments.

During the work on Synthetics, quite a lot of funny situations happened. But perhaps one of the funniest cases we came across was the answer to the question: “Why is the service still not working?”. “The problem now is that you have connected everything that is indicated in the documentation”– the escort answered us calmly.

But, on the other hand, every problem is a challenge. And since we have a lot of them, we learn quickly. Over the past year and a half, we have transformed from ordinary Java developers into Java developers who understand CI/CD processes, certification and security processes, infrastructure administration and, most importantly, have strengthened our nervous system!

Well, the main thing that helps us endure all adversity is the belief that we can make the product better. And, we are not afraid to say this, the understanding that we stand guard over the consumer.

Subtotals

So, the bottom line is that over the past year and a half of life, more than 80% of Platform V services have been connected to our application. Which led to:

  1. Significant reduction in testing time on consumers. For integration testing it decreased by half, and for Smoke testing by 4 times.

  2. Expanding coverage, including the integration layer and CI/CD processes.

  3. Simplifying the installation process for the direct consumer of the service.

For the future, we have set ourselves the goal of covering 100% of the platform’s services and developing a number of application templates so that connecting new services takes a minimum of time. Since we are the first to “touch the product,” we dream of making this path easier for future consumers.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *