Quash' Rerun: How Mahoraga Uses Memory to Test Faster
Every QA team runs the same tests repeatedly. Regression suites, nightly smoke tests, CI/CD pipeline checks, pre-release sanity runs — these are not one-off tasks. They run daily, sometimes multiple times a day.
The problem with most mobile test automation tools is that every single run is treated the same. The tool starts from zero, reads the screen, makes decisions, and reasons through the entire flow as if it has never seen the app before. That is expensive, slow, and fragile.
Today, Quash is changing how reruns work. Mahoraga — Quash's testing agent — now learns from the first run of a test and uses that knowledge to move through reruns much faster. The first run builds a map. Every run after follows it.
First Run | Rerun | Speed Gain |
~3 min | ~1 min | 3× faster |
Why Mobile Test Automation Gets Worse Over Time
Traditional automation tools like Appium and Selenium rely on selectors — XPath expressions, resource IDs, accessibility labels — to find elements on screen. Write a test today, and it works. Update the UI next sprint, and half your selectors break.
Maintaining selector-based tests is an ongoing cost that scales with how often the app changes. Rename a button, move a component, or add a new modal, and you are back to rewriting scripts. Teams often spend more time fixing tests than writing new ones.
Record-and-replay tools take a different approach but have a similar problem. They capture coordinates, taps, and selectors during a recording session. When the UI changes — even slightly — the replay breaks because it remembers where to tap, not why. It has no understanding of intent. A renamed button or a shifted layout is enough to cause a failure.
This is a major source of flaky tests in mobile automation. A test that passed yesterday fails today not because the app broke, but because the automation is brittle. Teams start to distrust the test suite. Flaky tests get ignored. Real bugs slip through.
Quash takes a different approach by understanding the app, not just remembering its coordinates. But understanding has a cost — AI reasoning on every step, every run, adds up. The Rerun update directly solves this.
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
How Mahoraga Learns During the First Run
On the first run of any test, Mahoraga operates in full reasoning mode. It reads each screen, identifies interactive elements, understands context, handles interruptions like permission prompts and notification popups, and makes decisions at each step to complete the flow.
This is where the AI test automation does the heavy lifting. Mahoraga uses an LLM to interpret the UI at each decision point — it is not matching selectors or replaying taps. It is reasoning about what the screen contains and what the next step should be.
When the run completes successfully, Mahoraga stores the full path it took.
This stored path is not a brittle recording of coordinates. It is a structured description of the flow — what happened, why, and what the screen looked like at each stage.
Why Reruns Are Faster with Mobile Test Automation
On the second run, and every run after, Mahoraga does not reason through the flow from scratch. It loads the stored path and follows it directly.
For each step, Mahoraga checks the current screen against what it expects based on the stored path. If the screen matches, it executes the next action immediately. No LLM call. No reasoning pause. Just execution.
This has a compounding effect on speed and cost:
Fewer LLM calls: A test that made 30+ reasoning calls on the first run might make 2–3 on a stable rerun.
Lower latency per step: Skipping inference means each step completes in milliseconds rather than seconds.
Lower inference cost: Stable flows become progressively cheaper as they accumulate run history.
For teams running hundreds of tests nightly, this adds up quickly — both in wall-clock time and in operational cost.
AI Only Activates When Something Changes
This is what makes Quash an example of adaptive test automation. The agent does not pick one mode and stick with it — it continuously reads the current state of the app and decides whether to follow the known path or switch back into reasoning mode.
When Mahoraga detects a mismatch between the current screen and the expected state, it re-engages the LLM to figure out what changed. It resolves the deviation, continues the test, and updates the stored path with the new information. Future reruns then use the updated path.
This hybrid approach is more efficient than re-running full AI reasoning on every test. It is also more robust than a static recording, because the agent can recover from changes rather than simply failing.
How Quash Handles UI Changes Without Breaking
Real apps change constantly. Buttons get renamed. Layouts shift between releases. Modals appear for new consent flows. Permission dialogs interrupt checkout. Notifications slide in at inopportune moments. On mobile in particular, device fragmentation means a flow can look different across screen sizes.
Quash is built to handle all of this. When Mahoraga encounters something unexpected during a rerun, it does not immediately fail the test. Instead, it switches back into reasoning mode for that specific step:
A button labelled "Continue" is now labelled "Next" — Mahoraga identifies the element by its role and context, not just its label.
A new permission dialog appears mid-flow — Mahoraga handles the interruption and returns to the main flow.
A promotional modal blocks the screen — Mahoraga dismisses it and continues.
The layout has shifted on a different device size — Mahoraga adapts and finds the correct element.
This is one of the most important reasons Quash reduces flaky tests. Most flakiness in mobile automation comes from tests that cannot recover from small, expected variations in the UI. Quash handles these gracefully and keeps the test moving.
After handling the unexpected change, Mahoraga stores the updated information. The next rerun already knows what to expect.
Where This Matters Most
Memory-driven reruns are most valuable in flows that run frequently and where speed and reliability directly impact the team's workflow.
For teams running regression testing nightly, cutting run time from 5 minutes per test to under 1 minute means suites that previously took hours can complete before engineers arrive in the morning. Feedback arrives earlier, and blocked releases become less common.
For CI/CD testing, faster reruns mean each pull request gets a test result sooner. Pipelines that used to queue for test capacity become more responsive.
For critical flows — checkout, payment, onboarding — reliability matters as much as speed. These are flows where a flaky test creates real confusion about whether the app is broken or the test is broken. Quash's ability to recover from UI changes without failing means these flows stay trustworthy.
In fintech and ecommerce especially, where UI changes are frequent and the cost of an undetected regression is high, having a test agent that adapts to changes rather than breaking on them makes a meaningful operational difference.
Conclusion
The goal of mobile test automation is to give teams confidence that the app works — across every release, every device, every flow. That confidence erodes when tests are slow, expensive to maintain, or too brittle to survive a UI update.
Quash's memory-driven reruns directly address all three problems. Tests get faster after the first run. They do not break on minor UI changes. And the AI effort is focused where it is actually needed — on new flows, changed screens, and unexpected states — not on re-reasoning through steps that have not changed.
This feature is available now. If you are running repeated flows in Quash, your next rerun will already use the stored path from the previous successful run. No configuration needed.
Frequently Asked Questions
Is this just another record-and-replay system? No. Record-and-replay tools capture coordinates, taps, and selectors. They remember the exact actions taken, not why they were taken. When the UI changes, they break because they have no understanding of intent. Quash stores the reasoning context of a flow — screen states, decision points, expected outcomes — and can adapt when the UI changes rather than failing.
Does Mahoraga still use AI during reruns? Yes, but only when needed. During a rerun, Mahoraga follows the stored path for each step where the screen matches expectations. It switches back into AI reasoning mode when it detects a mismatch — a UI change, a new modal, a renamed element, an interruption. Once it resolves the change, it returns to memory-driven execution and updates the stored path for next time.
Why are reruns faster than the first run? The first run uses LLM inference at every decision point to reason through the flow. This takes time at each step — typically resulting in a run of around 5 minutes for a moderately complex flow. On reruns, Mahoraga skips most inference calls and executes directly from the stored path. With fewer LLM calls and lower latency per step, the same flow can complete in around 1 minute.
How does this help reduce flaky tests? Most flaky tests in mobile automation fail because the tool cannot handle small, expected variations in the UI — a notification, a shifted element, a renamed button. Quash detects these deviations and handles them through reasoning rather than immediately failing the test. This means fewer false failures and a more trustworthy test suite. Flaky tests that previously required manual investigation can now self-recover.
What kinds of UI changes can Quash handle? Mahoraga can handle renamed buttons and labels, new modal dialogs, permission prompts, system notifications, layout shifts, and different element positions across device sizes. It can also handle changes to the flow itself — new steps, reordered screens — by reasoning through the updated path and storing the result for future runs.
Why is this especially useful for mobile apps? Mobile apps change more frequently than web apps, ship faster, and run across more device configurations. A flow that works on one screen size may look different on another. System interruptions — notifications, permission dialogs, low battery overlays — are common and unpredictable. And mobile test automation historically has had higher flakiness rates than web automation because of these variables. Quash's adaptive approach is designed specifically for this environment.
