Test automation with AI starts with architecture

AI can write code at lightning speed, and that includes test automation code. But producing code faster doesn't automatically give you better tests.
‍

When AI builds a website for you, it's relatively easy for a human to check whether the result does what you asked. With test automation, that's harder. An assertion can look technically correct but verify something other than what was functionally intended. A test can turn green without checking anything of real value. Especially when the person giving the instruction can't fully assess the generated code themselves.
‍

That is why, for us, test automation with AI doesn't start with code generation. It starts with architecture.
‍

AI has to work within the architecture
‍

At Cerios we use SPARTA: Simply Powerful Automated Regression Test Architecture. On top of that, we developed Spartaficial: the AI layer that lets agents use our existing automation capabilities.
‍

We don't give an agent an open-ended instruction like “just go ahead and automate this process.” The agent has to follow the same architecture and building blocks as our automation engineers.
‍

That control starts before the agent even begins to execute. We use skills to set guardrails. A Grill Skill, for example, first challenges our own brief. What exactly do you want to test? What is the risk? What actually needs to be verified? What assumptions are you making?
‍

So the agent doesn't take off just because someone types in a prompt. The brief has to be sharp enough first.
‍

That is a key principle for us: not just human in the loop, but the right human in the right loop.
‍

Browser, API, mobile and Windows desktop
‍

A lot of modern test automation starts with browser and API. But business processes don't stop there.
‍

A process can start in a web portal, move through a landscape via APIs and events, and end with the result showing up in a native mobile app or Windows desktop application. On top of that, you may need checks on databases, messaging or via shell commands.
‍

That is why we've made multiple automation engines available within the same architecture. Native mobile and Windows desktop are up and running too.
‍

That last one is something we're especially proud of: agentic Windows desktop testing.
‍

To the agent, these aren't separate test tools that each require their own way of working. They are capabilities available within the same architecture.
‍

This means an agent can perform an action in a browser as user A, analyze what happens across an event-driven architecture, and then check in a Windows application as user B whether the process arrived correctly.
‍

Analyze first, then build a regression test
‍

This agentic analysis now works in practice.
‍

The agent can open applications, interact with them and gather relevant information along the way. We deliberately aim to be token-aware, which means being careful about what goes to the language model. Not every DOM, desktop snapshot or full technical context needs to be sent to a language model every time. The agent gets the information it needs at that moment.
‍

During the analysis, the agent learns how the process runs through the chain. It then uses the existing SPARTA building blocks to turn that into a maintainable regression test.
‍

That difference matters. The end result isn't a standalone AI script that happens to work today. It becomes part of the same automation architecture as the rest of the test framework.
‍

Value in complex process chains
‍

We now use this approach at several organizations and across different domains, including pensions, energy, healthcare, financial services and complex government and infrastructure chains.
‍

That is exactly where a business process rarely consists of a single screen or a single technology. Event-driven architectures, different user roles and multiple application types all come together.

AI helps us analyze and automate these processes faster. The architecture, skills and existing building blocks make sure that speed doesn't come at the expense of control.
‍

For us, that is the essence of Spartaficial: not having AI write as much test code as possible, but letting AI make controlled use of automation knowledge that is already captured in the architecture.

‍

‍