Start from Intent, Not Scripts: A New Model for Mobile Testing

Mobile testing has always carried a heavy maintenance burden.

Apps change constantly. Screens are redesigned. Buttons move. Text changes. Login flows get updated. Permissions behave differently across devices. Small changes in the user interface can break tests that were technically correct yesterday.

For years, mobile test automation has tried to solve this with better scripts, better selectors, better frameworks, and better maintenance practices. Those things matter, but they do not change the core problem.

Most mobile automation still starts from the script.

A tester or automation engineer has to define every step manually. Find this element. Tap that button. Wait for this screen. Type into this field. Locate this selector. Assert that this value appears.

That model can work, but it also creates a gap between what the team wants to validate and how the test is actually built.

The team thinks in scenarios.

The automation thinks in steps.

The product team says:

“Make sure a user can log in, add an item to the cart, and complete checkout.”

The automation layer often requires:

“Find this element by ID, tap here, wait for this activity, type this value, locate this button, handle this popup, assert this text, and update everything again when the UI changes.”

That gap is where a lot of mobile testing effort gets lost.

The problem with starting from scripts

Script-based mobile automation is not wrong. It has helped teams validate important workflows for years.

But when scripts become the starting point for every test, teams inherit a few familiar problems.

First, tests become closely tied to implementation details. Instead of focusing only on the behavior that matters, the test often depends on selectors, screen structure, element names, timing, and assumptions about how the app is built.

Second, test creation becomes limited to people who know the automation framework well. Product managers, manual testers, customer-facing teams, and domain experts may understand the scenario perfectly, but they usually cannot turn that understanding into executable automation without help.

Third, maintenance becomes part of the operating cost. Every UI change can create work. Every unstable selector can create noise. Every false failure can reduce trust in the test suite.

And fourth, the test can become harder to understand over time. A long automation script may tell you what the test did technically, but it does not always make it easy to understand the original user intent.

That matters because testing is not just about execution. It is about validating product behavior.

What changes when the test starts from intent

Intent-based mobile testing starts from a different place.

Instead of beginning with selectors and scripted steps, the test begins with the scenario the team wants to validate.

For example:

“Open the app, log in as an existing user, search for a product, add it to the cart, and verify that the cart total is correct.”

That is not just a prompt. It is the intent of the test.

The intent describes the user journey, the goal of the flow, and the expected outcome. It is closer to how teams already talk about product behavior, user experience, and business risk.

From there, an AI mobile testing agent can execute the flow through the live app interface. The agent observes the screen, decides what action to take, taps, types, scrolls, waits, and adapts based on what actually appears in the app.

This changes the role of automation.

The test is no longer only a fixed sequence of technical instructions. It becomes a workflow that starts from the desired behavior and uses the app interface to complete the scenario.

Why mobile testing is a natural fit for agents

Mobile apps are visual, dynamic, and highly interactive.

Users do not experience an app through selectors. They experience screens, buttons, forms, menus, messages, and flows. They react to what they see. They adapt when something changes. They understand the goal of the journey even when the interface is slightly different.

That is why mobile testing is a strong fit for computer-using agents.

An AI mobile testing agent can interact with the application more like a user would. It can look at the screen, understand the available actions, and continue the scenario based on the current state of the app.

This does not mean there is no structure. Intent-based testing still needs clear scenarios, reusable flows, assertions, logs, screenshots, and evidence. The goal is not to make testing vague. The goal is to let teams express what needs to be validated without forcing every scenario to begin as selector-heavy code.

Intent does not mean less control

One common concern around AI agents in testing is control.

If the test starts from natural language, does that mean it becomes less predictable? Does it become harder to trust? Does it become too open-ended?

It should not.

Intent-based testing still needs guardrails. A good testing agent should not simply “do whatever it thinks is right.” It should follow the scenario, execute against the real application, produce evidence, and make the result understandable.

That means teams still need:

• Clear test scenarios
• Reusable workflows
• Assertions
• Execution logs
• Screenshots
• Failure details
• The ability to rerun and refine tests

The difference is that the team does not have to start by translating every scenario into a fragile script.

They can start from the behavior they care about and let the agent handle the interaction layer.

What this means for QA and engineering teams

Starting from intent can change how teams think about mobile test coverage.

It can help automation engineers move faster because they spend less time building and maintaining every low-level interaction manually.

It can help manual testers and domain experts contribute more directly because they can describe real user journeys in natural language.

It can help product and engineering teams align better because the test reads more like the actual scenario being validated.

And it can help reduce some of the maintenance overhead that comes from UI changes, selector changes, and brittle step definitions.

This does not remove the need for engineering discipline. It changes where that discipline is applied.

Instead of spending so much effort on every tap, selector, and wait condition, teams can focus more on scenario quality, validation logic, test coverage, and trust in the result.

Where Droid CUA fits

Loadmill Droid CUA was built around this idea.

Droid CUA is an AI mobile testing agent that lets teams create and run mobile tests from natural language intent. Instead of starting with scripts and selectors, teams describe the scenario they want to validate.

The agent runs against the live mobile app interface. It can tap, type, scroll, wait, and interact with the app based on what appears on the screen. Teams can add assertions, save reusable flows, rerun tests, and use the results as part of a broader mobile testing workflow.

To see the product flow in more detail, explore the Droid CUA documentation or follow the Droid CUA getting started guide.

The goal is simple: make mobile test automation start closer to the way teams already think about testing.

• Start with the scenario.
• Run against the real app.
• Validate the actual workflow.
• Reduce the manual effort required to create and maintain mobile tests.

The future is not scriptless. It is intent-first.

Scripts are not going away. There will always be places where code, APIs, frameworks, and technical control matter.

But scripts do not need to be the starting point for every mobile test.

For many user journeys, the better starting point is the intent: what the user is trying to do, what the app should allow, and what outcome needs to be validated.

That shift matters.

Because when mobile testing starts from intent, more people can contribute. Tests become easier to understand. Automation gets closer to real product behavior. And teams can spend less time maintaining fragile steps and more time validating what actually matters.

Mobile testing is moving from scripts to agents. For a broader look at how Loadmill approaches this shift across web and mobile, read Loadmill Agents for Web and Mobile.

And that shift starts with intent.