Skip to main content
Use Mo to explore a running app from a brief and review findings with evidence. Use repository tests for checks you want to repeat in CI, and your coding agent to implement changes and investigate the code behind a failure.

​
Choose a testing approach

You can combine these approaches. After Mo finds a bug, give the report to your coding agent, deploy the fix to the tested target, and ask Mo to recheck it. Add a repository test for behavior that needs ongoing regression coverage.

​
Define the coverage

A Mo brief names the target, expected behavior, accounts, test data, and prohibited actions. Mo plans cases from that context and any specs you supply. Read the case list and coverage gaps to see what it checked. Message Mo when a required flow is missing. For a change-specific session, name the branch or revision and product area in the brief. Workspace repositories provide read-only code context. You still provide a running app; Mo does not start it from the repository checkout.

​
Session execution

Mo runs on Momentic’s infrastructure. The session agent plans coverage and dispatches explore agents, bug bash agents, and bug reproducer agents. Each sub-agent has its own browser, simulator, or emulator. The session’s maximum concurrency is bounded by your plan. Each session tests one target: a web URL, an uploaded iOS simulator build, or an uploaded Android build. For a local web app, keep the app running and open a tunnel. See session settings for target and concurrency controls.

​
Independent bug reproduction

A suspected functional bug goes to a separate reproducer agent. It follows the flow from the beginning in a separate browser or device session, using the required authentication setup and fresh equivalent test data. Mo adds the bug as a confirmed functional finding only if the reproducer confirms it. Static findings, such as a typo, use a screenshot without a separate reproduction run. Blocked checks record access, test-data, or environment problems in a verdict or case blocker. Check the finding type and evidence before deciding what to fix. See report fields.

​
Reviewable results

Every session uses the same report fields. Cases include preconditions, an outline, and acceptance criteria. Verdicts distinguish verified behavior, issues found, and blocked checks. Findings include expected and actual behavior, reproduction steps, and recording or screenshot metadata when available. Export the report when Mo and its sub-agents are idle:
The export includes report.json, finding files, and available bug recordings. Use it to hand the findings to a coding agent or compare a recheck with the original report. The schema stays consistent; an exploratory session can choose different cases on a later run. Use repository tests when you need an explicit sequence of checks on each run. Connect GitHub to give Mo read-only context for a pull request or repository. See Mo integrations for setup and access requirements.

​
Product context

Mo retrieves terminology and rules from your Knowledge base. When you mark a finding as Works as intended, you can review and save a suggested knowledge entry that explains why. Later sessions can retrieve that entry when they test the relevant behavior. See triage.

​
Start Mo from a coding agent

Install the qa CLI and the mo-qa skill to let your coding agent start and follow a session. The skill asks for missing brief details and uses the CLI to read output, answer questions, and export findings. Once installed, give it a target and scope:
See the CLI walkthrough for authentication, local tunnels, and session states.

​
The fix loop

  1. Export the idle report into a baseline directory. Review the findings and human triage decisions before selecting bugs to fix.
  2. Give your coding agent the expected behavior, actual behavior, reproduction steps, and available evidence. It investigates the code and implements the fix.
  3. Deploy the fix to the target Mo can reach, or serve the updated branch through the local tunnel. Tell Mo which bug and revision to recheck with qa send --session-id <session-id> "<message>".
  4. Export the idle report into a new directory. Check the new reproduction result and any coverage gaps before treating the fix as verified.
For behavior you need to check on later releases, ask your coding agent to turn the case into a Momentic test. Review the YAML, run the test, and add it to your CI suite. See fix and recheck and add regression coverage.

​
Next

Write a brief

Define expected behavior, test accounts, and actions to avoid.

Run your first session

Start Mo, review coverage, and triage the findings.