Smoke vs sanity testing: what each actually buys you

Plenty of teams use these terms interchangeably, and it mostly doesn't hurt until someone asks "did we smoke test it?" and means something different from what you did. The distinction is genuinely useful, though: it tells you when in the cycle a quick check belongs, how wide it should be, and what a failure means. Get those right and you stop wasting a full test pass on a build that was never going to work.

What each one is

Smoke testing is broad and shallow, run early. It touches the major functions of the build — can you log in, does the home screen load, can you reach checkout — without going deep into any of them. Its job is build acceptance: a go/no-go gate that decides whether the build is stable enough to deserve real testing at all. It's the first thing you run on a new build, it's an excellent CI gate, and a smoke failure means stop — reject the build, don't waste a day testing on top of broken foundations.

Sanity testing is narrow and deep, run after a change. When a specific fix or small feature lands, you check that area works as intended before committing to broader regression. It's focused on the thing that changed plus its immediate surroundings — confirm the new discount code applies correctly, glance at the cart total, move on. Its job is to decide whether the change is sane enough to be worth a full regression pass, or whether it's obviously broken and should bounce straight back.

The decision rule

Reach for a smoke test when you've got a new build and need to know if it's worth your time — early, wide, mechanical, ideally automated in CI so it runs before a human looks at anything. Reach for a sanity test when a specific change has landed and you need a quick, focused confidence check on that area before investing in deeper regression. One protects you from testing a dead build; the other protects you from regression-testing around a change that never worked.

Smoke vs sanity: which, when

• New build just arrived → smoke: hit the major flows, decide go/no-go
• Smoke failed → reject the build; don't test further on broken foundations
• Specific fix or small feature landed → sanity: focused check on that area
• Sanity failed → bounce it back before spending effort on full regression
• Smoke is a great automated CI gate — broad, shallow, fast, runs on every build
• Sanity is usually manual and ad-hoc — it follows whatever just changed, so it's hard to pre-script
• Neither is a substitute for regression or a release sign-off — they're gates before the real work, not the work itself

The trap

The mistake isn't mixing up the words — it's skipping the gate they represent. Teams that don't smoke test spend hours discovering, deep into a careful regression pass, that the build was broken on launch and none of it counted. Teams that don't sanity check pour a full regression cycle around a change that was obviously wrong from the first click. Both checks are cheap precisely because they're shallow — that's the feature, not a limitation. They exist to stop you investing expensive, thorough testing in a build or a change that hasn't earned it yet.