What This Is
An AI agent drove a development build of the driver app the way a driver would: sign-in, onboarding, the home gates, starting a run, driving, pick-up, no-show, drop-off, and ending a run. At every step it took a screenshot, followed each branch and error state, and wrote down what it saw.
The result is a flow chart of the app drawn with real screens, plus 57 observations ready for triage. They are candidates, not confirmed defects. Some are intended behaviour or effects of test data, and the team has already tagged 13 of them that way.
Why It Matters
Tests Check What They Expect
The BrowserStack suite confirms known paths still work. Nothing in it goes looking for what is wrong.
An Agent Looks for Problems
It explores every screen and branch, spots issues nobody scripted a test for, and writes them up with evidence.
Less Risk During Staffing Gaps
QA coverage no longer depends on one person being available to click through every flow before a release.
Where It Can Go Next
- Triage and Fix - review the 57 observations with product, ticket the real ones, and fix them with Claude Code alongside the developers.
- Run It on Every Build - turn the sweep into an automated agentic regression pass that verifies each screen and flags anything new.
- Check Against Figma - connect the designs so the agent can catch design drift between what was designed and what shipped.
Two Ways to Run It
Your Team Drives It
Mike and Ringo lead the initiative with time carved out for it, and RedBit coaches them on AI-driven QA practices.
Add a RedBit AI QA Engineer
A RedBit QA engineer joins part time to build and run it, so the mobile developers stay focused on shipping.
How It Was Run
Development environment only. The app was a debug build on an Android emulator, signed in with a RedBit test account against the DEV backend, using generated test data. No production systems and no rider or student data were involved.