Smoke vs Sanity vs Regression Testing: The Differences, With Examples

Smoke, sanity and regression testing are often used interchangeably, and that confusion leads to suites that are either too slow to run on every change or too shallow to catch anything. They answer three different questions.

Smoke testing: is this build worth testing at all?

A smoke test is a fast, shallow check that the most important parts of a build work: the app loads, users can sign in, the main page renders. It runs right after a deploy and should finish in a few minutes. If it fails, the build is rejected before anyone spends time on deeper testing.

Example: after every staging deploy, five checks confirm the homepage, sign-in, dashboard, API health endpoint and checkout page all respond correctly.

Sanity testing: does this specific change work?

Sanity testing is narrow and targeted. After a bug fix or small feature, you check that the change does what it should and has not obviously broken what sits right next to it. It is often unscripted when done by hand.

Example: a fix makes discount codes case-insensitive. A sanity check applies the code in upper and lower case and confirms the total, before the full regression run.

Regression testing: did anything that used to work break?

Regression testing reruns the broad suite of existing tests after a change, to catch side effects anywhere in the product. It is the widest and slowest of the three, and the one that actually protects you from the bug two screens away from your change.

Example: a refactor of invoice calculations triggers the full suite, which catches that CSV exports now omit tax.

Side by side

Scope: smoke is broad and shallow, sanity is narrow and focused, regression is broad and deep. Timing: smoke runs after every deploy, sanity after a specific fix, regression on every pull request or nightly. Duration: smoke takes minutes, sanity takes minutes, regression takes minutes to an hour depending on parallelism.

How to automate all three without three suites

You do not need three separate suites. Tag tests instead: a handful tagged smoke run after every deploy, tests tagged by feature run as a sanity pass for changes in that area, and everything runs as regression on pull requests. Playwright projects and grep tags make this straightforward.

The part that is hard to automate is trust. A regression suite is only useful if its failures are real, which is why failure classification and flaky-test quarantine matter as much as the tests themselves.