Automated Smoke Testing

The problem

After every deploy, someone should confirm the build isn't fundamentally broken before the team sinks time into deeper testing or, worse, before it goes further down the pipeline. In practice that check is ad hoc — someone loads the app, clicks around, and gives a thumbs up from memory — or it's a scripted smoke suite that's quietly gone stale.

Why the usual approach falls short

• Manual smoke checks are inconsistent. Different person, different clicks, different confidence each time.
• A scripted smoke suite decays. It covers a fixed list that stops matching the product, and it still breaks on UI changes.
• "Seems fine" isn't a signal you can gate on.

How Manta fits

Point Manta at a fresh deploy and it does the smoke check for you: loads the app, signs in, exercises the main flows, and reports whether the core works or what's broken — with screenshots. A shallow pass is fast enough to fit right after a deploy, and the result is a clear go/no-go instead of a vibe.

For the handful of things that absolutely must work for a build to be worth testing further — "the app loads and a user can log in" — pin those down as plain-English checks so they're verified explicitly every run. The glossary entry on smoke vs sanity testing covers where this sits relative to other quick checks.

What your first run looks like

1. Deploy to staging.
2. Run Manta — a quick pass plus your must-work checks.
3. Green: proceed. Red: the findings tell you exactly what's broken.

Where it fits

Smoke testing is the first gate after a build. Unit and integration tests run earlier; the autonomous smoke pass confirms the whole thing hangs together before deeper testing or a release. See release testing for the checkpoint before production and continuous testing for keeping the loop running.