What is the difference between smoke testing and sanity testing?

Smoke testing broadly verifies that the critical functions of a whole build work, usually automated and run on every build. Sanity testing is a narrow, often manual check that one specific change or bug fix behaves as expected, without re-testing everything else. In short: smoke tests breadth on a new build; sanity tests depth on a specific change.

Is smoke testing manual or automated?

Both exist, but smoke tests are ideally automated so they run on every build without human effort. Manual smoke passes are still common before a demo, or when automation doesn't yet cover a newly built area.

How long should a smoke test take?

A few minutes at most. The whole point is a fast gate: if your smoke suite takes longer than your team is willing to wait on every build, people will skip it. Aim for under five minutes and roughly 5–20 checks.

Should smoke tests run in production?

Yes — run a read-mostly smoke test after every production deploy to catch config, secret, and infrastructure failures that pre-deploy tests can't see. Use safe, idempotent checks like health endpoints and a synthetic login, and avoid mutating real customer data.

What Is a Smoke Test? Definition, Uses, and Examples

A smoke test is a small, fast set of checks that confirms a build's most critical functions work before anyone spends time on deeper testing. If the smoke test fails, the build is rejected immediately — there is no point running a full regression suite on software that can't log in or load its home page. Smoke tests are typically automated, run on every build, and finish in minutes.

Why is it called a smoke test?

The term comes from hardware and electronics: power on a new circuit board and watch whether it literally smokes. If smoke appears, the unit is dead and any detailed testing is pointless. Software borrowed the metaphor — a smoke test is the "does it even turn on?" check. You'll also see it called build verification testing (BVT) or a build acceptance test, because a passing smoke test is what earns a build the right to be tested further.

What does a smoke test check?

A good smoke suite covers the handful of paths that, if broken, make the rest of the product untestable or worthless. One check per critical feature — breadth, not depth. A typical web-app smoke suite verifies:

The application boots — the app starts and the home or login page renders without a fatal error.
Authentication works — a user can log in and reach an authenticated page.
The core create/read path works — the primary object of your product (an order, a document, a message) can be created and then viewed.
Critical integrations respond — the payment provider, database, or any dependency the core flow relies on returns a healthy response.
No fatal errors on the main screens — key pages load without uncaught JavaScript errors or HTTP 500s.

If any of these break, the build is ship-blocking. Keep the suite to roughly 5–20 checks: a "smoke test" that takes 30 minutes is no longer a smoke test.

Smoke testing vs. regression testing

They answer different questions and run at different times:

Scope: smoke is breadth-first — one check per critical feature. Regression testing is depth-first — many cases per feature, including edge cases.
Trigger: smoke runs on every build or deploy as a gate. Regression runs before a release or on a nightly schedule.
Speed: smoke finishes in minutes; a full regression suite can take hours.
Purpose: smoke answers "is this build even worth testing?" Regression answers "did we break anything that used to work?"

Put simply: the smoke test is the gate, and regression is the full inspection you run once the gate passes.

When should you run a smoke test?

On every CI build — before the expensive full suite, so a broken build fails in two minutes instead of forty.
After every deploy — a post-deploy smoke test against the live environment catches config, secret, and infrastructure breaks that unit tests can't see.
Before a demo or release — a quick smoke pass confirms the critical path is intact before anyone watches.
After a dependency or infra change — a new database, a new API version, or a rotated certificate all warrant a fresh smoke run.

How to keep a smoke suite fast and trustworthy

A smoke test only works as a gate if people trust it. Four practices keep it healthy:

Cap the count and the runtime. Pick the smallest set of checks that proves the product is alive, and give the suite a hard time budget. Growth is the enemy of a smoke test.
Assert outcomes, not implementation. Check "the dashboard shows the signed-in user's name," not a brittle CSS selector three levels deep. Outcome-based checks survive routine UI changes.
Fix flakiness the day it appears. A smoke test that fails randomly gets ignored, which defeats the entire purpose of a gate. Broken selectors after a UI change are the most common cause; self-healing end-to-end tests re-anchor to stable attributes so the gate stays green when only the markup moved, not the behavior.
Make failures loud and specific. A failed smoke test should name exactly which critical path is down — "login returned 500" — so on-call can act without opening a debugger.

The bottom line

A smoke test is your product's heartbeat check: a few minutes of breadth-first verification that answers whether a build is alive enough to test further. Keep it small, keep it fast, keep it green, and put it in front of every build and every deploy. When one does fail, the follow-up matters just as much — capture the failing state (URL, console, network) so the fix ships in the same session instead of a "cannot reproduce" round-trip.