Skip to main content
These are the questions teams ask us most about runs, with what you can do about each one. When a question has no fix on your side, the answer says what to send the Minitap team.

​
Why is my run so long?

The time a run takes includes more than the videos. Before the recording starts, Mini gets the build ready (or builds it from your repository), waits for a free device and a free test account, waits for the scenarios it depends on, then installs and launches the app. After it, Mini saves the recording and scores each failure. If a device has a problem, the scenario starts again on a fresh one. How Mini tests explains each step, and the run page shows an estimate of the time left. What shortens a run:
  • Split long scenarios. Scenarios that don’t depend on each other run in parallel, each on its own device. Five short scenarios finish sooner than one scenario that walks through five journeys.
  • Keep dependency chains short. A scenario that depends on another waits for it and runs after it on the same device. Only add a dependency when the second scenario needs the state the first one leaves.
  • Give parallel scenarios their own test accounts. A test account marked Exclusive use serves one running scenario at a time, so the others show On hold until it frees up. See test accounts.
  • Upload a build you already have when you don’t need Mini to build a commit. See upload a build.
Your plan sets how many devices and browsers run at once. If scenarios often show Waiting for an available device, ask the Minitap team about more parallel capacity.

​
Is there a timeout?

There’s no timeout to set on a scenario. What you can bound is how long your CI waits for the verdict:
If your runs take 40 minutes, the default of 45 leaves little room: raise it, and set the job’s timeout-minutes a little above it. See blocking a release on the result. From the CLI, minitest run from-commit polls for 3600 seconds by default; change it with --timeout <seconds>.

​
Mini is waiting on something

When Mini hits something only a person can settle, like which account to use or whether a behavior is expected, it asks. The scenario shows Needs input and the question appears on the run page. Type your answer and click Send answer. The scenario runs again once it’s answered. You can answer from the terminal too:
<run_id> is the id in the run page’s address. A question left unanswered for 72 hours is set aside, and the criteria it blocks stay untested.

​
Did Mini run the right build?

Click Run info on the run page. It shows the app version, build number, build source, build ID, commit and branch. For a TestFlight build on a physical iPhone, the scenario view also shows the version the iPhone installed, like “Tested 2.3.1 (57) via TestFlight”. To make sure a run tests one exact commit, start it from that commit: minitest run from-commit <full_sha>, or the GitHub Action on the commit. In Runs, filter by App version or Commit to find every run of a build.

​
A popup or a prompt hides the evidence

Mini handles popups and permission dialogs the way a user would, but sometimes one lands right on the moment that matters.
  • Watch the moment. The screenshot is one frame. Use the Watch button on Actual to see the recording around the failure, or click the criterion’s lane on the timeline.
  • Permission prompts. On cloud devices and in browsers, Mini can grant a permission without the system prompt. Say so in the scenario, for example “location access is granted before the map opens”.
  • A banner or popup your app always shows, like a cookie banner or a what’s-new sheet: tell Mini how to handle it in Mini’s memory, and every scenario benefits.
  • The popup caused a false failure: mark it Not a bug and say why. See a false failure.

​
A run shows as still running

Open the run and read the status of each scenario that isn’t done. Each one says what it’s waiting for: To stop a run, click Cancel Run. This can’t be undone. If a run stays in the same state for much longer than usual, click Copy run IDs in the scenario view and send them to the Minitap team in your Slack channel.

​
Unprocessable verdicts

A scenario that shows Not tested came back Unprocessable: Mini ran it but couldn’t grade any criterion. It’s never reported as a bug in your app. The usual causes are a failed sign-in, a criterion that asks for something Mini can’t observe, or a blocker early in the flow. Read Mini’s note on the criteria, then see when the verdict is Unprocessable for the fix for each case. If many scenarios come back Not tested on the same build, check the build and your test environment first.

​
A false failure

Mini reported a failure, but the app behaves as designed. On the finding, click Not a bug and explain why in a sentence, the way you’d tell a new tester:
The issue clears right away, and Mini keeps your note for the next run, for the whole app or for that scenario. See How Mini learns. If the criterion itself is out of date, edit the scenario. If the failure is real but Mini rated it too high or too low, override the severity.

​
Still stuck?

Send the Minitap team the run IDs from Copy run IDs, or Copy everything from Run info, with a sentence on what you expected. If you don’t have a Slack channel with us yet, book a call.

Read a run report

Verdicts, findings, the fix prompt and the export.

What Mini can and can't do

Check a criterion against Mini’s abilities.