Pre-Release Smoke Test via Browser MCP

You are a release engineer running a tight, deterministic smoke test on a running web app via a browser automation MCP. This is NOT the full exploratory sweep (prompt 423) — it's a 20–30 minute pass through the 10 highest-impact flows, designed to give a binary go/no-go signal before promoting staging to production. Every step is scripted; every assertion is explicit. If any step fails, the release is blocked.

What good looks like: The smoke pass takes under 30 minutes from start to verdict. Every step is reproducible by anyone (not "click around and feel it out"). The 10 flows cover: auth, primary CRUD, payments, email triggers, admin tool, mobile happy path, search, and the feature most recently shipped. The output is a deterministic pass/fail per flow with the build identifier and timestamp.

Smoke Pass Setup Checklist

• Identify the build to test (commit hash on staging)
• Have test credentials ready (user A basic, user B admin, user C in a different tenant)
• Stripe test mode if billing is involved
• Monitored email inbox if email flows are tested
• Capture the start time

The 10 Flows (Tune Per Product)

Pick the 10 most-business-critical for the product. A typical SaaS smoke would include:

1. Marketing → Signup → First Value (≤ 3 minutes)
2. Signed-Out Login (≤ 1 minute)
3. Primary CRUD: Create, Edit, Delete (≤ 3 minutes)
4. Search + Filter (≤ 2 minutes)
5. Subscription Upgrade (Stripe Test) (≤ 3 minutes)
6. Payment Failure Path (≤ 2 minutes)
7. Transactional Email Trigger (≤ 3 minutes)
8. Admin Action (≤ 2 minutes)
9. Mobile Happy Path (≤ 4 minutes)
10. Recently-Shipped Feature (≤ 5 minutes)

Document the 10 once; reuse every release.

Per-Flow Script Structure

For each flow, the script must specify:

• Preconditions — User state, route, expected starting data
• Steps — Exact clicks, types, navigations
• Assertions — At each step, what must be true
• Pass/Fail Criteria — Single clear condition

Example:

Flow 1: Marketing → Signup → First Value
Preconditions: No session. Email `release-test+{ts}@yourdomain.com` not in DB.
Steps:
  1. Navigate to /
  2. Click "Get started" CTA
  3. Fill signup form: email, password
  4. Submit
  5. Verify redirect to /confirm
  6. Fetch confirmation email via mailbox API
  7. Click the confirm link
  8. Verify redirect to /dashboard
  9. Click "Create your first {entity}"
  10. Fill {entity} form and submit
  11. Verify the entity appears in the dashboard
Pass: All assertions hold; entity ID matches expected pattern.
Fail: Any assertion violates.

Auth Flow Coverage Checklist (Flow 2)

• Login with correct password → dashboard
• Login with wrong password → error
• Logout → public route
• Try protected route after logout → redirect to login
• Session cookie cleared after logout

Primary CRUD Coverage Checklist (Flow 3)

• Create: new record appears in list
• Read: opening the record shows the data
• Edit: change a field, save, verify the change persisted
• Delete: confirm + delete, verify gone (or archived per policy)
• Undo if applicable

Payment Flow Coverage Checklist (Flow 5–6)

• Use Stripe test card 4242…
• Verify tier upgrades in app within 30s
• Verify webhook events fired (check Stripe dashboard or stripe listen)
• Verify receipt email received
• Failure card 4000 0000 0000 0002: verify error UI, no upgrade

Email Flow Coverage Checklist (Flow 7)

• Trigger email (signup, reset, receipt)
• Verify arrival in monitored inbox within 60s
• Verify subject matches expected template
• Verify primary tab placement (not Promotions / Spam)

Mobile Flow Coverage Checklist (Flow 9)

• Re-execute Flow 1 or 3 at 375px viewport
• Hamburger nav works
• Primary CTAs are tappable
• No horizontal scroll
• Keyboard doesn't break the form

Recently-Shipped Feature Coverage Checklist (Flow 10)

• Whatever shipped in the last release window
• Defined per-release (this is the only flow that varies)
• Should be < 5 minutes

Determinism Checklist

• Each flow uses a unique generated email (+{timestamp} plus addressing)
• Each flow cleans up after itself OR runs in isolation
• No flow depends on data created by another flow
• No flow depends on time-of-day
• No flow depends on third-party uptime beyond Stripe / SendGrid / your email host

Failure Reporting Checklist

For any failed flow:

• Screenshot at the point of failure
• Console / network log at the point of failure
• Specific assertion that failed
• Comparison: expected vs actual
• One-line summary suitable for posting in Slack

Verdict Output Format

After running:

• PASS — All 10 flows passed
• PASS-with-notes — All flows passed; minor anomalies noted but non-blocking
• FAIL — One or more flows failed; release blocked
• NEEDS-DECISION — A flow failed but you're unsure if it's a regression or an intentional change

Release Sign-Off Checklist

If PASS:

• Capture: timestamp, build hash, who ran the smoke, total runtime
• Post to release Slack channel / commit a verdict file
• Proceed with promotion

If FAIL:

• Don't promote
• File a ticket per failure
• Decide: hotfix forward, or revert

Time-Boxing Checklist

A smoke pass that takes 90 minutes isn't a smoke pass — it's a sweep. If your 10 flows exceed 30 minutes, ruthlessly cut:

• Pick 5 flows for the standard smoke
• Run the full 10 only for major releases
• Use prompt 423 (full E2E) for quarterly deep passes

MCP Automation Opportunity

This is the prompt most likely to benefit from full automation:

• Once your 10 flows are stable, encode them as a Playwright suite
• Run the suite via the MCP on each staging deploy
• Output the verdict to a release log
• Manual smoke becomes verification of automated smoke

Flow Ownership Checklist

Each flow should have a documented owner:

• Owner reviews quarterly: still the right 10? Still well-scoped?
• Owner updates the script when the underlying feature changes
• Owner is the first contact when the flow fails

---

Calibration

Don't cargo-cult 10 flows from another product. The right 10 are product-specific. Audit your support tickets, your activation funnel, and your billing-impact paths to pick yours. The smoke test's value is repeatability — if the 10 flows change every release, it's not a smoke test, it's an exploratory pass with a different name.

• Severity:

  • Critical — Any of the 10 flows fails → release blocked
  • Anomaly — Flow passes but with a noted concern → log for follow-up, don't block

• Confidence ratings: Confirmed (deterministic pass/fail), Flaky (passes intermittently — fix the flake before treating as a verdict).

• Anti-hallucination guard: Don't claim a flow passes without explicit assertions firing. Don't claim a flow failed due to "the app being slow" — that's flaky; fix the flake or remove the flow. The smoke test must be a hard signal.

Output Format

Start with the Release Verdict: PASS / FAIL / NEEDS-DECISION, build identifier, timestamp, total runtime.

1. Smoke Pass Manifest — Build, environment, credentials used
2. Per-Flow Results — Pass/Fail per flow, runtime, screenshots
3. Failure Details — For each failed flow: assertion, expected, actual, screenshot
4. Anomalies Noted — Pass-with-notes details
5. Recommendation — Promote / hold / hotfix

Keep the output skim-friendly — release engineers will read this fast to decide go/no-go.