Diasoft automated API and event tests with AI and shifted QA's role toward business logic

Diasoft shared how it integrated an LLM-agent into the development pipeline and almost removed manual test writing from QA-teams for complex APIs and events. The system accepts test-cases in business language, automatically assembles the necessary contracts, generates code, runs it on the test bed, and refines it to stable execution.

Why Templates Were Insufficient

Previously, the company automatically covered mainly typical CRUD operations and standard events. For such scenarios, templates were sufficient because the logic repeated from service to service. But the real value of products does not lie in simple reading and writing data, but in business operations: calculating percentages, applying commissions, processing limits, launching chains of related actions. These are exactly the parts that are usually hardest to test, and they most significantly slowed releases when tests had to be written manually.

Diasoft relies on a low-code platform Digital Q.Archer, where API and event contracts are stored. This is important because the LLM works not from random descriptions or outdated documentation, but from a formalized service model. This allows the system to better understand which endpoints and events truly relate to the scenario, and the tester doesn't spend time manually parsing dozens of interfaces and understands the context of the business operation faster.

How the Agent Works

The key idea is that AI is not extracted into a separate chat next to development, but is embedded into the Digital Q.DevOps platform as a full-fledged automated testing agent. An orchestrator directs the model, validates the code against internal rules, sends the test to a real test bed, and returns errors back into the generation cycle. This way, the LLM doesn't just write a draft, but goes through the same path that an engineer usually follows during debugging.

"AI doesn't just write code 'into a drawer', it immediately runs it on

a test bed".

In general terms, the pipeline looks like this:

• the tester selects a service and formulates a case in business language
• the orchestrator pulls Swagger and JSON-schemas of events from Digital Q.Archer
• the LLM selects relevant endpoints and events for the scenario
• the model generates a Groovy test, and the platform validates it against domain rules
• the code runs on the bed, and when it fails, it is refined based on logs until it passes stably

After successful execution, the system adds service labels and publishes the ready test to the product's Git repository.

Groovy was chosen for tests because it is close to Java, which most of the company's microservices are built on, but the approach itself is not tied to a single language.

Diasoft separately emphasizes the complexity of event testing: it is not enough to call an API, you also need to catch a message in the broker, check the structure, and ensure that the content matches the business scenario and the expected result of the operation.

How the QA Role Changes

The most noticeable effect is the shift in the tester's role from code writing to requirements management. Now the quality of the result depends more on how precisely the specialist described the business scenario: what should happen, under what conditions, and what result is considered correct. If the instruction is vague, the model will select the wrong endpoints or check the wrong conditions. If the scenario is described clearly, the path to a ready autotest is noticeably shorter.

It is precisely the formulation that becomes the new working tool for automation.

This also entails a new area of responsibility for QA. For the tester, it is no longer so important to carefully review the generated code line by line as it is to check the meaning of assertions and ensure that the test truly proves the necessary business logic. Essentially, QA becomes the acceptor of AI work and a subject matter expert. There is less routine coding, but higher demands on understanding the product, integration contracts, and the quality of the requirements themselves. This is closer to scenario review than to manual programming.

What This Means

Diasoft demonstrates a practical scenario where LLM is useful not as an assistant for a single developer, but as part of a managed engineering pipeline. If a company already has formal contracts, test beds, and validation rules, automated test generation can be moved from experiment to industrial process — especially for complex APIs and events that previously almost always remained manual work. This is especially noticeable in financial and integration systems.