Turn a manual QA checklist into Monito scenarios

Turn Notion or spreadsheet QA rows into Monito scenarios with expected outcomes, environments and deploy checks. Keep human review and email limits explicit.

Write numbered steps followed by expected results the browser can observe, such as visible text, a URL, a value or state that survives a reload. Source · checked 2026-10-23.

Start with the Notion page or spreadsheet you open before a release. Read each row as an instruction to a person who has never tested the feature. Fill in the starting page, account, test data and expected result that you currently supply from memory. A row that says only checkout works is not ready to automate. Describe what the review screen must show and where the run must stop.

Split mixed rows before moving them. For example, Sign up with a new email, confirm the welcome email arrives contains a browser journey and an inbox check. Keep welcome-email delivery as a separate manual or email-tool check. A successful signup screen does not prove delivery. An inbox step later in the journey needs another tool. Our team uses illustrative checklist rows below; the benchmark runs show comparable behavior, not completion of your release checklist.

What the source documentation says

Write numbered steps followed by expected results the browser can observe, such as visible text, a URL, a value or state that survives a reload. Source · checked 2026-10-23.

What translates and what changes

Manual QA checklist concepts mapped to Monito
	Manual QA checklist	Monito
Row title and feature	Use a row title such as Profile name persists, with its feature or release section beside it.	Turn each selected user journey into a named scenario. Keep its starting path, actions and expected outcome together. Group the scenarios you intend to run together in a suite. Keep the original row and link to its scenario so a reviewer can find the requirement.
Steps column	Write the clicks and inputs you currently carry out from memory. Replace vague entries such as test checkout with a bounded journey.	Name the scenario and put the actions in What to test. Add the expected result to that same text.
Expected result column	State the visible result that lets you mark the row passed, including values that must persist after reload.	Put each required outcome in What to test. Preserve arithmetic and reload checks. Reaching a page or seeing a toast does not prove the saved state. Keep subjective acceptance criteria on the manual checklist. Looks good needs a human decision; a saved value surviving reload is an observable outcome.
URL and environment columns	Record whether the row applies to staging, production or the release preview, along with the page where it begins.	Create the environment with your app's base URL and set the scenario's starting path. Use --base-url on project run for a deployed preview. A preview URL does not authorize sending saved logins to a new origin; use an approved origin for an authenticated journey.
Account and prerequisites columns	Identify the disposable account, empty cart or initial profile value the person testing the row needs. Keep passwords out of the checklist.	Store email, password and any TOTP setup key in an environment login. Protected-preview request headers are also stored on the environment. These settings do not implement general prompt-variable substitution. Save the authenticator setup key in the login's Advanced settings. Monito generates TOTP when signing in. HOTP is not supported.
When to check column	Separate before-release checks from recurring checks. Record the cadence that meets the requirement instead of assuming every row needs a timer.	Monito offers a single us-east region and an hourly minimum schedule. Schedule presets are hourly, every 6 hours, daily and weekly, in UTC. Use a deploy trigger for release coverage and a schedule for checks between deployments. Select the environment and suite deliberately for each trigger.
Release trigger	Replace the reminder to click through migrated rows after deployment with a run of their suite.	A deploy webhook queues runs after deployment. For a blocking GitHub check, use the documented CLI project run workflow. Both integrations require Pro or Team.
Owner and failure destination	Keep a person responsible for interpreting a failed or blocked row and deciding whether the release can proceed.	Failed automated runs can email you when run-alert emails are enabled. Email is available on Free, Pro and Team; Slack notifications require Team. Failure emails go to your account's email address; turn them on or off under Settings, Run alerts. Connect Slack channels on Team.
Result and evidence columns	Keep the tested build, environment and report link beside the row. A previous release's tick does not establish the current result.	Read the run report's measured checks, screenshots, network and console evidence. Recording is off for signed-in runs; masked screenshots are captured instead. Keep old traces, videos and screenshots separately; a new scenario starts its own run history.
Shared test data	A person may have completed rows in order using the same account. Record any dependency before running them together.	Suite members launch side by side, with up to 5 launches in progress at once. This limits launch work, not the number of already running browsers. You do not configure CI shards. Give each journey independent test data so concurrent runs cannot overwrite the same cart or profile.
Device and location columns	Keep physical-device checks and location requirements visible in the checklist so they cannot be mistaken for migrated browser coverage.	Runs execute in us-east. You cannot select multiple regions. An environment selects the target app and login, not the runner's region. Monito has no private-location worker.

Set up the scenario and its login

Create a project and an environment with your app's base URL. Give the scenario a Name and a Where value, either a starting path or a full URL. In What to test, put the instructions and expected outcome together. The examples separate those two parts for review; they are not an import file or separate required form fields. Select the environment you intend to run against. Replace the illustrative paths, account names and fixture data with values your application actually has.

Add the email and password as an environment login, then select its role in the scenario. For authenticator login, open Advanced and save the setup key; Monito generates the TOTP code during sign-in. Login secrets stay encrypted in server storage. Protected-preview request headers also belong on the environment, with encrypted values tied to its origin. These settings do not implement general prompt-variable substitution. A disposable email login needs your own Resend receiving domain, API key, expected sender and subject prefix. It reads a code or magic link for a new disposable address, not an existing fixed-email account.

Writing a scenario

Three converted browser journeys

These examples show how to rewrite intent. Each report link is a run of a comparable journey from our benchmark. It is not a run of your check or a validation of these illustrative configurations.

Turn an account-access row into a login scenario

Before · text

Row | Steps | Expected result | Environment / path | Prerequisites | When
Account dashboard access | Sign in and open the account dashboard | Account menu and Recent activity are visible; no sign-in error | Staging /login | Disposable QA account with password login | Before release

Illustrative checklist row written as a pipe-separated table, not an import file. The linked guide explains how to write observable outcomes. The example account has no authenticator challenge. Source · checked 2026-10-23.

After · Monito scenario

Name: Account dashboard access
Starting path: /login
Environment: Staging

Instructions: Sign in with the saved QA login and open the account dashboard.

Expected: The account menu and recent activity are visible. A sign-in error or unresolved login challenge does not pass.

The row title becomes the scenario name, Staging selects the environment and /login becomes Where. Put the Steps and Expected result text together in What to test. Save the account as an environment login. When the sign-in challenge itself is under test, select Start logged out under Options, or leave Reuse login sessions off on the login. Session reuse is off by default. Keep the before-release requirement for the deployment trigger; do not mark the row covered until you have reviewed a run against your own app.

The run ended with an Error status, which our benchmark scores as cannot verify: the security check failed and no credentials were supplied. It illustrates an unresolved login prerequisite, not a successful sign-in or proof that your authentication will work.

A run of a comparable journey from our benchmark

Make a checkout row precise enough to verify

Before · text

Row | Steps | Expected result | Environment / path | Prerequisites | When
Checkout review | Add Test mug, open Checkout, choose the saved staging address, open Review order; do not place the order | Item and shipping are visible; total equals their sum | Staging /catalog | Checkout account with an empty cart and saved staging shipping address | Before release

Illustrative checklist row. Replace the product and saved address with your own staging fixtures. The source describes writing observable outcomes, not a spreadsheet importer. Source · checked 2026-10-23.

After · Monito scenario

Name: Checkout review includes delivery
Starting path: /catalog
Environment: Staging

Instructions: Use the checkout account's saved login, start with an empty cart, add the test mug and choose its saved staging shipping address. Open checkout review without submitting the order.

Expected: The review contains the item and shipping charge, and the displayed total equals their sum.

Write down the arithmetic you used to check in your head. Reaching the review screen is not enough to pass this row. Preserve the instruction to stop before ordering, and prepare the saved address before running. Reset the cart between validation runs and use a separate account from other journeys. Keep any payment approval or physical fulfillment check on the manual list with its own owner and evidence.

The benchmark includes a working checkout and a cart whose total omits shipping. These reports exercise checkout behavior and arithmetic. They do not execute the illustrative example above.

Keep the reload in a profile checklist row

Before · text

Row | Steps | Expected result | Environment / path | Prerequisites | When
Profile name | Change Display name to Migration sample, save, inspect the member list and reload | Success notice appears; list updates; name remains after reload | Staging /settings/profile | Disposable profile account starting with a different display name | Before release and daily

Illustrative checklist row. Reset the profile value before each run so saving changes something. Before release and daily are requirements for this example, not a claim about every team's checklist. Source · checked 2026-10-23.

After · Monito scenario

Name: Display name survives reload
Starting path: /settings/profile
Environment: Staging

Instructions: Use the disposable profile account's saved login, starting with a different display name. Change it to Migration sample, save, inspect the member list and reload.

Expected: The success notice appears, the member list updates and Migration sample remains the display name after reload.

Keep the reload you used to perform by hand. A success notice can appear even when the application loses the change. Turn the daily requirement into a Daily schedule with a UTC hour and the intended environment and suite. Keep the release trigger too if both checks are required. Assign the account reset to your test setup; a saved login does not restore the initial display name.

The benchmark profile saves show both a persistent update and an update lost after reload. The latter still shows a success toast. Read the reload evidence before treating the visible confirmation as success.

Ask your coding agent to recreate the checks

You can ask your coding agent to recreate the checks through the hosted MCP server. Give it the public target URL, environment and non-secret intent. The check tool runs a URL and expectation. After reviewing the result, save_check saves that check under a name without starting another run. Use run_scenario for the saved scenario afterward. A check or run_scenario call spends credits. These tools do not import the source vendor's project.

Connect the hosted MCP server and provide the journey you reviewed above.

Agent prompt

Recreate this browser journey in Monito using the hosted MCP server. Use the intended project's environment and saved login. Call check with the public URL and the instructions plus expected outcome. Read the report and identify any missing prerequisites. If the scenario is correct, call save_check with its checkId and name. Use run_scenario with the saved scenarioId for subsequent runs. Keep credentials out of the expectation.

Cut over the trigger and schedule

Review the checklist with the person who usually runs it. Expand shorthand into actions, expected results and prerequisites. Mark each row as a candidate browser scenario or a retained manual check. Split mixed rows such as signup plus welcome-email delivery, and retain an owner for the part that remains manual.
Create the project, environment and saved logins in Monito, then a suite for the moved rows. Enter each scenario through the form using the columns above. This is a row-by-row conversion, not a Notion or spreadsheet import. Link the scenario back from its original row and keep the expected outcome visible to the release reviewer.
Run each scenario against the build you would test manually. Compare its report with your own observations. Investigate a failure or cannot-verify result rather than checking the row off. Confirm that a known broken outcome is detected. Do not remove the manual repetition until the replacement reaches the same observable outcome with the right account and data.
For release coverage, add the blocking project run step below, after successful deployment. Use the generated GitHub Actions authentication setup under Automations. Set PROJECT_ID to the destination project. Set SUITE_NAME to the suite containing the migrated journeys. Keep the manual release review for retained rows; a green browser suite does not approve exploratory or physical-device checks.
For rows that also need recurring coverage, create a schedule in Automations and select the intended environment and suite. Choose Daily with a UTC hour for the profile example. Check notification preferences and who responds to a failed run. Record the new trigger beside the checklist row so the next release reviewer knows where to find its result.

For asynchronous checks, the deploy webhook returns 202 when runs are queued. That response does not mean they passed. Results appear in the dashboard; this request does not block the pipeline for a verdict. Deploy webhooks require Pro or Team.

For a blocking pipeline, configure GitHub Actions under Automations and use its generated authentication setup before adding this run step. Set GITHUB_TOKEN and grant checks: write. PROJECT_ID identifies the Monito project; PREVIEW_URL is the deployed target. The CLI waits for results and exits with code 1 if a scenario fails or errors. --github-check publishes the Monito GitHub check; the check is neutral when every test that didn't pass errored for a reason Monito caused, or when the CLI stops before it collects every result; other errors and failures mark it failed. The CLI exits 1 either way. The example pins the published CLI 4.8.1. A preview URL does not authorize sending saved logins to a new origin; use an approved origin for an authenticated journey.

Blocking GitHub check · shell

npx -y @monitodev/cli@4.8.1 project run "$PROJECT_ID" \
  --base-url "$PREVIEW_URL" --wait --github-check --suite "$SUITE_NAME"

Follow the GitHub Actions setup for authentication and permissions. The project run reference documents the command. GitHub Actions requires Pro or Team.

Without --suite, the command runs every scenario in the project, or the suite selected on the GitHub Actions automation. Pass --suite <name> or select a suite on the automation to limit it to the migrated journeys. Do not also fire a deploy webhook for the same deployment unless you intend duplicate runs. An asynchronous webhook is an alternative when the pipeline does not need to wait for a verdict.

Keep the manual checklist as the release record. Link each migrated row to the report for the build and environment under review. Leave unsupported and unverified checks visible with an owner. A passed scenario covers its own expected outcome, not every requirement that used to share a row with it.

Schedule allowance, regions and alerts

Schedule presets are hourly, every 6 hours, daily and weekly, in UTC. Runs execute in us-east; there is no region selector or multi-region execution. Failed automated runs can send email when run-alert emails are enabled. Email is available on Free, Pro and Team. Slack notifications require Team. Check the chosen environment, suite and notification preferences before relying on the schedule.

50 free test credits every month. Your balance refills to 50 on the 1st of each month (UTC), counting credits reserved by running tests. Unused credits are not added again; purchased credits are kept. Your signup credits count as the first month. Free includes one daily schedule. Verify your email to receive monthly refills. Any schedule other than that one daily schedule, a deploy webhook, GitHub Actions, and a public status page need Pro.

Check pricing before enabling the recurring workload. A slower schedule leaves a longer gap between checks; it changes the coverage you are buying.

When keeping a check manual fits better

Keep exploratory testing and visual design review manual. A person needs to investigate behavior that was not specified in advance and judge whether the design meets the intended experience. Keep checks that need a physical device or a human judgment call manual too. Record who performs them and what evidence the release reviewer needs; do not remove them because the browser scenarios pass.

Keep welcome-email delivery and inbox content checks manual or in a dedicated email tool. A disposable email login needs your own Resend receiving domain, API key, expected sender and subject prefix. It reads a code or magic link for a new disposable address, not an existing fixed-email account. An inbox step later in the journey needs another tool. That login capability does not verify that a welcome email arrived.

Keep a row manual while its outcome is ambiguous or Monito cannot verify it. Replace looks good with a measurable browser result only when that result expresses the actual requirement. Do not reduce a human judgment to a convenient text match. Resolve missing account access and test data before treating the browser part as covered. A blocked challenge leaves this journey unverified; it does not establish that the dashboard works.

What to keep outside this migration

Automate repeatable browser journeys with observable outcomes. Keep exploratory testing, visual design review, physical-device checks and human judgment calls manual.

Monito runs desktop Chromium. It does not run component tests, provide multiple browser engines or export executable test code. Keep other platform coverage and any checks Monito cannot verify in the existing release process.

Keep email delivery separate from signup success. Keep the manual owner and expected result for each unsupported check, and do not mark the whole checklist passed because its migrated scenarios passed.

Validate your first scenario

Run the scenario against your own app and inspect the result before switching its trigger. Our team publishes the benchmark method and its limits on the reliability page. The reports above show comparable behavior; your application still needs its own validation.

Create a scenario All switching playbooks