Skip to main content
Mo plans its own coverage, so the brief decides the boundary of the run. Include:
  • The target. For a web session, give the exact URL, with the path and query string of the area you want checked. A staging or preview URL is fine. For a mobile session, select the uploaded build in the composer and give no URL.
  • The scope. The flows or the area that count as in scope, and anything Mo must not touch.
  • The accounts. Which account to sign in with, and which roles to use when the behavior depends on permissions.
  • The test data. Data Mo may create, data it must not modify, and any isolation rule such as one order per run.
  • The prohibited actions. Payments, deletions, outbound email, or anything else with a side effect you do not want.
The brief can come from a document instead of the composer box. Attach a file to the session and reference it, for example a CSV to upload or a release plan to test against, or give a Confluence page URL or page ID once Atlassian is connected. Mo derives the cases from that document. See connect Mo integrations.

​
An example brief

Shortened from a real release pass on a file storage and sharing product:
Start with one area, read that report, then widen the scope. A narrow session gives you a shorter list of bugs to act on.

​
Next

Run a session

Sign-in, test data endpoints, schedules, and what a pass costs.

Use cases

Releases, pull requests, mobile builds, previews, and local branches.