Skip to main content
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 or ask in your Slack channel with the team.

​
Evaluating Minitap

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.
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.
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 and Web apps.
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.
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 walks through the setup in the order the dashboard shows it.

​
Setting up

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 and Upload a build.
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.
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 and Test inboxes.
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.
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.
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.

​
Runs and results

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?
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 and Pull request checks.
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.
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.
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.
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.
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?

​
Security and data

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.
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.
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.
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. Bring your questionnaire to a call and we sign the DPA with your contract. See Request a security review.

​
Pricing

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.
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 says what counts as usage. To invite your team, see Members and roles.
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 and we send your invitation after a short walkthrough.

​
Next steps

Quickstart for mobile

Connect your iOS or Android app and watch Mini run your first regression.

What Mini can and can't do

Every ability, platform by platform, and the limits.

Security and data

Where Minitap runs, what it stores, and what the models see.

Troubleshooting runs

Long runs, Mini’s questions, the wrong build and false failures.