Skip to main content
Mini tests your app the way a careful QA engineer would. It reads the screen, does one thing, checks what happened, and repeats until it has a result for every acceptance criterion. Every verdict comes with the moment in the video it’s based on. This page explains that loop at a high level, so you know what to expect from a run and how to read its results. We don’t publish the models or prompts behind Mini. They change as we improve it.

​
What happens when a run starts

For each scenario in a run, before Mini does anything:
  1. A virtual device is ready with your build installed and the app launched.
  2. The screen recording starts. It runs until Mini has finished the scenario.
Scenarios that depend on each other, like sign-in then checkout, run one after another on the same device, so the next one starts where the previous one left the app. Other scenarios run on their own devices, in parallel. See dependencies. Mini then reads the scenario, its acceptance criteria, and Mini’s memory for your app. If the scenario has a profile, Mini signs in with it. Email codes, phone OTP, and Google sign-in are handled for it.

​
The test loop

Observe. Mini reads the screen the way a person does: it looks at what’s rendered, the text, images, colors, and layout, and understands what’s in front of it. On top of that, it uses the accessibility services of the device, the same ones screen readers rely on. They tell Mini exactly which buttons, fields, and text are on screen, so it can move through the app quickly and confirm the app’s state precisely, for example that a field holds the right value or a toggle is really on. Mini uses whichever fits the question, and often both. Some screens expose nothing to accessibility services, like games, canvases, or some web views. There, Mini works from what it sees, and finds what to tap by describing it, the way you’d point at it. Act. Mini taps, types, swipes, and scrolls like a user. It works toward the goal of the scenario rather than replaying fixed coordinates, so a moved button or a new pop-up doesn’t break the run. When the next steps are predictable, like filling a field and pressing Continue, Mini can do them together. Each step still has to succeed before the next one runs, and the check is part of the same move. Check. After every action, Mini confirms what changed before it decides anything else. What it read about the screen before an action is never reused after it, because the screen may have moved. Mini doesn’t wait a fixed number of seconds for loading. It waits for the thing it expects to appear, or for the screen to settle.

​
When the app does something unexpected

  • Pop-ups and permission dialogs. Mini handles them the way a real user would. If a criterion is about the dialog itself, Mini judges that first, then moves on.
  • Short messages. Toasts and snackbars can disappear before anyone looks. Mini can review the recording to catch them.
  • An action had no effect. Mini doesn’t repeat the same tap blindly, since that could submit a form twice. It looks again, waits, or tries a different gesture.
  • Mini can’t get past something. A missing account, test data it doesn’t have, or a wall a user couldn’t pass either. Mini stops and asks you instead of inventing a workaround a real user would never try.

​
How each criterion is judged

Mini gives every acceptance criterion its own verdict, while the evidence is fresh.
  • Passed means Mini did every part of the criterion and saw the outcome. A message saying “Saved” isn’t enough: Mini checks the thing was actually saved.
  • Failed needs evidence specific to that criterion. When the call depends on interpretation, Mini gets a second reading with a different method before it reports. If something is supposed to be missing, Mini confirms it’s really missing in two different ways.
  • Mini rules itself out first. If a failure could be explained by Mini’s own action, like a mistyped value or a tap that didn’t land, Mini redoes the step cleanly before it blames your app.
  • Not proven isn’t failed. If Mini couldn’t prove the outcome either way, or something outside your app got in the way, it doesn’t report a failure. It tells you what stopped it, and asks you when it needs something. See when the verdict is Unprocessable.
  • One bug stays one bug. When a failure makes the next criteria impossible to reach, those are marked as skipped rather than failed again. Criteria that don’t depend on the failure are still tested.
  • When Mini stops early. If the app won’t start, or the build is clearly broken from the first step, Mini reports that and skips the rest instead of guessing.
Each failure then gets a criticality (Critical, Warning, or Pass) based on what your app does and what matters in it. A failure Mini couldn’t verify is never marked Pass. Those add up to the scenario’s verdict.

​
What you get

For every scenario in a run:
  • The video of the device. Each verdict points at the stretch of the video it’s based on, so you can watch exactly what Mini saw instead of trusting a single screenshot.
  • The steps Mini took.
  • What Mini observed for each criterion, and why it reached its verdict.
  • A fix prompt for each failure, ready to paste into Cursor or Claude.
A failure in your app is never retried until it passes: it’s reported. Mini may also notice UX problems you didn’t ask it to check. Those become suggestions and never change a verdict.

​
Why a run takes longer than its videos

The video only covers the time Mini spends in your app. A run also includes:
  • Before the video: getting the build ready (or building it from your repo), waiting for a free device or a free test account, waiting for the scenarios it depends on to finish, then installing and launching the app.
  • After the video: saving the recording and scoring each failure’s criticality before the verdict appears.
  • Retries: if a device or our infrastructure has a problem, the scenario runs again from the start on a fresh device.
The run page shows an estimate of the time left while the run is in progress. The videos are shorter than the time Mini spent on the device too, on purpose. We cut the stretches where nothing moves on screen, like loading or waiting, so you can review a scenario as fast as possible. Each video is also split into segments that take you straight to the moments that matter, like the step behind a failed criterion.

​
What Mini knows before it starts

Before every run, Mini reads two things:
  • Mini’s memory for the app: what the app does, how it’s organized, which accounts to use for what, and your app’s own names for its screens and features. You can edit it, and Mini adds to it as it learns.
  • What it learned about this scenario from past runs and from your triage. When you mark a result as not a bug or explain a failure, Mini keeps that for the next run. See How Mini learns from your feedback.
Both are context, not answers. Mini still judges every criterion from what it sees on the device in this run, so a run always tests the build in front of it.

​
Writing criteria Mini can judge well

Mini judges what it can observe on the device. The clearer the criterion, the more reliable the verdict. See how to write a scenario for more.