From test automation to an agentic quality loop: how Cunda works

Cunda is a product family that treats software quality as a self-improving loop rather than a one-off test phase. In the loop, AI agents produce the tests, the tests run on real and virtual devices, the code each run touched is measured, and what real users struggle with becomes the next test. This post explains how the five products fit into that loop.

Where classic test automation gets stuck

In most teams, test automation lives in four separate worlds. People write the scenarios and patch the scripts by hand whenever the app changes. Mobile tests run on emulators or on a limited number of physical devices. Coverage is usually measured for unit tests only, while a regression suite spends its time against deployed services. And when a user hits a problem in production, it reaches the test team long after it reached support.

When those worlds do not talk to each other, the team answers the same question again for every release: what did this change affect, and did we actually test it?

The six stages of the loop

Cunda answers that question in one loop. Each product solves one stage on its own and connects to the others:

1. Commit: TestingOps. Agents read the change and write test cases grounded in your requirements and code.
2. Provision: DeviceOps. Virtual phones boot from official OEM firmware and are cloned from a known state for every run.
3. Build: RunningOps. Tests written in plain language run in parallel on web, Android, iOS and API targets.
4. Test: CoverOps. Agents attached to running services record which lines of code each test actually executed.
5. Deploy: the release gate. Changed lines that no test reached show up on the pull request before the release ships.
6. Monitor: ReplayOps. Real sessions are recorded, user frustration is scored and the worst sessions become findings.

The loop does not end there. Problems found by ReplayOps and coverage gaps shown by CoverOps flow back to the TestingOps agents, which produce sharper tests for those areas in the next cycle.

What agentic testing means

Agentic testing means a team of agents with defined roles runs the testing work, instead of a single assistant bot. In TestingOps every project gets a QA Delivery Lead, Test Engineers, a Test Data Engineer and a Test Manager. The Delivery Lead takes the request and plans it, the Test Engineers design the scenarios, and the Test Data Engineer prepares the accounts and data a run needs.

The approach follows two rules. First, every test step shows its evidence: the agents read your repositories, trackers and documents, and when they find no evidence they say so instead of guessing. Second, results are honest: an infrastructure fault is never counted as a product bug, and a skipped scenario is marked as skipped. A green result has to mean the product works.

Why mobile testing starts with a virtual device

The biggest bottleneck in mobile testing is usually the device. DeviceOps is not an emulator: it rebuilds the phone maker's own system image (such as Samsung One UI, Google Pixel or Xiaomi HyperOS) for virtual hardware and runs it natively on Arm servers. It can also create a digital twin of a real phone; apps and selected settings are copied, personal data and accounts are not.

Steps that need real hardware, such as a one-time code sent by SMS, run on physical phones with real SIM cards through RunningOps and TestingOps.

Where your data stays

Every product runs in the Cunda cloud or on your own infrastructure, in your own cloud account or data center. CoverOps also runs in air-gapped networks and never captures request or response bodies. ReplayOps' dynamic GDPR/KVKK masking replaces names, e-mail addresses, national ID numbers, IBANs and card numbers in the recording before they are stored or sent anywhere, using a model trained on Turkish as well as English data.

Where to start

You do not need to set up the whole loop on day one. Start with the stage that hurts most:

• If your regression suite takes hours, use CoverOps to see what needs re-testing after each change.
• If mobile tests wait for devices, use DeviceOps to open as many identical devices as you need.
• If there is no time left to write tests, start with the TestingOps agent team.
• If you cannot see what users experience, record sessions with ReplayOps.

If you want to work out together which stage would make the biggest difference for you, write to us.