Mo

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.

​

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_URL variable 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: 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.

​

Not available yet

• Pulling your repository and running the application itself, so Mo does its own setup and teardown in the codebase.
• Delivery by Slack or email.
• Sharing a report by public URL.

​

Next