Mo - Momentic
Documentation Index
Fetch the complete documentation index at: /docs/llms.txt
Use this file to discover all available pages before exploring further.
Mo tests a running application. You give it a target and a brief, and it plans the test cases, works through them, and reports findings with evidence. To check one flow now, run your first Mo session. You need Mo access and a reachable app, with a test account if the flow requires sign-in. Use Mo for exploratory testing on a preview deployment, a release candidate, or a product area without existing tests. You provide the running target, expected behavior, test accounts, and actions to avoid in the brief. The report shows what Mo checked and what it could not verify. For repeatable regression checks, keep Momentic tests in your repository and run them in CI.
Mo tests the running application through its interface. Repositories you add to the workspace provide read-only context. Mo does not start your app from that checkout or write Momentic test files.
Targets
A session tests one of these:
- A web app at a URL, in a hosted browser. The URL can be a production site, a preview deployment, or a local build through a tunnel.
- An iOS app, on a remote simulator.
- An Android app, on a remote emulator.
Mobile sessions require Mo mobile access in your workspace. For iOS and Android, Mo installs a build you uploaded to a channel and a tag, the same build a Momentic mobile test uses. See iOS app setup and Android emulators.
What a session produces
A session keeps one report. It holds:
- Test cases, each with preconditions, an outline, and acceptance criteria.
- Verdicts for checked cases: verified, issues found, or blocked. Cases can also record a blocker before verification starts. Review both verdicts and coverage gaps.
- Findings with expected behavior, actual behavior, and reproduction steps. Functional bugs require independent reproduction. Static findings, such as a typo, use a screenshot.
See session reports for the fields, and triage for the decisions you make on a bug.
Context the session reads
Beyond the brief, a session can start with three more sources:
- Workspace repositories you select on the Mo workspace page provide code and diffs through read-only Git access. Mo refreshes default branches at session startup when possible; a cached checkout may be stale if the refresh fails. Name the branch or revision in a brief that depends on a specific change.
- A named Momentic environment provides variables to the session, and its
BASE_URLvariable sets the starting URL. - An uploaded spec or test plan becomes the source the cases derive from.
See run a session for the settings and diff-based regression for the pass over a diff window.
The agents in a session
A session has a session agent and its sub-agents. Each role has one job:
| Role | Job |
|---|---|
| Session agent | Plans the coverage, dispatches sub-agents, reads their reports, removes duplicate cases and bugs, and answers you. |
| Explore agent | Maps an area of the product and records test cases. It reports a suspected bug, but never confirms one. |
| Bug bash agent | Takes one test case, works through the flow in its own browser, and submits a verdict. |
| Bug reproducer agent | Takes one suspected bug and tries to reproduce it from a clean start. |
For a suspected functional bug, a reproducer agent walks the flow from the beginning in a separate browser or device session. It uses the authentication and setup instructions for the case and equivalent test data. If it cannot reproduce the behavior, Mo does not add it as a confirmed functional bug. Static findings use a screenshot without a separate reproduction run.
Parallel agents
Every sub-agent gets its own browser, simulator, or emulator, so agents check cases at the same time. Set the maximum number of concurrent sub-agents in the session settings, up to your plan limit. See session settings. Separate browsers and devices can still share accounts and backend data. Provide disposable test data or isolation rules in the brief.
Limits
A web session runs in a hosted browser. Flows that require operating-system dialogs or another desktop app, such as a print dialog or a mailto: link, can block verification. Review the coverage gaps in the report before treating a session as complete. One session tests one target. To cover web, iOS, and Android, start a session for each.
Next
Quickstart \ \ Start your first session, read the report, and triage what it found.
When to use Mo \ \ Choose between a Mo session, repository tests, and a coding agent check.
Write a good brief \ \ Define the target, scope, accounts, test data, and prohibited actions.
Run a session \ \ Sign-in, test data, schedules, and session timing.
Use the Mo CLI \ \ Start and follow sessions from a terminal or a coding agent.
qa CLI reference \ \ Every command, option, and output shape.