01
Point
Provide a URL or uploaded mobile build. Describe expected behavior, test accounts, data rules, scope, and actions to avoid. Mo asks for missing context in the session chat.
platform
/ mo
Mo, the AI QA engineer.
Mo tests your app from a prompt. Review what passed, what broke, and what was blocked before you ship.
Use a web URL, or tunnel your local or private app. Mobile sessions use an uploaded iOS or Android build and require mobile access.
Bug bashing for web and mobile apps.
117,010 bugs caught before deploy
Agents
Mo runs independent test cases in parallel.
Findings
Review bugs, reproduction steps, and evidence.
Prompts
Tell Mo what to test and what should happen.
Platforms
Test a web URL or an uploaded Android or iOS build.
From a prompt to verified behavior.
Describe the flows that should work. Mo explores the app and checks the outcomes.
02
Bash
Mo plans test cases and runs them in parallel, up to your plan limit. A separate agent reproduces functional bugs before they're reported. Blocked cases remain visible.
03
Report
Findings appear in the app while the session runs. Review case verdicts, expected and actual behavior, reproduction steps, and evidence. Export the report for your coding agent to investigate a fix.
Verify the build against your prompt.
Start in the app or with the CLI. Give Mo the target, expected behavior, and actions to avoid, then review what it verified and what was blocked.
npm install -g qa
qa login
qa start "Test the cart at https://staging.example.com/cart.
Check quantity changes, totals, and persistence after refresh.
Do not place orders or submit payments."
# Use the session ID returned by qa start.
qa status <session-id>
qa read <session-id>
qa report <session-id> --require-idle --output ./mo-reportMake the target reachable
Use a staging or preview URL and provide sign-in instructions. Tunnel a local or private app, and allow Mo through deployment protection. Mobile sessions need access and an uploaded build.
Define the expected behavior
Name the flow, the outcome to check, test data, and prohibited actions. Mo asks for missing access or context in the session chat.
Review tested and blocked cases
The report records case verdicts and bug evidence. Blocked cases haven't been verified. A separate agent tries to reproduce functional bugs. Recordings are included when available.
Fix, then recheck
Accept a bug or mark it as working as intended. Review suggested Knowledge base entries. After deploying a fix, ask Mo to rerun the reproduction and export the updated report.
Know what works before you ship.
Review tested flows, reproduced bugs, and blocked cases. After a fix is deployed, ask Mo to recheck it.
Bug bash on demand
Give Mo the areas and expected behavior to check. Agents execute cases concurrently and file findings with reproduction steps and available recordings.
Check the build when it's ready.
Make dogfooding count
Run Mo before your team uses the build. Review failed and blocked cases, then spend the human session on product judgment.
Give your team findings to work from.
Exploratory testing
Mo chooses flows from your prompt and the running app. A separate agent reproduces functional bugs before they're filed.
Test beyond the cases you've already written.
Another check before release
Start a session against the build you want to release. Findings appear while it runs; human testers still cover physical hardware and local product requirements.
Review findings as they're filed.
Keep checking the behavior
Schedule another Mo pass or provide merged diffs to focus exploration. Your coding agent can turn covered flows into repository tests for CI.
Schedule another pass or keep a repository test.
Coverage across your targets
Start one session per target. Web sessions use hosted browsers; iOS uses simulators and Android uses emulators. Review tested and blocked cases for each target.
Review coverage for each requested target.
Trusted by teams that ship every day.
A Fortune 1000 file-collaboration platform · 700M+ registered users
“We pointed it at staging before a release and it found 27 bugs in an afternoon . Nobody wrote a test. The engineers just got the report.”
Senior Engineering Manager File-collaboration platform
27
bugs from one bug bash
116
agents exploring at once
2 days
of manual QA automated in a single run
Mo covers web, iOS, and Android.
One prompt per target. Hosted browsers, simulators, or emulators.
01
Web
Point Mo at any URL our hosted browsers can reach, or a local build through a tunnel. It bug bashes the live app.
02
iOS
Point Mo at an uploaded iOS build. The bash runs on a Momentic-hosted simulator.
03
Android
Point Mo at an uploaded Android build. The bash runs on a Momentic-hosted emulator.
Mo, answered.
How much of my product does Mo actually cover?
You choose the scope. The report shows tested flows, findings, and any blocked or unverified cases.
Do I ever have to write or maintain tests?
No. There is no test suite. You give Mo an objective and read the report.
We already point a coding agent at Playwright. Why Mo?
Mo plans test cases from your running app and prompt without maintaining a saved test suite. Agents run the cases in parallel, up to your plan limit. A separate agent reproduces functional bugs before they're reported.
We have coding agents but no QA team. Is Mo for us?
Yes. Give Mo a build or preview and the behavior to check. Your team reviews its cases, findings, and coverage gaps. Your coding agent can investigate a fix from an exported report.
What does Mo need to reach my staging environment?
A reachable URL or uploaded mobile build, sign-in instructions, and a test account. A tunnel or Connector gives Mo access to a private app. Pass credentials through environment variables. Session data and evidence are stored in the Mo app; see security and data use.
How do I start a run?
In the app composer, with the CLI, or on a cron schedule. The Momentic GitHub App gives Mo read-only repository and pull request context. Include the pull request, preview URL, and expected behavior in your prompt.
Is it safe to run Mo on production?
Yes, with boundaries in the prompt. You name the actions Mo must not take (submit a payment, delete an order, touch admin surfaces) and the data it must not modify. Most teams still point it at staging first.
How does Mo decide what counts as a bug?
A separate agent reproduces suspected functional bugs before they enter the report. Findings include expected and actual behavior, reproduction steps, and recordings when available. Static findings, such as typos, can use a screenshot instead. The report also shows blocked coverage.
Can Mo replace our bug bash?
Mo executes cases from your prompt and files findings with reproduction steps and available recordings. Review blocked coverage. Keep people for product judgment and exploratory feedback.
Can Mo do exploratory testing?
Yes, and that is the default. You give Mo an objective instead of a script, and Mo decides which flows to try.
We dogfood before every release. Where does Mo fit?
Run Mo on the build first, then dogfood. Your team reads a report instead of walking the same flows, and it spends the session on what Mo could not judge.
Does Mo replace our outsourced QA team?
It replaces the repeat passes, not the people. Mo runs the same flows on demand and reports the same day. Human testers still cover local payment methods and real hardware.
Can we keep the flows Mo tested as a suite?
Yes, as Momentic tests. A flow Mo covered becomes plain-English steps in a YAML file in your repo. Your coding agent writes that file over our MCP server, and the CLI runs it in CI.
How many agents does Mo run at once?
A hundred or more on a single bug bash, up to your plan limit. Each agent gets its own hosted browser for web, or a simulator or emulator for a mobile build.
How is Mo different from Codex or Devin driving a browser?
Mo starts from a running app and your prompt. Agents plan and run test cases, and a separate agent reproduces functional bugs. Agents run in parallel on hosted browsers, simulators, or emulators, up to your plan limit. Your coding agent can read the report to investigate a fix.
How do you keep false positives out of the report?
A separate agent starts from a clean browser or device session, follows the authentication and setup instructions, and uses equivalent test data. A functional bug it cannot reproduce is not filed as confirmed. Static findings use screenshots without a separate reproduction run.
Does Mo learn how our product works?
Yes. Agents look up relevant Knowledge base entries on each AI-assisted step. Mark a finding as working as intended and give the reason. Mo drafts a linked entry; review and accept it to make that guidance available to later sessions.
Do we have to choose between Mo and our coding agents?
No. The CLI exports findings, reproduction steps, and evidence as files your coding agent can read. It can investigate a fix, then ask Mo to recheck the deployed change and export the updated report.
Do the bugs go to Jira or Linear?
They can. The report lives in the Momentic app; its test cases sync to TestRail, Qase, or Testiny, and an accepted bug files to Jira or Linear.
We already have a Playwright suite. Why do we need Mo?
Mo needs no test script. You give it an objective or a spec, it explores the running app, writes the cases itself and runs them across many browsers at the same time. Your suite covers the cases someone already wrote, so Mo is how you find the bugs that have no case yet.
Still have additional questions?
Contact us