Release Testing & Pre-Release QA

The problem

Before every release, someone runs through the critical flows by hand: sign up, log in, the main create/edit/delete loop, checkout, settings. It's slow, it's boring, it's error-prone, and it's the step that gets compressed when the release is late — which is exactly when regressions slip through.

Why the usual approach falls short

• Manual pre-release QA is a person-shaped bottleneck. It doesn't fit a same-day hotfix or a team shipping daily.
• A scripted smoke suite helps but decays. It covers a fixed list, and that list stops matching the product.
• Coverage silently narrows under pressure. "Check the important bits" becomes "check the bits I have time for."

How Manta fits

Point Manta at the release candidate on staging and it runs the pre-release sweep for you — exploring every reachable flow and checking the plain-English journeys you've defined as must-pass. You get back a clear result: which explicit checks passed, and what broken behaviour the exploration turned up, each with a screenshot and reproduction steps you can hand straight to a developer.

The plain-English checks are where you encode "this must work to ship": "a new user can sign up, verify their email, and complete onboarding." How to write those is its own short guide.

What it looks like in practice

1. Deploy the release candidate to staging.
2. Run Manta — the autonomous sweep plus your must-pass checks.
3. Review findings; fix or accept; ship.

Where it fits

This is the layer between your CI test run and production. Unit and integration tests run earlier and faster; the pre-release Manta run is the "does the whole thing still work for a user" check that used to land on a person. See the end-to-end testing guide for how it sits in the wider strategy.