# Frequently asked questions
Source: https://www.minitap.ai/docs/minitest/get-started/faq
Short answers to what QA leads and engineers ask before and after they start with Minitap, each with the page that holds the details.
The questions teams ask us most, from the first evaluation to the hundredth run, each with a short answer and a link to the page that goes further. Can't find yours? [Book a call](https://cal.com/team/minitap/minitap-get-access?overlayCalendar=true) or ask in your Slack channel with the team.
## Evaluating Minitap
> [accordion] How is Mini different from scripted test automation?
>
> A scripted test replays fixed steps against fixed elements, so someone updates it every time a screen changes. Mini starts from a scenario written in plain English, with acceptance criteria. At every step it reads the screen, acts toward the goal of the scenario and checks what changed, so a moved button or a new pop-up leaves the run on track. When your app changes for good, Mini drafts the update to the scenario itself. See [How Mini tests your app](/docs/minitest/get-started/how-mini-tests).
> [accordion] Where does our QA team fit in?
>
> Mini takes on the repetitive work: writing scenarios, running them on every build, keeping them current and triaging what fails. Your QA and engineering teams keep the calls that matter: what to cover, what counts as a bug and when to ship. In practice they review Mini's drafts, answer its questions during a run and correct it with a **Not a bug** note when it gets a result wrong. See [Meet Mini](/docs/minitest/get-started/meet-mini).
> [accordion] Which platforms and devices does Mini test on?
>
> iOS apps run on cloud iPhone and iPad simulators, Android apps on cloud phone and tablet emulators, and both can run on physical phones assigned to your workspace (in beta, requested from the device picker). Web apps run in Chrome, Firefox and Edge at desktop, tablet and mobile sizes, plus Safari on iPhone and Chrome on Android. You pick the devices for each run in **Run tests → Choose devices**. See [Devices](/docs/minitest/setup/devices) and [Web apps](/docs/minitest/setup/web-apps).
> [accordion] What can't Mini test yet?
>
> Face ID, fingerprint, NFC and Bluetooth pairing, real SMS and calls (a static code covers phone sign-in), push notifications on Android, and real money (sandbox payments work). For backend questions, Mini checks the screen against the API responses your app receives and can call your test backend API; it doesn't read your database or server logs. Unit, integration, load and security testing are out of scope. A criterion that needs one of these comes back **Not tested**. The full list is in [Capabilities](/docs/minitest/reference/capabilities).
> [accordion] What does Mini need from us to get started?
>
> An app to test: a branch of your repository, an `.ipa`, `.apk` or `.aab` you upload, or your web app's URL. Then a test account for each kind of user Mini should sign in as, some context about your product, and your existing test cases if you have them. You can skip anything you don't have yet: Mini asks again when it needs it. The [quickstart](/docs/minitest/get-started/quickstart) walks through the setup in the order the dashboard shows it.
## Setting up
> [accordion] Do we have to connect our repository?
>
> Either way works. You can upload a build from the dashboard or the CLI, or point physical iPhones at a TestFlight link. Connecting GitHub, GitLab or Bitbucket lets Mini build your iOS and Android app from the commit each run needs. On GitHub it also posts a check on your pull requests and keeps your suite in step with what lands on the default branch. See [Builds from your repository](/docs/minitest/setup/builds-from-repo) and [Upload a build](/docs/minitest/setup/upload-a-build).
> [accordion] We already have a test plan. Can Mini start from it?
>
> Yes. Hand Mini a spreadsheet, a document or a zip of your tests during onboarding, or later in **Ask Mini**, and it turns every case into scenarios. Your case IDs, test values and expected results are kept as written, and you can check that every case made it. See [Import your tests](/docs/minitest/suite/import-tests).
> [accordion] How does Mini get past sign-in, email codes and phone OTP?
>
> Attach a test account to each scenario that needs one. Email codes and magic links go to `@qa.minitap.ai` test inboxes that Mini reads during the run, and your team can read the same emails in **View emails** on the account or in the run report's **Emails** tab. Phone sign-in works with a static code you pin for a test number in staging, and Google sign-in uses accounts Minitap maintains for you. See [Test accounts](/docs/minitest/setup/test-accounts) and [Test inboxes](/docs/minitest/setup/test-inboxes).
> [accordion] Should Mini test production or a staging environment?
>
> Point Mini at a staging URL or a pull-request preview that our cloud can reach, and give it test accounts made for testing. Keep production data and production credentials on your side: Mini never asks for them. Real payment card data, health data and children's data don't belong in a test either; sandbox test cards are fine. See [what not to give Mini](/docs/minitest/workspace/security#what-not-to-give-mini).
> [accordion] Our app sits behind a firewall, a VPN or a country restriction.
>
> Each case has its own way in. For an app that blocks some countries or cloud traffic, turn on **Proxy: test from another country** in **App settings → General**. For hosts that only exist inside your network, a private network connector runs on your side (Enterprise plan). For an IP allowlist, ask the Minitap team for the addresses to allow, and a staging password goes in **Test suite → Knowledge**. See [Private apps](/docs/minitest/setup/private-apps).
> [accordion] Can Mini test in-app purchases?
>
> Yes, with sandbox buyers so nobody is charged. On iOS cloud simulators purchases work with nothing to set up. Physical iPhones need a TestFlight or Ad Hoc build and a Sandbox Apple Account, and purchases on Android run on physical Android phones, since cloud emulators run without Google Play. Set it up per app in **Builds & test data → In-app purchases**; the feature is in beta. See [In-app purchases](/docs/minitest/setup/in-app-purchases).
## Runs and results
> [accordion] How long does a run take?
>
> It depends on how long your scenarios are and how many run at once. Scenarios that don't depend on each other run in parallel, each on its own device, up to the parallel capacity of your plan. A run also includes the time to get the build ready, wait for a free device or test account, install the app and score each failure, so it takes longer than its videos. Splitting long scenarios into short, independent ones is the first thing to try when runs feel slow. See [Why is my run so long?](/docs/minitest/troubleshooting/runs#why-is-my-run-so-long)
> [accordion] Can Mini run in our CI and block a merge?
>
> Yes. On GitHub Actions, the Minitap GitHub Action signs in with the workflow's OIDC token; GitLab CI, CircleCI, Jenkins and every other CI use the `minitest` CLI with a workspace API key. Both can wait for the verdict and fail the job when a scenario fails. On pull requests, turn on **Block merge on failing tests** in **Workbench → CI & Maintenance** and add the check to your required status checks. See [Run Mini from your CI](/docs/minitest/runs/ci) and [Pull request checks](/docs/minitest/runs/pull-request-checks).
> [accordion] What do we get when a scenario fails?
>
> The recording of the device, with **Expected** and **Actual** side by side for each failed criterion, the steps to reproduce and Mini's analysis of the root cause. The timeline under the video jumps to the moment each criterion was decided. Every failure also comes with a fix prompt you can paste into Cursor or Claude. See [Read a run report](/docs/minitest/runs/run-report).
> [accordion] Can we trust a failure? How flaky is Mini?
>
> Mini gives a failure only with evidence specific to that criterion. When the call depends on interpretation, it gets a second reading with a different method, and when its own action could explain the failure, it redoes the step cleanly before it blames your app. A device problem restarts the scenario on a fresh device, while a failure in your app is reported as it happened. When Mini can't prove an outcome either way, the criterion shows **Not tested** and Mini tells you what stopped it. See [how each criterion is judged](/docs/minitest/get-started/how-mini-tests#how-each-criterion-is-judged).
> [accordion] What happens when Mini gets a result wrong?
>
> Click **Not a bug** on the finding and say why in a sentence, the way you'd explain it to a new tester. Mini checks your note against the recording, clears the issue when it agrees, and keeps what it learned for the scenario, for every scenario with one of its tags, or for the whole app. The same false alarm doesn't come back on the next run. See [How Mini learns from your feedback](/docs/minitest/get-started/how-mini-learns).
> [accordion] Who keeps the tests up to date?
>
> Mini does, with your team approving what matters. It watches what lands on your default branch and opens a draft in **Workbench → Proposed changes** with new scenarios, retired ones and criteria rewritten for the new UI. Each change is checked on a device first; drafts that need nobody merge on their own, and a draft that removes a scenario or found what looks like a bug waits for you. New test accounts and device files are the two things you add by hand. See [Mini maintains your suite](/docs/minitest/suite/mini-maintains-your-suite).
> [accordion] How do we know Mini tested 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 phone installed. To test one exact commit, start the run from that commit with the GitHub Action or `minitest run from-commit`. See [Did Mini run the right build?](/docs/minitest/troubleshooting/runs#did-mini-run-the-right-build)
## Security and data
> [accordion] Where does Minitap run?
>
> On every plan, in Minitap's managed cloud, in the EU or the US, your choice, with data encrypted in transit and at rest. On Enterprise, you can have a dedicated instance in your region, or run Minitap in your own cloud or on your own servers. See [Where it runs](/docs/minitest/workspace/security#where-it-runs).
> [accordion] Do the AI models train on our data?
>
> Minitap doesn't use customer content to train models, on any plan, and your content is never shown to another customer or sold. Mini sends a model only what a test needs: screenshots and page text, the scenario and its criteria, and code or ticket context when it writes or updates a test. Zero data retention at the model providers is available on request on Scale and Enterprise. See [What the models see](/docs/minitest/workspace/security#what-the-models-see).
> [accordion] How long do you keep our data?
>
> Test results and recordings are kept 90 days at most, sensitive test data 30 days at most, and your content is deleted within 30 days of the end of your contract. Test account passwords are encrypted per workspace and never shown in a report. See [What we keep, and for how long](/docs/minitest/workspace/security#what-we-keep-and-for-how-long).
> [accordion] Do you support single sign-on, and how do we run a security review?
>
> Every plan signs in with email and password, Google or GitHub, with Owner, Admin and Member roles. Single sign-on with SAML or OIDC, SCIM provisioning and audit-log streaming are part of the Enterprise plan. Our SOC 2 Type II audit is in progress; the subprocessor list and the documents we share under NDA are in the [trust center](https://trust.minitap.ai). Bring your questionnaire to a call and we sign the DPA with your contract. See [Request a security review](/docs/minitest/workspace/security#request-a-security-review).
## Pricing
> [accordion] How much does Minitap cost?
>
> The plan depends on your apps, so we size it with you: how many apps and platforms, how many tests each release needs and how often you ship. Team, Scale and Enterprise run the same Mini and differ in parallel capacity, service and hosting. Team runs 6 mobile devices and 10 web browsers at once, Scale runs 8 and 15, and Enterprise is scoped to your release program. You can pay monthly or annually. See [Pricing](https://www.minitap.ai/pricing).
> [accordion] Do you charge per user or per build?
>
> Every plan includes every user, build, recording and report, so developers, QA engineers, product managers and support can all have an account. Extra parallel sessions are a line you can add on any plan, for the months you need them. [Plans, usage and billing](/docs/minitest/workspace/billing) says what counts as usage. To invite your team, see [Members and roles](/docs/minitest/workspace/members).
> [accordion] Can we try it on our own app first?
>
> Yes. During a pilot of about two weeks, Mini learns your app, writes a suite and runs it on your builds. Bring a build and a test account. Minitap is invite-only for now: [book a call](https://cal.com/team/minitap/minitap-get-access?overlayCalendar=true) and we send your invitation after a short walkthrough.
## Next steps
> [card] [Quickstart for mobile](/docs/minitest/get-started/quickstart)
>
> Connect your iOS or Android app and watch Mini run your first regression.
> [card] [What Mini can and can't do](/docs/minitest/reference/capabilities)
>
> Every ability, platform by platform, and the limits.
> [card] [Security and data](/docs/minitest/workspace/security)
>
> Where Minitap runs, what it stores, and what the models see.
> [card] [Troubleshooting runs](/docs/minitest/troubleshooting/runs)
>
> Long runs, Mini's questions, the wrong build and false failures.
# How Mini learns from your feedback
Source: https://www.minitap.ai/docs/minitest/get-started/how-mini-learns
What happens when you mark a result Not a bug, where Mini keeps what it learned, and how to see or undo the change.
Every time you tell Mini a result was wrong, it learns from it, so the same false alarm doesn't come back on the next run. This page covers the **Not a bug** note, where Mini keeps what it learned, and the two places to check it: **Test suite → Knowledge** and a criterion's history.
## Tell Mini it got something wrong
On an issue, open **What happened?** and click **Not a bug**. The same button sits on each finding in the run's scenario view. Mini asks **Why is this not a bug?**: answer in a sentence or two, the way you'd explain it to a new tester, or pick one of the answers **Suggested by Mini**.
```text theme={"theme":{"light":"github-light","dark":"vesper"}}
The banner is supposed to stop after the last slide. That's the new design.
```
When the panel shows **Applies to**, say where the note holds: **This scenario**, every scenario with one of its tags, or **The whole app**. Then click **Submit feedback**. The steps and the other triage actions are on [Issues](/docs/minitest/triage/issues#mark-it-not-a-bug).
## What Mini does with your note
Mini reads your note against the evidence of the run and replies in the issue's **History**:
* **Not a bug**: Mini agrees, and the issue is cleared.
* **Failure is real**: the recording still shows a problem. Mini says why, and the issue stays open for you to triage.
Then it keeps what your note taught it, where it belongs:
* **For the whole app.** A rule about how your app works, like "prices include VAT", goes into what Mini knows about the app. Every scenario benefits from it.
* **For a scenario or a tag.** Something true only there is kept with that scenario, or with every scenario carrying the tag, and Mini reads it the next time it runs them.
* **For the criterion.** If the criterion's wording led to the wrong verdict, Mini suggests a new one. **History** shows **Suggested editing this criterion**, and the change only applies once someone accepts it.
Your note is context for the next run, never an automatic pass. Mini still judges every criterion from what it sees on the device.
## See what Mini learned
**Test suite → Knowledge** shows what Mini reads before every run, and where each piece came from. Two parts matter here:
* **Recently learned** lists what Mini changed in its knowledge on its own. Open one to see the change.
* Each change names its source, and a change that came from your triage reads **Not a bug feedback**. **History** on each tab lists every change, and **Restore this version** puts an earlier one back from the next run.
The full tour of the page, and what to write down yourself, is on [Knowledge](/docs/minitest/setup/knowledge).
## See how a criterion changed
Every acceptance criterion keeps its versions. Open the scenario from **Tests**, click **More actions** (the **⋯** button), then **Criteria history**, and pick the criterion.
Each version shows its number, **Current** on the latest, when it changed, who changed it, and where the change came from:
| Source | What it means |
| - | - |
| **Initial** | The criterion as it was first written. |
| **Manual edit** | Someone on your team edited it. |
| **Mini suggestion accepted** | Mini proposed the wording and someone accepted it. |
| **Mini suggestion (edited) accepted** | Someone adjusted Mini's proposal before accepting it. |
| **Reverted** | Someone went back to an earlier version. |
Each version also counts the runs where it passed and failed. **Revert** brings an earlier wording back as a new version, so the history stays intact. Like a manual edit, it moves the criterion's open issues to **Fixed**, waiting for the next run to confirm.
## When the same issue comes back
If a criterion you marked **Not a bug** fails again, its issue opens flagged **Came back after "Not a bug"**, with your earlier note under **Prior feedback**. Two actions help: **Improve the feedback**, to give Mini the context it missed, and **Reconsider the criterion** when it keeps flipping between pass and fail, which usually means it needs rewording.
## Feedback inside a draft
When a check on a draft fails and you think Mini is wrong, click **Not a bug** and tell Mini what it got wrong. Mini fixes the scenario and checks it again, without using up a fix attempt. See [Working with Mini](/docs/minitest/suite/workbench).
## Next steps
> [card] [Knowledge](/docs/minitest/setup/knowledge)
>
> What Mini knows about your app, and how to edit it.
> [card] [Triage issues](/docs/minitest/triage/issues)
>
> Fix, file a ticket, set aside or mark Not a bug.
> [card] [Verdicts and severity](/docs/minitest/runs/verdicts)
>
> What each verdict means, and when to override one.
# How Mini tests your app
Source: https://www.minitap.ai/docs/minitest/get-started/how-mini-tests
What Mini does while it runs a scenario. How it reads the screen, decides what to do next, checks every action, and decides each acceptance criterion.
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](/docs/minitest/runs/triggering-a-run), before Mini does anything:
1. A device or browser is ready, with your [build](/docs/minitest/setup/builds-from-repo) installed and the app launched, or your web app open.
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](/docs/minitest/suite/anatomy).
Mini then reads the scenario, its acceptance criteria, and [Mini's memory](#what-mini-knows-before-it-starts) for your app. If the scenario has a [test account](/docs/minitest/setup/test-accounts), Mini signs in with it. Email codes, phone OTP, and Google sign-in are handled for it.
## The test loop
```text theme={"theme":{"light":"github-light","dark":"vesper"}}
Observe → Act → Check → (repeat) → Judge each criterion
```
**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, 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. For loading, Mini 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](/docs/minitest/runs/run-report#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 **severity** (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](/docs/minitest/runs/run-report).
## 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.
* The steps Mini took.
* What Mini observed for each criterion, and why it reached its verdict.
* A [fix prompt](/docs/minitest/runs/run-report#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](/docs/minitest/triage/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 severity 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:
* **[Knowledge](/docs/minitest/setup/knowledge)** about 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](/docs/minitest/get-started/how-mini-learns).
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.
| Instead of | Write |
| - | - |
| The checkout works | After tapping **Pay**, the order confirmation screen shows an order number |
| The page loads fast | The product list appears without an error message |
| The test account looks good | The test account shows the name and email used to sign up |
| The notification is sent | A banner saying "Order shipped" appears in the app |
See [how to write a scenario](/docs/minitest/suite/anatomy) for more.
# Meet Mini
Source: https://www.minitap.ai/docs/minitest/get-started/meet-mini
The AI QA engineer on your team. What it takes off your plate, where it runs, and where you'll work with it.
Mini is the AI QA engineer that joins your team. It writes your scenarios, runs them on every build, keeps them in step with the app and triages whatever fails. Your QA and engineering teams keep the calls that matter: what to cover, what counts as a bug, and when to ship.
## What Mini takes off your plate
> [card] [Writing the suite](/docs/minitest/suite/anatomy)
>
> Mini reads your code, your docs and your existing test plan, explores the app, and drafts the scenarios worth running.
> [card] [Running it](/docs/minitest/runs/triggering-a-run)
>
> On every pull request, on a schedule, from Slack, Jira or the CLI. Scenarios that don't depend on each other run in parallel.
> [card] [Keeping it current](/docs/minitest/suite/mini-maintains-your-suite)
>
> A screen moves or a feature ships, and Mini updates the scenarios to match this week's build.
> [card] [Triaging failures](/docs/minitest/triage/issues)
>
> Each failure comes with the video, the criterion that broke, device logs and a fix prompt for Cursor or Claude.
Mini also points out what you didn't ask it to check, like a button below the fold or a confusing empty state. Those land as [suggestions](/docs/minitest/triage/suggestions), and you decide which are worth your time.
## Where Mini runs
| App | Devices |
| - | - |
| **iOS** | Cloud simulators, or iPhones assigned to your workspace |
| **Android** | Cloud emulators, or Android phones assigned to your workspace |
| **Web** | Chrome, Firefox and Edge, plus Safari on iPhone and Chrome on Android |
Mini [builds your app from your repository](/docs/minitest/setup/builds-from-repo) or takes the build you upload. It signs in with the [test accounts you attach](/docs/minitest/setup/test-accounts), and handles email codes, phone OTP and Google sign-in on its own. For Google sign-in, Minitap maintains the accounts for you.
## Mini learns from your team
When you mark a result as **Not a bug** and say why, Mini keeps that for the next run, for the whole app or for that one scenario. The same false alarm doesn't come back. See [How Mini learns](/docs/minitest/get-started/how-mini-learns).
## Where you'll work with Mini
> [card] [In the dashboard](https://app.minitap.ai)
>
> Chat with Mini, review scenarios, watch runs and triage issues.
> [card] [In Slack](/docs/minitest/integrations/mini-in-slack)
>
> Live progress for every run, runs started from a message, and triage in the thread.
> [card] [On your pull requests](/docs/minitest/integrations/github)
>
> A Minitap check on every PR, green when the suite passes on that build.
> [card] [From your editor](/docs/minitest/integrations/cursor-and-claude)
>
> Your coding agent writes scenarios and starts runs through the CLI.
# Quickstart: mobile app
Source: https://www.minitap.ai/docs/minitest/get-started/quickstart
From your invitation to the first regression run of your iOS or Android app. About ten minutes of your time; Mini does the rest.
You give Mini an app, a few accounts and some context. Mini explores the app, writes the scenarios, checks each one on a device and runs your first regression. This page walks through that path for an iOS or Android app, in the order the dashboard shows it. Testing a web app? Follow the [web quickstart](/docs/minitest/get-started/quickstart-web).
> [!NOTE]
>
> Minitap is invite-only for now. [Book a call](https://cal.com/team/minitap/minitap-get-access?overlayCalendar=true) and we'll send your invitation after a short walkthrough.
**1. Accept your invitation**
Open the invitation email, sign in, and click **Get started** on the welcome screen. Your workspace is already created; you land straight in the setup.
**2. Connect your code and your tools**
Three optional screens, each with a **Set up later** button:
* **Your repository** on GitHub, GitLab or Bitbucket. Mini builds your iOS and Android apps from any commit and posts a check on your pull requests. See [GitHub](/docs/minitest/integrations/github).
* **Slack**, for live run updates in a channel and runs started from a message. See [Mini in Slack](/docs/minitest/integrations/mini-in-slack).
* **Jira and Confluence, Linear or Notion**, so Mini reads your tickets and docs and files what it finds in your tracker.
You can connect any of them later from **Settings → Integrations**.
**3. Tell Mini about your app**
**Let's get Mini ready** is a short conversation. Mini asks for:
* **The app**: a name, the **Mobile app** type, and its platforms.
* **What to test**: a branch of your repository, or an `.ipa`, `.apk` or `.aab` you upload. See [Upload a build](/docs/minitest/setup/upload-a-build).
* **Test accounts**, one per kind of user Mini should sign in as. Pick **My app has no sign-in** if there's nothing to sign in to.
* **Context** about your product: special flows, expected behaviors, environment details. Documents work too.
* **Your existing tests**, if you have any. Upload a CSV export or a zip and Mini imports them, case IDs included.
Skip anything you don't have yet. Mini asks again later when it needs it.
**4. Mini explores your app**
Mini installs the build on a device and walks through the app screen by screen. You can watch it live. When it's done, it shows you the map of screens it found and asks **Happy with the map?**
**5. Review the scenarios**
From the map and everything you shared, Mini drafts the scenarios worth running, each with its acceptance criteria. Every draft is checked on a device before it counts as ready. If Mini hits something it can't guess, like a missing account or an ambiguous expected result, it asks you in the chat.
**6. Run your first regression**
Click **Approve & run first regression**. If a few questions are still open, **Skip & run** starts the scenarios that are ready now and keeps the others as drafts until you answer.
## What you get back
A run report: a verdict for every scenario, the video of the device, and for each failure the criterion that broke, the device logs and a [fix prompt](/docs/minitest/runs/run-report#fix-prompt) ready for Cursor or Claude.
A scenario in the run report.
## Next steps
> [card] [Check every pull request](/docs/minitest/runs/pull-request-checks)
>
> Get a verdict on each PR before it merges.
> [card] [Read a run report](/docs/minitest/runs/run-report)
>
> What each verdict means and how to act on a failure.
> [card] [Shape your scenarios](/docs/minitest/suite/anatomy)
>
> What a scenario contains, and the parts only you can provide.
> [card] [Work with Mini in the chat](/docs/minitest/get-started/working-with-mini)
>
> Ask for new scenarios, import a test plan, explain a result.
# Quickstart: web app
Source: https://www.minitap.ai/docs/minitest/get-started/quickstart-web
From your invitation to the first regression run of your web app, on the browsers and screen sizes your users have.
You give Mini a URL or a repository, a few accounts and some context. Mini opens your site in a browser, explores it, writes the scenarios, checks each one and runs your first regression. This page walks through that path for a web app, in the order the dashboard shows it. Testing an iOS or Android app? Follow the [mobile quickstart](/docs/minitest/get-started/quickstart).
> [!NOTE]
>
> Minitap is invite-only for now. [Book a call](https://cal.com/team/minitap/minitap-get-access?overlayCalendar=true) and we'll send your invitation after a short walkthrough.
**1. Accept your invitation**
Open the invitation email, sign in, and click **Get started** on the welcome screen. Your workspace is already created; you land straight in the setup.
**2. Connect your code and your tools**
Three optional screens, each with a **Set up later** button:
* **Your repository** on GitHub, GitLab or Bitbucket. For a web app, Mini builds and serves each commit it tests, so you don't need a deployed URL, and it posts a check on your pull requests. See [GitHub](/docs/minitest/integrations/github).
* **Slack**, for live run updates in a channel and runs started from a message. See [Mini in Slack](/docs/minitest/integrations/mini-in-slack).
* **Jira and Confluence, Linear or Notion**, so Mini reads your tickets and docs and files what it finds in your tracker.
You can connect any of them later from **Settings → Integrations**.
**3. Tell Mini about your app**
**Let's get Mini ready** is a short conversation. For a web app, Mini asks for:
* **The app**: a name, and **Web app** as its kind.
* **Where people open it**: pick the devices and browsers your users have, and Mini tests the same ones. You need at least one.
* **Your repository**, if you didn't connect it earlier. With a repository, Mini builds every commit itself.
* **The URL** to open, when there's no repository: your production site, a staging host or any address Mini can reach.
* **Test accounts**, one per kind of user Mini should sign in as. Pick **My app has no sign-in** if there's nothing to sign in to.
* **Context** about your product: specs, designs, boards. Documents work too.
* **Your existing tests**, if you have any. Upload a zip, a CSV export, Markdown or a PDF and Mini starts from there.
* **Files** your scenarios upload, like a photo or a document.
Skip anything you don't have yet. Mini asks again later when it needs it.
**4. Mini explores your app**
Mini opens your site in a browser and walks through it page by page. You can watch it live. When it's done, it shows you the map of screens it found and asks **Happy with the map?**
**5. Review the scenarios**
From the map and everything you shared, Mini drafts the scenarios worth running, each with its acceptance criteria. Every draft is checked in a browser before it counts as ready. If Mini hits something it can't guess, like a missing account or an ambiguous expected result, it asks you in the chat.
**6. Run your first regression**
Click **Approve & run first regression**. If a few questions are still open, **Skip & run** starts the scenarios that are ready now and keeps the others as drafts until you answer.
## Browsers you can pick
| Device | Browsers |
| - | - |
| **Desktop** | Chrome, Firefox, Edge |
| **Tablet** | Chrome, Firefox, Edge |
| **Mobile** | Chrome on Android, Safari on iPhone |
Each browser you pick becomes a default target for the app's runs. You can change the list later and pick other targets for a single run. See [Web apps](/docs/minitest/setup/web-apps).
## What you get back
A run report: a verdict for every scenario and browser, the recording of the session, and for each failure the criterion that broke, the logs and a [fix prompt](/docs/minitest/runs/run-report#fix-prompt) ready for Cursor or Claude.
## Next steps
> [card] [Test staging and preview URLs](/docs/minitest/setup/web-apps)
>
> Point a run at a preview deployment and pick browsers per run.
> [card] [Reach a private site](/docs/minitest/setup/private-apps)
>
> For a site behind a firewall, a VPN or a country restriction.
> [card] [Run on every pull request](/docs/minitest/runs/triggering-a-run)
>
> Add the GitHub Action so each PR gets a verdict before it merges.
> [card] [Read a run report](/docs/minitest/runs/run-report)
>
> What each verdict means and how to act on a failure.
# Ask Mini
Source: https://www.minitap.ai/docs/minitest/get-started/working-with-mini
Talk to Mini about your app in plain language, what it asks your OK for, what it never does on its own, and how to point it at a run or a scenario with @.
**Ask Mini**, at the top of your app's sidebar, is where you talk to Mini in plain language: ask why a run failed, what your suite misses, or have it write and change scenarios. This page covers what to ask, how Mini checks with you before it acts, and how to point it at the exact run or scenario you mean.
Ask Mini, with a few starters.
## Where to find it
Click **Ask Mini** at the top of the app sidebar. The conversation sits in the middle and your **Chat history** on the right; **New chat** starts a fresh one. Other pages open the same conversation when they hand you to Mini, like **Tests → New test → Ask Mini** or **Ask Mini about this scenario** in a draft, so you can move between pages without losing a reply in progress.
Mini knows which page you're on. On a run, "why did this fail?" is about that run.
## What to ask
An empty conversation suggests a few starters under **Try Mini for…**. A few things Mini is good at:
| You want | Ask, for example |
| - | - |
| Where the app stands | "How is this app doing right now?" |
| To understand a failure | "Explain the last failed run and what to do about it." |
| To triage | "Summarise the open issues, most critical first." |
| Coverage | "Which flows of this app have no test scenario yet? List them, most important first." |
| A new scenario | "On Android, search for a phone and turn on the filter switch." |
| Better criteria | "Review the acceptance criteria of my test scenarios and tighten the vague ones." |
| Flaky scenarios | "Which test scenarios are flaky or blocked, and how do I fix them?" |
| A test account | "Create a test account for a returning customer, with the account and data it needs." |
When you ask how to set something up, Mini answers and links the page of these docs that covers it.
To hand Mini your existing test plan, attach the file with the paperclip or drop it on the chat: see [Import your existing tests](/docs/minitest/suite/import-tests).
## Point at things with @
Type `@` in the message box to mention something from your app. A list opens above the box, with a tab per type: **Scenarios**, **Criteria**, **Runs**, **Issues**, **Builds** and **Test accounts**. During onboarding, **Screens** from the [screen map](/docs/minitest/suite/exploration) are there too.
```text theme={"theme":{"light":"github-light","dark":"vesper"}}
Did @Checkout with saved card pass on @v2.3.1 (57)? If it failed, which criterion broke?
```
Arrow keys move through the list, Enter inserts the mention, Tab switches type and Escape closes it. A mention becomes a chip that you delete in one keystroke. Paste a link or an ID right after `@` and the list shows only what it names. Mini reads everything you mention before it answers.
## Mini proposes, you confirm
Before anything that changes your suite or uses device time, Mini tells you its plan in a sentence or two, like what it will create or change and how much of it, and waits for your answer. You'll usually see **Yes, do it**, along with other choices or **Something else…** to answer in your own words. When Mini has several questions, it asks them one after the other and sends your answers together.
Some requests are already your OK, so Mini goes ahead without asking again:
* **Tests → New test → Ask Mini**, where you describe what someone should be able to do.
* Asking Mini to import your test cases.
* A deletion or cancellation you asked for in so many words.
When Mini is waiting on you, a bar above the message box says how many things need you, with a button to the question.
## What Mini never does on its own
* **Start a run.** Mini can't start runs from the chat. Ask for one and it points you to **Run tests**, or start it from CI, Slack or the CLI: see [Triggering a run](/docs/minitest/runs/triggering-a-run).
* **Commit for real in your app.** Mini won't place an order or make a booking during a test unless you've told it that's fine, for example "you can make test bookings".
* **Call a scenario ready.** A new scenario is a draft until Mini has checked it on a device: the screens exist, the test account works, and the criteria can be observed. Walking the app in the chat doesn't count as that check.
## Where Mini's changes land
When Mini changes your suite from the chat, it says what changed in a line or two, including anything it removed. New scenarios start as drafts and join your runs once Mini has checked them on a device.
For a change that spans several scenarios, like a redesigned flow, open a draft in [Workbench](/docs/minitest/suite/workbench) with **Draft a change**. Mini writes the whole change there and proves it on a device, and your suite only changes when you merge.
## Next steps
> [card] [Import your existing tests](/docs/minitest/suite/import-tests)
>
> Turn your test plan into scenarios, case IDs included.
> [card] [Workbench](/docs/minitest/suite/workbench)
>
> Bigger changes, checked on a device before they merge.
> [card] [Write scenarios by hand](/docs/minitest/suite/authoring)
>
> The New test menu and every field of a scenario.
> [card] [Mini in Slack](/docs/minitest/integrations/mini-in-slack)
>
> Talk to Mini from your team's channels.
# Welcome to Minitap
Source: https://www.minitap.ai/docs/minitest/index
Your AI QA engineer, on every build of your mobile and web apps.
Minitap gives your team **Mini**, an AI QA engineer. You tell Mini which journeys in your iOS, Android or web app matter, in plain English. It tests them on every build, keeps the tests in step with your app, and comes back with a verdict and the proof behind it.
A run report: each finding with Expected and Actual, and a recording that jumps to the moment every criterion was decided.
## Start here
> [card] [Quickstart for mobile](/docs/minitest/get-started/quickstart)
>
> Connect your iOS or Android app and watch Mini run your first regression.
> [card] [Quickstart for web](/docs/minitest/get-started/quickstart-web)
>
> Point Mini at your web app's URL and pick the browsers to test.
> [card] [Meet Mini](/docs/minitest/get-started/meet-mini)
>
> What Mini does for your team, from the first scenario to every release after.
> [card] [Security and data](/docs/minitest/workspace/security)
>
> Where Minitap runs, what it stores, and what the models see.
## How it works
**1. Describe what has to keep working**
Write it the way you'd brief a new tester: "a returning user signs in and lands on the home screen." Mini turns that into a scenario with acceptance criteria you can read and edit. Connect your repo and Mini drafts the first scenarios from your code. Already have a test plan? Drop the spreadsheet in the chat and Mini imports it, case IDs included.
**2. Mini tests every build**
Start a run from the dashboard, Slack, your CI or a pull request. Mini drives the app like a user: it reads the screen, taps, types and checks each step, on virtual or physical devices. When a screen moves or a feature ships, Mini [updates the scenarios](/docs/minitest/suite/mini-maintains-your-suite) so your coverage follows this week's build.
**3. You get a verdict you can act on**
Every run ends with **Passed**, **Warning** or **Failed**. A failure comes with the video, the criterion that broke, device logs and a [fix prompt](/docs/minitest/runs/run-report#fix-prompt) ready to paste into Cursor or Claude. Tell Mini when it got something wrong and it [remembers](/docs/minitest/get-started/how-mini-learns) on the next run.
## Plug Mini into your day
> [card] [Pull requests](/docs/minitest/integrations/github)
>
> A check on every PR, green when the suite passes.
> [card] [Slack](/docs/minitest/integrations/mini-in-slack)
>
> Live progress for every run, and triage from the thread.
> [card] [Cursor and Claude](/docs/minitest/integrations/cursor-and-claude)
>
> Write scenarios and upload builds from your editor.
> [!TIP]
>
> **Working with an AI assistant?** Point it at [llms.txt](https://www.minitap.ai/docs/llms.txt) or the docs MCP server, and it answers from the current docs. See [Docs for AI agents](/docs/minitest/reference/for-ai-agents).
## Need a hand?
Read the [FAQ](/docs/minitest/get-started/faq), or [book a call with the team](https://cal.com/team/minitap/minitap-get-access?overlayCalendar=true) and we'll walk you through Mini on your own app.
# Coding agents
Source: https://www.minitap.ai/docs/minitest/integrations/cursor-and-claude
Connect Cursor, Claude Code or any MCP client to Minitap, so your coding agent can write scenarios, start runs, read results and fix what Mini found.
Your coding agent already knows the feature you just shipped. Connect it to Minitap and it can write the scenarios for it, start a run on your build, read the verdicts and fix what failed. There are two ways in, and they work together: the MCP server and the `minitest` CLI.
| | MCP server | CLI |
| - | - | - |
| Best for | Agents in Cursor, Claude Code, Windsurf or any MCP client | Agents that run shell commands, scripts and CI |
| Sign-in | Your Minitap account, in the browser, on first use | `minitest auth login` once per machine, or an API key in CI |
| What the agent can do | List apps, write and edit scenarios, manage test accounts and test files, find builds, start runs and read their results, search these docs | Everything in the dashboard that has a command, from uploading builds to schedules |
## Connect the MCP server
The server lives at `https://testing-service.app.minitap.ai/mcp/`. Add it to your client, then sign in with your Minitap account when the client asks.
> [tab] Claude Code
>
> ```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
> claude mcp add --transport http minitap https://testing-service.app.minitap.ai/mcp/
> ```
> [tab] Cursor
>
> In `.cursor/mcp.json` at the root of your project, or `~/.cursor/mcp.json` for every project:
>
> ```json theme={"theme":{"light":"github-light","dark":"vesper"}}
> {
> "mcpServers": {
> "minitap": {
> "url": "https://testing-service.app.minitap.ai/mcp/"
> }
> }
> }
> ```
> [tab] Other clients
>
> Add a remote HTTP server with the URL `https://testing-service.app.minitap.ai/mcp/`. Authentication is OAuth: the client opens a browser window for you to sign in.
The server loads two skills into your agent's context on its own: an onboarding playbook (discover the app, create test accounts, map the journeys, create the scenarios) and the rules for writing good scenarios. Your agent follows the same practices Mini does.
Then ask, from your app's codebase:
```text theme={"theme":{"light":"github-light","dark":"vesper"}}
Using the Minitap MCP server, read this codebase and create scenarios for the key user journeys: the core flows, the meaningful interactions and the edge cases that matter. Aim for a representative suite, then tell me which scenarios you created.
```
## Use the CLI
**1. Install the CLI**
```bash macOS / Linux theme={"theme":{"light":"github-light","dark":"vesper"}}
curl -fsSL https://raw.githubusercontent.com/minitap-ai/minitest-cli/main/install.sh | bash
```
```powershell Windows theme={"theme":{"light":"github-light","dark":"vesper"}}
powershell -ExecutionPolicy ByPass -c "irm https://raw.githubusercontent.com/minitap-ai/minitest-cli/main/install.ps1 | iex"
```
**2. Sign in**
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
minitest auth login
```
It opens a browser, pairs the CLI with your workspace and keeps a token on the machine.
**3. Let your agent drive it**
The CLI ships with an agent skill, so your agent uses the same commands you would, with the same rules for scenarios, criteria and dependencies:
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
# The apps you can see
minitest apps list
# Upload a build
minitest --app myapp build upload ./path/to/build.ipa
# Run two scenarios together and wait for the verdict
minitest --app myapp run start "Sign up" "Checkout" --watch
```
Every command takes `--json`. Pick the app with `--app `, or `export MINITEST_APP_ID=...` once per shell. See [CLI commands](/docs/minitest/reference/cli-commands).
## Fix with your agent
When a scenario fails, open its **Fix with your agent** tab in the run report, copy the prompt and paste it into your coding agent. The agent reads Mini's verdicts, the screens and the logs through the CLI, finds the root cause in your code, explains it and asks before it changes anything. See [Read a run report](/docs/minitest/runs/run-report#fix-prompt).
The Fix with your agent tab of a scenario.
## Next steps
> [card] [What a scenario is](/docs/minitest/suite/anatomy)
>
> The shape your agent writes: name, criteria, tags, dependencies.
> [card] [CLI commands](/docs/minitest/reference/cli-commands)
>
> Every command and flag.
# GitHub
Source: https://www.minitap.ai/docs/minitest/integrations/github
Install the Minitap GitHub App, link each app to its repository, and connect GitLab or Bitbucket.
Connecting your repository lets Mini build your app from any commit, keep your scenarios in step with your code, and show up on your pull requests. This page covers installing the Minitap GitHub App, linking an app to its repository, and connecting GitLab or Bitbucket. For what Mini posts on a pull request, see [Pull request checks](/docs/minitest/runs/pull-request-checks).
## Do you need it?
You can test an app without a repository: upload builds yourself, from the dashboard or the CLI. Connecting one adds:
* Builds of any branch or commit, made by Mini. See [Builds from your repository](/docs/minitest/setup/builds-from-repo).
* Scenarios that follow your code changes. See [Mini maintains your suite](/docs/minitest/suite/mini-maintains-your-suite).
* On GitHub, a comment and a check on your pull requests. See [Pull request checks](/docs/minitest/runs/pull-request-checks).
## Install the GitHub App
**1. Open the integrations**
Go to **Settings → Integrations → GitHub** and click **Connect**. Only workspace owners and admins can connect it.
**2. Pick the organization and repositories**
GitHub's install screen opens. Pick the organization, then grant **All repositories** or **Only selected repositories**.
**3. Come back to Minitap**
The organization and its repositories show on the GitHub card. Use **Add account** to install the App on another organization, and **Manage on GitHub** to change which repositories it can see.
One install covers every app in your workspace that lives in that organization. GitHub may still show the App under its former name, MiniTest.
## Link an app to its repository
In the app's **Builds & test data → Builds**, set:
* **Repository**: picked from the repositories the App can see.
* **Default branch**: builds and maintenance run against this branch, and pull requests into it get Mini's comment.
* **Source folder** (optional): where the app lives in the repository, for monorepos. Pull requests that change nothing under it are skipped.
Once the app is linked, its settings show **CI & Maintenance**, where you set the release branches, the release tag pattern and **Block merge on failing tests**. Those are explained in [Pull request checks](/docs/minitest/runs/pull-request-checks).
## Run from your workflows
The [GitHub Action](/docs/minitest/reference/minitest-trigger-action) starts a run from any workflow and signs in with GitHub OIDC, so there's no key to store. The App must be installed on the organization first. See [Ways to start a run](/docs/minitest/runs/triggering-a-run#github-action).
## GitLab and Bitbucket
Mini builds and tests from GitLab and Bitbucket repositories too, and keeps your scenarios in step with the code. Connect them from **Settings → Integrations**:
| Provider | How to connect |
| - | - |
| **GitLab** | **Connect GitLab.com** to connect a group, or **Self-hosted** for your own instance: enter the instance URL and a group or personal access token with the `api` and `read_repository` scopes. |
| **Bitbucket** | **Connect** a Bitbucket workspace. |
Comments and checks on pull requests are GitHub only. To gate a GitLab or Bitbucket pipeline on the verdict, run Mini from it with the [CLI](/docs/minitest/runs/triggering-a-run#cli-for-any-ci).
## Removing the App
Uninstall it from the organization's GitHub settings, under the installed GitHub Apps. Minitap keeps your run history and configuration, but builds from that organization and pull request checks stop. Reinstalling restores them.
## Next steps
> [card] [Pull request checks](/docs/minitest/runs/pull-request-checks)
>
> The comment, the check and the merge gate on each pull request.
> [card] [Builds from your repository](/docs/minitest/setup/builds-from-repo)
>
> How Mini builds your iOS, Android and web apps from a commit.
> [card] [GitHub Action reference](/docs/minitest/reference/minitest-trigger-action)
>
> Every input of the Action, with examples.
# Integrations
Source: https://www.minitap.ai/docs/minitest/integrations/index
Every tool Minitap connects to, what Mini does with each one, and where to set it up.
Mini works in the tools your team already uses: it builds from your repository, posts on your pull requests and in Slack, reads your tickets and specs, and files what it finds in your tracker. This page lists every integration and how far each one goes, so you can pick the ones worth connecting.
Connect them from **Settings → Integrations**. Connecting a repository, Linear or Jira takes a workspace owner or admin.
## Code and CI
| Integration | What Mini does with it | Docs |
| - | - | - |
| **GitHub** | Builds your app from any commit and keeps the scenarios in step with your code. Comments on pull requests to your main or release branches with a box to tick to run the tests, answers `@mini test`, and posts a check named after your app on every run. The check informs by default; turn on **Block merge on failing tests** and branch protection can require it. | [GitHub](/docs/minitest/integrations/github), [Pull request checks](/docs/minitest/runs/pull-request-checks) |
| **GitHub Action** | Starts a run from any workflow, signed in with GitHub OIDC. Uploads your build or asks Mini to build the commit, picks the browsers for web runs, and can wait for the verdict to hold a release. On a release tag, runs only the scenarios affected since the previous tag. | [GitHub Action reference](/docs/minitest/reference/minitest-trigger-action) |
| **CLI, for any CI** | GitLab CI, CircleCI, Jenkins, Azure Pipelines and Bitbucket Pipelines run Mini through the CLI with a workspace API key. It uploads your `.ipa`, `.apk`, `.apks` or `.aab`, starts runs, and reads every verdict as JSON. | [Ways to start a run](/docs/minitest/runs/triggering-a-run#cli-for-any-ci) |
| **GitLab and Bitbucket** | Connect a GitLab group (self-hosted too) or a Bitbucket workspace: Mini builds from your repositories and keeps the scenarios in step with your code. Comments and checks on pull requests are GitHub only; gate a pipeline through the CLI. | [GitHub](/docs/minitest/integrations/github#gitlab-and-bitbucket) |
| **TestFlight** | Add Minitap's tester to TestFlight once, paste a build's link, and Mini runs that build on physical iPhones, where your workspace has them. | [Upload a build](/docs/minitest/setup/upload-a-build) |
## Where your team talks
| Integration | What Mini does with it | Docs |
| - | - | - |
| **Slack** | Posts one message per run and edits it as the run goes. Each issue gets a thread with a clip of the failure and **Acknowledge**, **Not a bug** and **Resolved** buttons. A scheduled run posts one summary. Start runs with `@mini run`, and Mini asks in the channel when it needs context or a test account. | [Mini in Slack](/docs/minitest/integrations/mini-in-slack) |
## Tickets and specs
| Integration | What Mini does with it | Docs |
| - | - | - |
| **Jira** | Reads your tickets, their comments, attachments and test cases for context. Mention `@Mini` in a Jira comment and it tests the ticket, then replies there with the report, the recording and the scenario. Files a ticket from an issue, a UI/UX suggestion or a failed criterion, or links a ticket you already have. | [Jira](/docs/minitest/integrations/jira) |
| **Linear** | Files a Linear issue from an issue, a UI/UX suggestion or a failed criterion, with the steps to reproduce and the recording. Or links the issue you already have, and its status shows beside the finding. | |
| **Notion** | Reads the specs and PRDs your team already wrote, and writes scenarios from them. Sends a finding to a Notion database as a new page, or links a page you already have. | |
| **Figma** | Opens the designs linked in your tickets, so Mini knows what the screen should look like. | |
## Coding agents
| Integration | What Mini does with it | Docs |
| - | - | - |
| **MCP server** | Your coding agent in Cursor, Claude Code or Windsurf signs in to Minitap's MCP server. It can read and edit scenarios, test accounts and builds, start runs and read their results. | [Coding agents](/docs/minitest/integrations/cursor-and-claude) |
| **Fix prompts** | Every failed criterion has a fix prompt: the root cause, the steps to reproduce and a proposed fix, ready to paste into your coding agent. The CLI ships a skill so the agent can run Mini itself. | [Fix prompt](/docs/minitest/runs/run-report#fix-prompt) |
## What Mini gets access to
* **GitHub**: the repositories you pick when you install the Minitap GitHub App.
* **Slack**: Mini joins your public channels and posts each run to the channel you pick. Anything started from Slack runs as that person's own Minitap account.
* **Jira, Linear and Notion**: Mini reads what you connect, and writes only the tickets you send and its replies to `@Mini`.
* **CLI and MCP server**: a workspace API key or your own sign-in.
For how Minitap handles your data, see [Security](/docs/minitest/workspace/security).
## Next steps
> [card] [Install the GitHub App](/docs/minitest/integrations/github)
>
> Builds from your repository, and Mini on your pull requests.
> [card] [Connect Slack](/docs/minitest/integrations/mini-in-slack)
>
> Live runs in a channel, and runs started from a message.
> [card] [Mini on Jira](/docs/minitest/integrations/jira)
>
> Tickets with the recording, and `@Mini` in any comment.
> [card] [Connect your coding agent](/docs/minitest/integrations/cursor-and-claude)
>
> The MCP server and the CLI for Cursor and Claude Code.
# Jira
Source: https://www.minitap.ai/docs/minitest/integrations/jira
Let Mini read your Jira tickets, test a ticket when someone mentions @Mini in a comment, and file what it finds as Jira tickets.
Connect Jira and Mini works from your tickets: it reads them for context, tests a ticket when someone mentions `@Mini` in a comment and answers right there, and turns any finding into a Jira ticket with the steps to reproduce and the recording. This page covers both connections and what each one gives you.
| Connection | What it gives you | Who sets it up |
| - | - | - |
| **Atlassian** | Mini reads your boards, sprints and tickets for context, and you file or link Jira tickets from findings. | A workspace owner or admin, from **Settings → Integrations** |
| **Mini on Jira** | `@Mini` in a Jira comment tests the ticket and replies on it. | A Jira site admin, then a workspace admin to confirm |
## Connect Atlassian
Go to **Settings → Integrations → Atlassian**, click **Connect** and approve access with your Atlassian account. From then on:
* Mini reads your Jira tickets, their comments, screenshots and the test cases you keep there, and uses them as context when it writes and runs scenarios.
* Findings get a Jira option when you file a ticket. See [File a ticket from a finding](#file-a-ticket-from-a-finding).
## Set up Mini on Jira
**1. Start from Jira**
A Jira site admin opens Jira settings, then **Apps**, then **Mini**, and clicks **Connect to Minitest**. The link it opens lasts 15 minutes and works once.
**2. Pick the workspace**
An admin of your Minitap workspace confirms which workspace Mini works for and clicks **Connect site**. Mini tests any app of that workspace, and the workspace's credits pay for the tests. A Jira site works with one workspace, and a workspace with one Jira site.
**3. Each person links their Jira account**
The first time someone mentions `@Mini`, Mini replies with a link to connect their Jira account to their Minitap account. They can also do it from **Mini** in their Jira personal settings. Minitap stores only the Jira account ID and display name.
The **Mini on Jira** panel in **Settings → Integrations** shows the connected site, how many members linked their Jira account, and your own link, which you can **Unlink** at any time.
## Mention @Mini on a ticket
Write a comment that mentions `@Mini` on the ticket you want tested:
```text theme={"theme":{"light":"github-light","dark":"vesper"}}
@Mini can you test this on the latest build?
```
Mini reads the ticket with its comments and attachments, works out which app it concerns (and asks when it can't tell), and tests the change against the ticket's acceptance criteria. It replies on the ticket with the run report, the recording and the scenario it ran. Reply in the same thread to steer it: Mini reads every comment.
Mini only writes comments. It never changes a ticket's status or fields.
Every ticket Mini works on also appears in **Mini sessions**, for the whole workspace (open it from **Settings → Integrations** with **See Mini sessions**). A session shows where Mini stands, the drafts it opened, and each criterion with its result and evidence.
## File a ticket from a finding
You can file a Jira ticket from an [issue](/docs/minitest/triage/issues), a [UI/UX suggestion](/docs/minitest/triage/suggestions) or a failed criterion in a [run report](/docs/minitest/runs/run-report).
**1. Open the ticket menu**
Click **Ticket** on the finding and choose Jira.
**2. Link a ticket you already have**
Search Jira by key, words or link, or pick from the recently updated tickets. The finding shows the ticket's status from then on.
**3. Or create a new one**
Click **Create a new Jira ticket**, pick the project, and fill in the fields your Jira project requires. The ticket lands with the steps to reproduce and the recording attached. Use **Link to another ticket** to connect it to an existing ticket with a Jira link type.
## Next steps
> [card] [Triage issues](/docs/minitest/triage/issues)
>
> Decide which failures deserve a ticket.
> [card] [Ways to start a run](/docs/minitest/runs/triggering-a-run)
>
> Every other way to start a run.
> [card] [All integrations](/docs/minitest/integrations)
>
> What else Mini connects to.
# Linear
Source: https://www.minitap.ai/docs/minitest/integrations/linear
File a Linear issue from any Minitap finding, with the steps to reproduce and the recording, or link the issue you already have and see its status.
Connect Linear and any finding becomes a Linear issue in two clicks: an [issue](/docs/minitest/triage/issues), a [UI/UX suggestion](/docs/minitest/triage/suggestions) or a failed criterion in a [run report](/docs/minitest/runs/run-report). If your team already tracks it, link the existing issue instead, and its Linear status shows next to the finding.
## Connect Linear
**1. Open Integrations**
Go to **Settings → Integrations** (also reachable from an app's **App settings → Integrations**). A workspace owner or admin can connect Linear.
**2. Authorize Minitap**
Click **Connect** on the **Linear** row and approve access with your Linear account. Minitap lists the teams that account can see.
You can also connect from a finding: before any tracker is connected, its **Ticket** menu offers **Connect Linear**, and the ticket form opens again when you come back.
## File an issue from a finding
**1. Open the Ticket menu**
Click **Ticket** on the issue, the UI/UX suggestion or the failed criterion. With several trackers connected, pick **Linear** at the top of the menu.
**2. Create a new issue**
Click **Create a new Linear ticket**, then pick the **Team**: type a few letters to search your teams. Minitap loads that team's fields.
**3. Check the fields and create**
Adjust what Minitap preset, then click **Create ticket in Linear**. The finding now shows the issue's key and status, and links to it.
Minitap presets the fields so the issue lands ready to pick up. You only see the fields your team has:
| Field | Preset |
| - | - |
| **Priority** | **High** for a Critical finding, **Medium** for a Warning one |
| **Labels** | Your team's **Bug** label, when it has one |
| **Project** | The team's first project |
| **Status** | The team's backlog state |
| **Assignee** | Nobody |
### What the issue contains
For an issue or a failed criterion, the Linear issue is titled with what went wrong and holds:
* A **View in Minitap** link and a **Watch the recording** link.
* **What happened**, in Mini's words.
* **Root cause analysis**, with the steps to reproduce, the expected and actual behavior when Mini wrote them down.
* A **Context** table: the scenario, the acceptance criterion, the platform, the build and the severity.
For a UI/UX suggestion, it holds what Mini found, the screen, the kind of suggestion, its severity, the scenarios it was seen in, the platform, Mini's notes, and a **View in Minitap** link.
## Link an issue you already have
Open the **Ticket** menu and search instead of creating: type an issue key (`ENG-142`), a few words, or paste the issue's link. With an empty search, the menu shows the recently updated issues. Pick one and the finding is linked to it.
A finding holds one ticket at a time. To change it, open the issue in the **Issues** tab and click **Unlink ticket**: the link goes, and the issue stays in Linear.
## Status in Minitap
Every linked finding shows the issue's key and its current Linear status, such as `ENG-142 · In Progress`, and opens the issue in Linear on click. Minitap reads the status from Linear each time it shows it. If the issue was deleted in Linear, Minitap drops the link.
The finding keeps its own triage status in Minitap: triage it in the [Issues](/docs/minitest/triage/issues) tab.
## From the CLI
The same actions work from the `minitest` CLI, for scripts and coding agents:
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
# Your Linear teams, with their IDs
minitest --app issues ticket targets linear
# File an issue in a team, or link one you have
minitest --app issues ticket create --provider linear --target
minitest --app issues ticket link --provider linear --ticket ENG-142
```
`issues ticket fields linear --target ` lists the fields you can set with `--field KEY=VALUE`. See the [CLI reference](/docs/minitest/reference/cli-commands).
## Next steps
> [card] [Triage issues](/docs/minitest/triage/issues)
>
> Decide which failures deserve a ticket.
> [card] [UI/UX suggestions](/docs/minitest/triage/suggestions)
>
> The polish ideas Mini flags while it tests.
> [card] [Jira](/docs/minitest/integrations/jira)
>
> The same tickets in Jira, plus @Mini in comments.
> [card] [Notion](/docs/minitest/integrations/notion)
>
> Specs for Mini to read, and findings filed as pages.
# Mini in Slack
Source: https://www.minitap.ai/docs/minitest/integrations/mini-in-slack
Connect Slack so Mini posts every run and each scheduled run's summary to your channel, lets you triage issues in thread, and takes @mini requests.
Connect Slack and your team follows Mini where it already talks: one message per run that updates as the run goes, a thread per finding with a clip and triage buttons, one summary after each scheduled run, and `@mini` to start runs or ask for status. This page covers the setup and every message Mini posts.
| Mini posts | When | Where |
| - | - | - |
| A run message, edited as the run goes | Every run you start from the dashboard, CI, the CLI or Slack | The app's run channel |
| A thread reply per issue, with a clip and buttons | When the run finds an issue | Under the run message |
| One summary | After each scheduled run, or when a schedule didn't start | The channel picked on the schedule |
| A question card | When Mini needs an answer to go on | The run's thread |
| A possible bug notice | When maintaining your tests turns up an app bug | The app's run channel |
## Installing
A workspace owner or admin goes to **Settings → Integrations → Slack** and clicks **Connect**, then approves Minitap in Slack. Mini then joins every public channel of your Slack workspace silently, so anyone can ask `@mini` for app health, status or a run. To add it to a private channel, run `/invite @mini` in that channel. You can remove it from any channel later.
After the install, Mini sends the admin a direct message with a link to pick each app's channel.
To disconnect, click **Disconnect** in the same place.
## Channel routing
Each app posts its run messages to one channel. Pick it in either place:
* **Settings → Integrations → Slack → Run channels**: every app with its channel picker. Each row saves on its own.
* **App settings → Notifications → Slack channel**, for one app. Owners and admins can change it.
When you set a channel, Mini posts a welcome message there with a few things to ask it. When you move an app to another channel, Mini posts a short note in the old one saying where its updates now go. **Clear channel** stops the app from posting to Slack until you pick a channel again, and Mini says so in the old channel.
The run channel only decides where Mini posts. You can mention `@mini` in any channel it has joined.
## Talking to Mini
Mention `@mini` and write what you want. Mini works out the request from your words, so phrasing can vary. The full list is in [Mini commands](/docs/minitest/reference/mini-commands).
### Triggering a run
```text theme={"theme":{"light":"github-light","dark":"vesper"}}
@mini run acme-checkout v1.4.2
```
Mini finds the app and the builds matching that version, then shows you a confirmation with **Run now** and **Cancel**. Without a click, the run starts after 10 seconds. `@mini run acme-checkout web` runs the app's default web targets.
```text theme={"theme":{"light":"github-light","dark":"vesper"}}
@mini run all tests
```
This opens a picker instead: the app, the scenarios, the builds, then confirm. See [Ways to start a run](/docs/minitest/runs/triggering-a-run) for every other way.
### Other requests
* `@mini status` replies with the latest verdict, after asking which app when you have several.
* `@mini create test`, `@mini edit test` and `@mini delete test` open a short flow to write, change or remove a scenario without leaving the conversation. See [Write scenarios by hand](/docs/minitest/suite/authoring).
* `@mini create app` starts a new app.
## The run heartbeat
Every run gets one message in the app's channel, posted when the run starts. Mini edits that same message as scenarios finish and issues turn up, at most once every 10 seconds, so the channel stays readable. When the run ends, the message shows the final verdict: a green completion when everything passed, otherwise the breakdown with a link to each issue.
If you started the run from another channel, Mini still posts in the app's channel and replies where you asked with a link to the run message.
Scheduled runs post a summary instead, described [below](#after-each-scheduled-run).
### Issue threads
Each issue a run finds gets a reply under the run message: the criterion that failed, its severity, a link to the run report and a clip of the moment it failed. Triage it with the buttons:
* **Acknowledge** marks the issue as seen.
* **Not a bug** asks why, then sends your feedback to Mini, which learns from it.
* **Resolved** asks you to confirm, then closes the issue. If a later run fails the same criterion, the issue reopens.
After triage, the reply shows who did what, with **Resolved** and **Back to review** in case you change your mind. Actions in Slack and in the dashboard stay in step. See [Triage issues](/docs/minitest/triage/issues).
## After each scheduled run
A [schedule](/docs/minitest/runs/schedules) posts one summary to the channel picked on it, once the run ends:
* A headline that leads with the outcome: all clear, nothing new, new problems, or only part of the suite checked.
* The problems found, each with its severity.
* What was tested, what works again since last time and what is still broken.
* A button to the run, and a footer with the schedule's name, when it runs, and **Change schedule**.
Each problem also gets a thread reply with the steps, what Mini expected and what it got, a link to the recording, and the same triage buttons as a run's issues. If the run is retried, Mini updates the summary in place and marks the problems that now pass as working again.
A schedule that didn't start posts why, for example no build to test or the previous run still going, with a button to fix it. Turn off **Post when all clear too** on the schedule to hear only about problems.
## When Mini needs your team
When Mini can't go on without an answer, such as a test account it doesn't have or how a feature should behave, it posts a card in the run's thread and keeps testing the rest while it waits. Click **Answer** to reply in Slack, or **Skip this** to leave that scenario untested. When the answer is a file, the button opens Minitap to upload it.
When Mini keeps your tests up to date and finds what looks like an app bug, it posts a possible bug notice in the app's channel with **Open the draft**. If someone says it's not a bug, Mini fixes the scenario instead. Otherwise maintenance stays quiet in Slack.
## Linking your account
Anything you do from Slack runs as your own Minitap account, with your role. Mini matches Slack users to Minitap members by email, so you're linked already when both emails match. Otherwise, the first time you reply to Mini or click one of its buttons, it answers with **Link my account**: one click in the dashboard finishes the link, and you only do it once.
Check your link in **Settings → Integrations → Slack**, under **Your Slack account**.
## Next steps
> [card] [Schedules](/docs/minitest/runs/schedules)
>
> Run your scenarios every night and read the summary in Slack.
> [card] [Mini commands](/docs/minitest/reference/mini-commands)
>
> Every `@mini` request, with examples.
> [card] [Triage issues](/docs/minitest/triage/issues)
>
> The same buttons, with the full history in the dashboard.
# Notion
Source: https://www.minitap.ai/docs/minitest/integrations/notion
Let Mini read your specs and PRDs in Notion, and file findings to a Notion database as pages that show their status in Minitap.
Connect Notion and Mini reads the specs and PRDs your team already wrote, so it knows how the app is meant to work when it writes and runs tests. The same connection lets you send any finding to a Notion database as a new page, or link it to a page you already have, with the page's status shown on the finding.
| With Notion connected | Where you see it |
| - | - |
| Mini reads the pages and databases you shared | **Test suite → Knowledge**, under **Mini learns from** |
| Mini uses them in conversations and drafts | **In Mini's context**, in a draft or the onboarding conversation |
| Findings go to a database as pages | The **Ticket** menu on issues, UI/UX suggestions and failed criteria |
## Connect Notion
**1. Open Integrations**
Go to **Settings → Integrations** (also reachable from an app's **App settings → Integrations**). A workspace owner or admin can connect Notion.
**2. Pick what to share**
Click **Connect** on the **Notion** row. Notion asks which pages to share with Minitap: pick the specs, PRDs and product docs Mini should read, and the database your team files bugs in. Mini only reads what you share.
You can also connect Notion while setting up the workspace, or from a finding's **Ticket** menu (**Connect Notion**) before any tracker is connected. To share more later, add the Minitap connection to more pages from Notion.
## Mini reads your specs
Once pages are shared, Mini reads them and keeps what it learns for every chat, scenario and run. It reads new and edited pages on its own. When you ask Mini in a draft to cover a feature, it works from the spec your team wrote.
To see what Mini took in, open **Test suite → Knowledge**. Under **Mini learns from**, the **Notion** source shows **Pages and databases you shared**, how many pages Mini read and when it last read one. Open it to see the pages. Knowledge Mini wrote from a Notion page cites it as its source. See [Knowledge](/docs/minitest/setup/knowledge).
In a draft or the onboarding conversation, the **In Mini's context** panel lists the Notion pages and databases Mini can read, by title. If it says nothing is shared with Minitap right now, the connection works but no page was shared yet.
## File a finding to a database
You can send an [issue](/docs/minitest/triage/issues), a [UI/UX suggestion](/docs/minitest/triage/suggestions) or a failed criterion in a [run report](/docs/minitest/runs/run-report) to Notion.
**1. Open the Ticket menu**
Click **Ticket** on the finding. With several trackers connected, pick **Notion** at the top of the menu.
**2. Create a new page**
Click **Create a new Notion ticket**, then pick the **Database**: type a few letters to search the databases shared with Minitap.
**3. Set the properties and create**
Minitap shows the database's select, multi-select and status properties. A status starts on the database's first to-do option. Click **Create ticket in Notion**.
The new page takes the finding's title in its title property. Its content holds the report: a **View in Minitap** link and, for an issue or failed criterion, a **Watch the recording** link, what happened, Mini's root cause analysis with the steps to reproduce, and a context table with the scenario, criterion, platform, build and severity. A UI/UX suggestion's page holds what Mini found, the screen, its severity and the scenarios it was seen in.
## Link a page you already have
Open the **Ticket** menu and search instead of creating. Notion pages have no short key, so search by title or paste the page's link. Typed words match rows of your shared databases; with an empty search, the menu shows the recently updated ones. Pick a page and the finding is linked to it.
A finding holds one ticket at a time. To change it, open the issue in the **Issues** tab and click **Unlink ticket**: the link goes, and the page stays in Notion.
## Page status on the finding
A linked finding shows the page's title and, when the database has a status property, its current status, and opens the page in Notion on click. Minitap reads the status from Notion each time it shows it. If the page is deleted or archived, Minitap drops the link.
## From the CLI
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
# The databases shared with Minitap, with their IDs
minitest --app issues ticket targets notion
# File an issue as a page in a database
minitest --app issues ticket create --provider notion --target
# Find a page by its title or link, then link it by its ID
minitest --app issues ticket search notion "Checkout spinner never stops"
minitest --app issues ticket link --provider notion --ticket
```
See the [CLI reference](/docs/minitest/reference/cli-commands) for the other `issues ticket` commands.
## Next steps
> [card] [Knowledge](/docs/minitest/setup/knowledge)
>
> Everything Mini knows about your app, and where it learned it.
> [card] [Triage issues](/docs/minitest/triage/issues)
>
> Decide which failures deserve a ticket.
> [card] [Linear](/docs/minitest/integrations/linear)
>
> File the same findings as Linear issues.
# What Mini can and can't do
Source: https://www.minitap.ai/docs/minitest/reference/capabilities
What Mini tests today, on which devices and browsers, and what's out of scope.
Will it work for your app? Check where Mini runs, then what it can do on each platform, then the limits.
## Where Mini runs
| App | Devices and browsers | What Mini tests |
| - | - | - |
| **iOS** | Cloud iPhone and iPad simulators, and physical iPhones enabled for your workspace | A build Mini makes from your repository, an `.ipa` you upload, or a TestFlight link on physical iPhones |
| **Android** | Cloud phone and tablet emulators, and physical Android phones enabled for your workspace | A build Mini makes from your repository, or an `.apk` or `.aab` you upload |
| **Web** | Chrome, Firefox and Edge at desktop, tablet and mobile sizes, Safari on iPhone and Chrome on Android | Your staging or preview URL |
Physical phones are switched on per workspace: ask the Minitap team, and see [devices](/docs/minitest/setup/devices). One scenario can drive up to 3 devices at once, for flows like two users in one chat.
## Platform by platform
✅ means Mini does it on that platform today. – means not yet. N/A means it doesn't apply there. The table describes cloud simulators, emulators and browsers. On physical phones, the camera feed, the microphone and API responses aren't available.
| Ability | What Mini does | iOS | Android | Web |
| - | - | - | - | - |
| **Taps, swipes and drags** | Tap, double-tap, long-press, swipe, drag, pinch. | ✅ | ✅ | ✅ |
| **Curved gestures** | Signatures, dials, pattern locks. | ✅ | ✅ | ✅ |
| **Typing** | Type, erase, press enter. | ✅ | ✅ | ✅ |
| **Back and home** | System back and home. | ✅ | ✅ | N/A |
| **Reading the screen** | Screenshots, UI tree, text lookup. | ✅ | ✅ | ✅ |
| **Brief screens** | Loaders, transitions and toasts that vanish fast. | ✅ | ✅ | – |
| **Short-lived targets** | Bonus bubbles, timed rewards and pop-ups that vanish in seconds. | ✅ | ✅ | ✅ |
| **Deep links** | https, universal and custom-scheme links. | ✅ | ✅ | ✅ |
| **Cookies and local storage** | Set feature flags or session state. | N/A | N/A | ✅ |
| **API responses** | Check the screen against what the backend returned. | ✅ | ✅ | ✅ |
| **Backend API** | Call your test API to set up data or check backend state. | ✅ | ✅ | ✅ |
| **Region-locked apps** | Test from another country through a residential proxy. | ✅ | ✅ | ✅ |
| **Internal apps** | Reach your staging and internal hosts through a connector you run. | ✅ | ✅ | ✅ |
| **Browser speaker** | Transcribe what the page says, talk to voice agents. | N/A | N/A | ✅ |
| **Microphone** | Voice commands and dictation. | ✅ | ✅ | ✅ |
| **Camera feed** | An image or video as the camera, for QR and document scans. | ✅ | ✅ | ✅ |
| **Offline mode** | Go offline and back online mid-run. | – | ✅ | ✅ |
| **Rotation** | Portrait and landscape. | ✅ | ✅ | – |
| **Permissions and dark mode** | Grant or revoke permissions, switch light and dark. | ✅ | ✅ | ✅ |
| **Shell commands** | Run any adb shell command mid-run. | – | ✅ | N/A |
| **Push notifications** | Deliver a payload to the app. | ✅ | – | – |
| **Location** | Set a position or move along a route. | ✅ | ✅ | – |
| **Email codes and magic links** | Your workspace's `@qa.minitap.ai` test inboxes. | ✅ | ✅ | ✅ |
| **Sign in with Google** | Minitap-managed accounts, 2-Step Verification included. | ✅ | ✅ | ✅ |
| **Phone sign-in** | With a [static code](/docs/minitest/setup/test-accounts#phone-number-sign-in) you pin in staging. | ✅ | ✅ | ✅ |
| **Several devices at once** | Up to 3 devices live together, for chat, presence and session-conflict scenarios. | ✅ | ✅ | ✅ |
| **Payments and in-app purchases** | Checkout and subscriptions with test money. | ✅ | ✅ | ✅ |
## Beyond the device
> [card] [Signs in for you](/docs/minitest/setup/test-accounts)
>
> Email and password, Sign in with Google, email codes and magic links, and phone sign-in with a static code.
> [card] [Writes your suite](/docs/minitest/suite/mini-maintains-your-suite)
>
> Connect your repository and Mini drafts your scenarios and keeps them current.
> [card] [Builds your app](/docs/minitest/setup/builds-from-repo)
>
> Mini builds each commit, or you [upload your own build](/docs/minitest/setup/upload-a-build).
> [card] [Hands you the fix](/docs/minitest/runs/run-report#fix-prompt)
>
> Every failure comes with the recording and a prompt for your coding agent.
> [card] [Flags what you didn't test](/docs/minitest/triage/suggestions)
>
> UI/UX suggestions point out visual problems and confusing screens.
> [card] [Runs where you work](/docs/minitest/runs/triggering-a-run)
>
> Pull requests, CI, [schedules](/docs/minitest/runs/schedules), the dashboard, [Slack](/docs/minitest/integrations/mini-in-slack) and the [CLI](/docs/minitest/reference/cli-commands).
## Automate it with the CLI
Every command takes `--json` and returns [stable exit codes](/docs/minitest/reference/cli-commands#exit-codes).
| To | Run |
| - | - |
| Authenticate CI | `minitest auth api-key mint`, then set `MINITEST_API_KEY` |
| Build and test a commit | `minitest run from-commit ` |
| Test your own build | `minitest build upload app.ipa`, then `minitest run all --ios-build ` |
| Run the suite every night | `minitest schedules create --name "Nightly" --at 03:00` |
| Answer Mini's questions during a run | `minitest run ask list ` |
| Gate a release | `minitest run verdicts --only-failed` |
| Send failures to a coding agent | `minitest issues list --batch ` |
| Manage the suite as code | `minitest user-story`, `test-profile`, `test-file` |
| Set env vars and Mini's memory | `minitest env set`, `minitest app-knowledge update` |
| Check support per platform | `minitest capabilities --platform ios` |
| Give your coding agent the skill | `minitest skill` |
The [GitHub Action](/docs/minitest/reference/minitest-trigger-action) wraps the same commands and posts a PR check.
## What Mini can't do today
A criterion that needs one of these comes back Unprocessable, shown as **Not tested**. Rewrite it around what the app shows.
* **Push notifications** (Android). Not on Android yet.
* **Backend checks**. No database, server-log or analytics checks.
* **Other inboxes**. Only `@qa.minitap.ai` test inboxes.
* **Real SMS or calls**. Use a static code instead.
* **Biometrics, NFC, Bluetooth** (iOS, Android). No Face ID, fingerprint or pairing.
* **Hearing the app** (iOS, Android). Device sound isn't captured.
* **Network toggling** (iOS). No Wi-Fi or airplane mode.
* **Rotation and location** (Web). Fixed viewport, no location mocking.
* **Wearables**. No watches or paired devices.
* **Real money**. Test and sandbox payments only.
* **Precise timing**. Order and outcome, not latency.
### Backend checks
Mini doesn't read your database, server logs or analytics. Two abilities cover most backend questions:
* **API responses.** On cloud devices and in browsers, Mini reads the API responses your app receives and checks the screen against them.
* **Backend API.** Turn on **Use a backend API** in your app's settings, under **General**, and give Mini your test backend's base URL and OpenAPI URL. Mini then calls your test API to set up data, and to check backend state when a criterion asks for it. Both URLs must be reachable from the internet. From the CLI: `minitest apps backend-api set --enable`.
On iOS, hardware buttons other than home are also out of reach.
## Out of scope
Unit and integration tests, load testing, security testing, and general-purpose automation. Mini tests your app the way your users use it.
Missing something? Ask us. The list moves fast.
> [card] [How Mini tests](/docs/minitest/get-started/how-mini-tests)
>
> What Mini does on the device, and how it decides each verdict.
> [card] [Read a run report](/docs/minitest/runs/run-report)
>
> What to do when a criterion comes back Not tested.
# CLI commands
Source: https://www.minitap.ai/docs/minitest/reference/cli-commands
Every minitest command and flag, grouped by what you're working on.
Every command of the `minitest` CLI, grouped by area, with the flags each one takes. For the install and a quick tour with your coding agent, see [Cursor and Claude](/docs/minitest/integrations/cursor-and-claude).
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
uv tool install minitest-cli
minitest auth login
minitest --json --app scenario list
```
Command names are what you type. A few still carry older words: `test-profile` manages test accounts, `batch` manages runs, and `df` manages suite branches. Each section says what the command means in the dashboard's words. `minitest --help` prints the same flags from your installed version.
## Global
The global flags go **before** the subcommand:
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
minitest [--json] [--app ] [arguments] [flags]
```
| Flag | Short | Description |
| - | - | - |
| `--json` | | Print JSON to stdout, with every diagnostic on stderr. Pass it whenever a script or an agent reads the output. |
| `--app ` | | Target app. Overrides `MINITEST_APP_ID`. Every app-scoped command needs one of the two. |
| `--version` | `-v` | Print the CLI version and exit. |
| `--install-completion`, `--show-completion` | | Shell completion. |
Two groups declare their own flag, which then goes **after** the subcommand: `app-knowledge` takes its own `--app`, and `auth api-key` takes its own `--json`.
### Environment variables
| Variable | What it does |
| - | - |
| `MINITEST_API_KEY` | A workspace API key (`mtk_…`). The usual way to sign the CLI in from CI. See [API keys](/docs/minitest/workspace/api-keys). |
| `MINITEST_APP_ID` | The default app, so you can leave out `--app`. |
| `MINITEST_TOKEN` | A raw bearer token. Legacy; usually unset. It wins over `MINITEST_API_KEY` when both are set, with a warning. |
| `MINITEST_NO_AUTO_UPDATE` | Set to `1` to keep the CLI from updating itself in that environment. CI never auto-updates. |
### Exit codes
| Code | Meaning |
| - | - |
| 0 | Success. |
| 1 | General error, including credentials rejected on a normal command. |
| 2 | Authentication required (`auth` commands). |
| 3 | Network or API error. The only code worth a blind retry. |
| 4 | Not found. |
| 5 | Build rejected as invalid (`build upload`). |
| 6 | Conflict: the resource changed or its state doesn't allow this. Read it again, then retry once. |
## Auth
The CLI signs in from, in order: `MINITEST_TOKEN`, then `MINITEST_API_KEY`, then the session saved by `minitest auth login`.
| Command | What it does |
| - | - |
| `auth login` | Sign in through the browser. The session is saved for this machine. |
| `auth logout` | Remove the saved credentials. |
| `auth status` | Show how you're signed in, as whom, and when the session expires. |
| `auth api-key mint` | Create a workspace API key. The full key is printed once. |
| `auth api-key list` | List the workspace's keys, by name and prefix. |
| `auth api-key revoke` | Revoke a key. Anything using it stops working right away. |
The `api-key` commands need a browser session (or `MINITEST_TOKEN`): a key can't create or revoke keys, and the command exits 2. They take their own `--json`, after the subcommand.
| Flag | On | Description |
| - | - | - |
| `--tenant ` | `mint`, `list`, `revoke` | Required. The workspace ID. |
| `--name ` | `mint` | Required. A label you'll recognize in the list. |
| `--key ` | `revoke` | Required. The key ID, from `list`. |
| `--json` | all three | JSON output. |
Keys don't expire. To rotate one, mint the new key, update your CI secret, then revoke the old one:
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
minitest auth api-key mint --tenant --name ci-runner-v2 --json
minitest auth api-key revoke --tenant --key --json
```
Keys can also be created and revoked in **Settings → API keys**.
## Apps
| Command | What it does |
| - | - |
| `apps list` | List the apps you can see. |
| `apps get ` | Show one app. |
| `apps create` | Create an app. Prints its ID, or the full record with `--json`. |
| `apps dependencies [app_id]` | The scenario dependency graph, as a Mermaid flowchart (raw graph with `--json`). |
### `apps create`
| Flag | Description |
| - | - |
| `--name ` | Required. The app name. |
| `--platform ` | Repeatable. At least one. |
| `--web-url ` | Where a web app is reachable, with `--platform web`. |
| `--tenant ` | Needed only when you belong to several workspaces. |
| `--description `, `--slug `, `--icon ` | Optional. The slug is generated from the name when omitted. |
### `apps dependencies`
| Flag | Description |
| - | - |
| `--simulate` | Try dependency edits without saving them: reports cycles, affected scenarios and the new run order. |
| `--add :`, `--remove :` | Edges to add or remove. Repeatable, with `--simulate`. |
### Network and backend API
These match the options in **App settings → General**. Changing the proxy or the private network needs the owner or admin role. With `set`, options you don't pass stay as they are.
| Command | What it does |
| - | - |
| `apps residential-proxy show` / `set` | **Proxy: test from another country**: devices reach the listed domains from a residential address in the chosen country. |
| `apps private-network show` / `set` | **Private network**: devices reach internal hosts through a connector you run. |
| `apps private-network connectors` | List the workspace connectors the app can use. Connectors are created in **Settings → Private network**. |
| `apps backend-api show` / `set` | **Backend API**: during runs, Mini reads your OpenAPI document and calls your test API. Off by default. |
| Flag | On | Description |
| - | - | - |
| `--enable` / `--disable` | all `set` | Turn the setting on or off. |
| `--country ` | `residential-proxy` | Exit country code, like `tr`. |
| `--domain `, `--remove-domain `, `--clear-domains` | `residential-proxy`, `private-network` | Domains to route. `*.host` covers subdomains. Repeatable. |
| `--connector ` | `private-network` | The connector to route through. |
| `--port ` | `private-network` | Ports devices may reach. Repeatable, replaces the list. Default 443. |
| `--base-url `, `--openapi-url ` | `backend-api` | Required to turn it on. |
| `--secret `, `--remove-secret `, `--clear-secrets` | `backend-api` | App secrets Mini authenticates its calls with. |
| `--skill `, `--clear-skill` | `backend-api` | A skill that explains how to use your backend. |
| `--openapi-auth ` | `backend-api` | How to download a protected OpenAPI document, with `--openapi-auth-secret`, `--openapi-auth-header`, `--openapi-auth-username` or `--openapi-auth-param`. |
## Builds
| Command | What it does |
| - | - |
| `build upload ` | Upload an `.ipa` or `.app.zip` (iOS), or an `.aab`, `.apk` or `.apks` (Android). Prints the build ID. |
| `build list` | List the app's builds. Completed builds only, unless you filter by status. |
| `build get ` | One build: status, version, build number, commit and, for a failed build, what to fix. |
| `build from-commit [sha]` | Build a commit from your repository without running anything. Without a SHA, the latest commit of the default branch. |
| `build signing-certificate` | The SHA-1 and SHA-256 of the key Minitap signs converted `.aab` builds with. Register the SHA-1 for Google sign-in. |
### `build upload`
| Flag | Default | Description |
| - | - | - |
| `--platform ` | from the extension | Needed when the file name has no known extension. |
| `--physical` | off | Check the build for physical devices: an Ad Hoc or Development `.ipa`, or an Android `.apk` for real phones. An `.aab` doesn't need it. |
| `--wait` / `--no-wait` | `--wait` | For an `.aab`, wait until it's converted into APKs. |
Without `--physical`, iOS builds must be simulator builds. A device `.ipa` uploaded without `--physical`, or a simulator build uploaded with it, is rejected with exit code 5 and a hint. See [Upload a build](/docs/minitest/setup/upload-a-build).
### `build list`
| Flag | Default | Description |
| - | - | - |
| `--platform ` | all | Filter. |
| `--status ` | completed | Repeatable. `--status failed` lists failed builds with their guidance. |
| `--kind ` | all | Filter by build kind. |
| `--page `, `--page-size `, `--all` | 1, 20 | Pagination. `--all` fetches every page. |
### `build from-commit`
| Flag | Default | Description |
| - | - | - |
| `--platform `, `-p` | `ios` and `android` | Repeatable. Web apps must pass `--platform web`. |
| `--force-full` | off | Skip the incremental build cache. |
The SHA is the full 40-character one. Needs a linked repository, see [Builds from your repository](/docs/minitest/setup/builds-from-repo).
### `env`
The app's build environment variables, the ones in **Builds & test data → Builds → Build environment variables**.
| Command | What it does |
| - | - |
| `env list [--show]` | List variables. Values are masked unless you pass `--show`. |
| `env get ` | Print one value verbatim. Without `--json`, so you can capture it in a shell variable. |
| `env set ` | Create or update one variable, keeping the others. |
| `env unset ` | Remove one variable, keeping the others. |
| `env clear` | Delete every variable of the app. |
`set`, `unset` and `clear` take `--yes` to confirm and `--dry-run` to show the change without applying it.
## Scenarios
The scenarios of an app, the list on **Test suite → Tests**. The command was `minitest user-story` before; that name still works and prints a warning.
| Command | What it does |
| - | - |
| `scenario list` | List the app's scenarios. |
| `scenario get ` | Show one scenario. |
| `scenario create` | Create a scenario. |
| `scenario update ` | Change part of a scenario. What you don't pass stays as it is. |
| `scenario delete --force` | Delete a scenario. |
| `scenario allow-setup-commit ` | Let Mini complete this scenario's final step (the save, booking or payment) while checking it, so scenarios that depend on it start from what it produced. |
| `scenario revoke-setup-commit ` | Go back to stopping before that final step. |
### `scenario create` and `scenario update`
| Flag | On | Description |
| - | - | - |
| `--name ` | both | Required on create. |
| `--description ` | both | The journey, in plain English. |
| `--criteria ` | both | Acceptance criteria, repeatable. On update, replaces them all. |
| `--add-criteria ` | update | Append criteria, repeatable. |
| `--set-criterion =` | update | Reword one criterion and keep its history. Prefer it over `--criteria` to reword. |
| `--revert-criterion =` | update | Restore a criterion's earlier wording. |
| `--override ::`, `--clear-override :` | update | A criterion's wording for one platform. |
| `--tag `, `--clear-tags` | both | Tags, repeatable. Replaces the scenario's tags; unknown tags are created. |
| `--profile `, `--clear-profiles` | both | Test accounts, repeatable. Replaces the set. On create, omit it to use the app's default account. |
| `--depends-on `, `--remove-dependency ` | both | Scenarios this one runs after. `--depends-on` replaces the whole set. |
| `--device-count ` | both | Devices a run provisions, for multi-device scenarios. Auto is one per test account. Capped at 3 and your workspace's quota. |
| `--camera-media `, `--clear-camera-media` | both | The image or video fed to the webcam in web runs. Video up to 50 MB, image up to 25 MB. |
| `--in-app-purchases` / `--no-in-app-purchases` | both | The journey buys, subscribes or restores. On physical iPhones it then runs on a device signed in to a Sandbox Apple Account. |
| `--idempotency-key ` | create | Retry a create without making a duplicate. |
```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
minitest --json --app scenario create --name "Upgrade to Pro" \
--tag checkout --criteria "The plan badge reads Pro after checkout"
minitest --json --app scenario update --set-criterion 1="The badge reads Pro"
```
`allow-setup-commit` takes `--customer-quote `, required: the words of the person who allowed it, quoted.
### `scenario list`
| Flag | Default | Description |
| - | - | - |
| `--tag ` | all | Scenarios carrying any of these tags. Repeatable. |
| `--page `, `--page-size `, `--all` | 1, 20 | Pagination. |
### `scenario-binding`
Attach test accounts, files and skills to a scenario. Each command replaces the current set. It was `user-story-binding` before, and that name still works.
| Command | What it does |
| - | - |
| `scenario-binding set-profile --profile ` | Set the scenario's test accounts. Repeatable; `--clear` removes them all. |
| `scenario-binding set-files --file ` | Set the test files placed on the device. Repeatable; `--clear` removes them all. |
| `scenario-binding list-files ` | List the files attached. `--page`, `--page-size`. |
| `scenario-binding set-app-skills --skill ` | Set the skills Mini loads before the scenario starts. Repeatable; `--clear` removes them all. |
## Test accounts
### `test-profile`
The app's test accounts, in **Builds & test data → Test accounts**. The CLI still calls them test profiles.
| Command | What it does |
| - | - |
| `test-profile list` | The app's own test accounts. |
| `test-profile list-shared` | The accounts listed under **Shared by Minitap**. |
| `test-profile get ` | One account. |
| `test-profile create` | Create an account. |
| `test-profile update ` | Change part of an account. |
| `test-profile delete --force` | Delete an account. |
| `test-profile set-default ` / `clear-default` | The account new scenarios get when you don't pick one (**Use by default**). |
| Flag | Description |
| - | - |
| `--name ` | Required on create. |
| `--username ` | The address Mini signs in with. Use `@qa.minitap.ai` for an email-code sign-in, see [Test inboxes](/docs/minitest/setup/test-inboxes). Omit it on create to get a generated address. |
| `--password ` or `--password-stdin` | The password. Prefer stdin so it stays out of your shell history. |
| `--phone-number <+E.164>` | A test number whitelisted in your backend, for phone sign-in. |
| `--static-otp-code ` or `--static-otp-code-stdin` | The fixed code your backend accepts for that number. |
| `--about ` | The account's **Note**: who this user is. |
| `--test-card-number`, `--test-card-expiry`, `--test-card-cvc`, `--test-card-holder-name`, `--test-card-postal-code` | A sandbox card for checkout scenarios. |
| `--password-secret `, `--otp-secret `, `--card-secret ` | Point a field to an app secret instead of storing the value on the account. An `--otp-secret` of kind OTP seed makes Mini generate the live code. |
`update` also takes `--clear-username`, `--clear-password`, `--clear-phone-number`, `--clear-static-otp-code`, `--clear-about` and `--clear-test-card`. Pass an empty string to a `--*-secret` flag to stop using that secret. Setup and sign-in types are in [Test accounts and sign-in](/docs/minitest/setup/test-accounts).
## Tags
| Command | What it does |
| - | - |
| `tags list` | Every tag of the workspace, with how many scenarios carry it. |
| `tags create --name ` | Create a tag, or return the existing one with that name. `--color`, `--description`. |
| `tags update ` | Rename a tag, or change its color or description. Address it by name or ID. |
| `tags delete --yes` | Delete a tag and remove it from every scenario. |
Tag names are 1 to 40 characters, without commas. Tags are shared by every app of the workspace. `flow-types` is the older command for scenario types, which tags replaced: it still works and points you to `tags`.
## Runs
In the CLI, a **batch** is what the dashboard calls a run: one or more scenarios started together. A **run ID** from `run start` or `run status` is one scenario's run inside it.
| Command | What it does |
| - | - |
| `run start [scenario...]` | Start a run for one or more scenarios, by name or ID, or for every scenario with `--tag`. One scenario waits for the result; several start one run and return. |
| `run all` | Start a run of every scenario of the app. Returns right away. |
| `run from-commit ` | Build a commit and run the suite on it, then wait for the verdict. |
| `run status ` | One scenario's run. `--watch` polls until it finishes or stops on a question. |
| `run list ` | The past runs of one scenario. `--status`, pagination. |
| `run cancel ` | Cancel a scenario's run. `--platform` or `--target-id` cancels one part of it. |
| `run verdicts ` | The verdict of every scenario and criterion in a run, as JSON. |
| `run feedback ` | Tell Mini about one criterion's result. Doesn't close the issue: `issues not-a-bug` does both. |
| `run recording ` | Download the recording, a timeline of Mini's actions and verdicts, and a frame strip per criterion. |
| `run frames