From Acceptance Criteria to Emulator: Building an Agentic AI Workflow for Mobile QA

For enterprise organizations managing complex mobile applications, quality assurance is about more than validating whether a feature works. It requires coordinating requirements, design specifications, test coverage, development environments, and release expectations across multiple systems and teams.

As organizations explore agentic AI for software development and testing, an important opportunity is emerging: connecting those disconnected workflows so QA engineers can spend less time gathering information and more time validating quality.

But building an effective agentic QA workflow requires more than asking AI to generate test cases. It requires a repeatable process, access to trusted systems, and human oversight.

Here’s how we approached that challenge by connecting acceptance criteria, design files, existing test cases, and mobile emulators into a more cohesive AI-assisted QA workflow.

Where We Started: The Challenge of Disconnected QA Workflows

QA work rarely fails because people lack skill. More often, it fails because the pieces of the job live in different places and someone has to stitch them together by hand.

Acceptance criteria sit in stories on Azure DevOps, mockups live in Figma, existing test cases sit in another suite, and content pages with test users live in SharePoint. The known “gotchas” for the app are usually somewhere even harder to find: in someone’s head, on a SharePoint page, or in a checklist that only a few people remember to open.

When we started experimenting with AI assistants for mobile QA, the models were fine at producing steps, but they were much worse at pulling the right context without a lot of copy and paste.

We already had a version of this story for web, where Playwright, custom chat modes, and an evolution file helped us capture lessons over time. For mobile, we needed something similar, but the shape of the work was different.

Mobile QA is not only “write a test.” It is also open the right story, look at the design, check what we already cover, get an emulator running, and prove the screen looks right.

So this past month, we built a framework around that full loop rather than around a single tool.

Cursor Skills as the Playbook for Agentic QA

The first thing that made a real difference was treating Cursor skills like versioned runbooks instead of one-off prompts.

A skill is a short, reviewable document that says when the workflow applies, what inputs matter, what tools to use, and what “done” looks like. Writing one forces the team to agree on the process, and that alone is useful even before an agent ever runs it.

For us, skills covered things like:

Drafting test cases from a story’s acceptance criteria and adding them to suites in Azure DevOps (ADO)

Comparing a Figma design to a simulator or emulator screenshot

Launching the app to a specific screen with mock data

Running known QA checkpoints for high-traffic flows

Once those playbooks existed, the agent stopped inventing a new process every chat and started following the same path a careful QA engineer would follow, just faster on the busywork.

For enterprise QA teams, this kind of standardization is particularly valuable. A documented, repeatable workflow makes it easier to maintain consistent testing practices across applications, projects, and team members.

Connecting QA Tools With Model Context Protocol (MCP)

Instead of replacing Azure DevOps, Figma, or our device tooling, we worked on connecting them.

The useful pattern was piping several Model Context Protocol (MCP) servers together so the agent could move across systems in one session:

Pull the work item and acceptance criteria.

Look at related designs or attachments when they exist, comparing SharePoint content and Figma designs when possible.

Check existing test cases so we do not reinvent coverage.

Draft new cases in the team’s format.

When needed, drive a simulator or emulator and capture evidence.

That sounds obvious written down, but in practice, it is the difference between “AI wrote some test steps” and “AI started from the same sources QA already trusts.”

The important choice was to keep each MCP focused on one job and let the skill tell the agent how to sequence those jobs.

That kept the system understandable, and it made it easier to extend later when someone asked whether it could also check SharePoint or attach screenshots back to the story.

Rather than introducing another disconnected platform, this approach allows teams to build on their existing QA investments while creating a more connected testing process.

Getting Mobile Emulators and Simulators Into the Loop

Mobile is where the clean diagram meets real friction.

We wired emulator and simulator access so the agent could list devices, launch the app, navigate to a screen, and take screenshots.

For repeatable visual checks, mock mode mattered a lot, because jumping straight to a screen with controlled data beats logging in and tapping through five menus every time you want to compare padding on a card.

This is also where honesty helps.

Emulators flake, first launches behave differently, authentication and environment setup still need care, and platform parity is a real requirement rather than a nice-to-have.

The framework did not magically remove those issues, but it made them visible earlier, with screenshots and a clear trail of what the agent tried.

This also made it straightforward enough for manual QA resources to hand flaky or tricky cases over to automation engineers, while keeping the workflow approachable enough to lighten the load on those engineers.

What changed for QA was the cost of asking a question like, “Does this match the mock on both platforms?”

That used to mean a long manual setup. Now it can start from a chat, move through manual review, and result in a completed automation test being added to the codebase, all with minimal coding knowledge required from less technical resources.

For teams supporting mobile applications across iOS and Android, this creates an opportunity to reduce repetitive setup work while making cross-platform visual validation more accessible.

Human Oversight Still Owns QA Risk

We were deliberate about what the agent is allowed to do.

Drafting cases, gathering context, taking screenshots, and proposing coverage is one thing. Publishing into the official suite, marking a story done, or declaring a release safe is another.

QA still reviews the output, edits the wording, drops the noise, and keeps ownership of the risk.

Our team’s normal pull request flow still stands, and automation engineers still review all proposed code changes and added tests. This helps make sure agents aren’t running rogue and that less technical resources don’t miss small hiccups that could hurt the overall regression libraries.

That boundary is not a limitation of the tools so much as a practical way to get adoption.

People trust a system faster when you can say clearly what it does not do yet.

For enterprise organizations, this distinction matters. AI-assisted testing can improve efficiency and coverage, but established review processes, engineering standards, and accountability remain essential to maintaining software quality.

What Web QA Teams Can Learn From Agentic Mobile Testing

If you already have Playwright or Cypress and an AI assistant in the IDE, a lot of this maps cleanly:

The web version of this story is not “buy a new platform.”

It is closer to “stop asking the model to invent context, and stop treating test generation as a one-shot prompt.”

Our earlier Playwright work already showed the value of splitting planning, generation, and healing.

Skills and MCP pipelines are the same idea one layer up: give the agent a stable process and the systems of record it needs to follow that process well.

Lessons From Our First Month of Agentic QA

A few things stood out quickly.

Context Matters More Than Clever Prompting

Acceptance criteria alone tend to produce generic cases, but when you pair them with existing coverage, design, and app-specific checklists, the drafts start looking like something a QA lead would actually review.

Repeatable Test Environments Make a Difference

It is worth investing in repeatable setup.

Mock data and jump-to-screen tooling make visual and functional checks much more reliable. Without that, the agent spends a surprising amount of time just rediscovering how to reach the screen.

Capture Lessons and Improve the Skills

When the agent misreads a common acceptance-criteria pattern, picks a weak locator style, or ignores a known flaky area, write that miss back into the skill once.

That is the mobile cousin of our web evolution file, and it compounds over time.

Start Narrow and Expand Gradually

We also learned to start narrow.

Day one can be “draft cases from a story,” then add designs, then add device evidence.

A staged path is easier to sell than promising fully hands-off QA in the first week.

This is also reflected in the use of mock modes to make sure we can verify certain screens before tying real users to them and performing thorough end-to-end validation of our cases.

It helps to expect failure modes up front: the wrong work item linked, stale mockups, over-generated cases, or an emulator that needs a reboot.

Call those out in the workflow instead of pretending the happy path is the only path.

Cost and Practicality of Agentic QA Automation

The big expenses are not necessarily mystery licenses. Instead, one of the primary considerations is token usage.

We all know AI usage costs can add up, but the nice thing about chaining context well and managing our tools correctly is that agents spend far less time, and fewer tokens, chasing context on their own.

Instead, they can spend more time on high-value tasks like generating code and verifying execution.

The return showed up as less time spent gathering context and more time spent on judgment:

Is this coverage enough? Is this visual difference a real defect? Does this story need another case for Spanish or a small phone?

Those are the questions where QA expertise matters most.

For organizations evaluating the cost of AI-assisted software testing, the practical value is not simply how many tests an agent can generate. It is how effectively the workflow reduces repetitive effort while supporting better testing decisions.

What’s Next for Our Agentic QA Framework?

We want tighter feedback from real runs into the skills, better attachment of evidence back to work items, and clearer defaults for when to stop at draft cases versus when to drive a device.

On the web side, the same pattern should keep expanding alongside Playwright planning, generation, and healing.

As the framework evolves, the goal remains the same: make it easier for QA teams to move from requirements to reliable test evidence without losing the engineering judgment that makes those tests valuable.

Final Thought: AI Doesn’t Replace QA, It Makes Better QA Possible

AI does not replace QA, and that was never the point.

What it can do, used carefully, is take some of the friction out of gathering context across tools so people spend more time on judgment and expanding test coverage and less time on copy and paste.

For us, the useful unit of work turned out to be a clear skill, a small set of systems wired together, and a human who still decides what “good” means.

That mix is what made the framework usable for the QA team this month, and it is also the part other teams can carry over to web or mobile without waiting for a perfect platform to show up.

Bringing Agentic QA Into Enterprise Software Delivery

At RBA, we help organizations modernize software engineering and quality assurance practices by connecting AI capabilities with the tools, workflows, and governance structures their teams already rely on.

Whether the goal is improving mobile test automation, strengthening existing QA processes, or exploring agentic AI across the software development lifecycle, the opportunity is to build practical solutions that improve delivery without compromising quality.

Explore how RBA can help your organization bring AI-assisted testing and intelligent automation into your software engineering workflows.