Is smoke testing done before or after sanity testing?

Smoke testing usually comes first. It runs against a fresh build to confirm the core paths work and the build is worth testing at all. Sanity testing comes later, after a specific bug fix or minor change lands on an already-stable build, to confirm that one area behaves correctly.

Is smoke or sanity testing a subset of regression testing?

Sanity testing is often treated as a focused subset of regression testing, aimed at the code that just changed and its immediate neighbors. Smoke testing is broader and shallower and is usually considered its own gate, run before regression testing begins.

Should smoke and sanity tests be automated?

Smoke tests are the best automation candidate: they run on every build, cover the same critical paths, and rarely change, so a scripted suite in CI pays off quickly. Sanity checks are frequently ad-hoc and tied to a specific change, so they are often run manually — though repeatable ones are worth promoting into your regression suite.

Smoke Testing vs. Sanity Testing: What's the Difference?

Smoke testing and sanity testing both decide whether it's worth investing in deeper QA, but they answer different questions. Smoke testing is a wide, shallow pass over a new build's most critical paths to confirm the build is stable enough to test at all. Sanity testing is a narrow, deep check that a specific change or bug fix works as intended without breaking the features around it. In practice you run a smoke test first to accept the build, then run a sanity test after a targeted change.

What is smoke testing?

Smoke testing (sometimes called build verification testing) is a quick, broad check that the core functionality of a new build works. The name comes from hardware testing: power on the device and see if it smokes. If a login, a checkout, or the main dashboard is broken, the build fails the smoke test and goes back to the developers before QA wastes time on it.

The defining traits of a smoke test:

Wide and shallow. It touches many features but tests none of them deeply — one happy-path check per critical flow.
Runs on every build. A smoke test is a gate, so it runs each time a new build is produced, ideally automatically in CI.
Fast and scripted. Because it repeats constantly, a good smoke suite is documented, automated, and finishes in minutes.

What is sanity testing?

Sanity testing is a focused check performed after a minor change — usually a bug fix or a small feature tweak — on a build that is already known to be stable. Instead of covering everything, it verifies that the specific thing you changed now behaves correctly and that closely related functionality still works.

The defining traits of a sanity test:

Narrow and deep. It exercises one area thoroughly, including the edge cases around the change, rather than skimming the whole product.
Runs after a targeted change. You reach for a sanity test when a fix lands and you need to confirm it before running a full regression pass.
Often unscripted. Sanity checks are frequently ad-hoc and tied to the exact change, so they lean on a tester's judgment more than a fixed script.

Smoke testing vs. sanity testing: the key differences

The two tests differ on four axes that make it easy to tell them apart:

Purpose. Smoke testing verifies overall build stability; sanity testing verifies that a specific change works.
Scope. Smoke is broad and shallow (breadth); sanity is narrow and deep (depth).
Timing. Smoke runs on every new build up front; sanity runs after a minor change to an already-stable build.
Form. Smoke is typically scripted and automated; sanity is typically ad-hoc and manual.

A useful shorthand: smoke testing asks "is this build worth testing?" while sanity testing asks "did this change do what we wanted, and only that?" Both are gates that let you fail fast — they exist so you don't pour hours of regression effort into a build that was never going to survive it.

When should you run each?

Slot them into your QA flow like this:

New build arrives → smoke test. Run the automated smoke suite in CI. If a critical path is broken, reject the build immediately and skip everything downstream.
Bug fix or small change lands → sanity test. On a build that already passed smoke, verify the changed area deeply before committing to a full pass.
Sanity passes → regression test. Once the targeted change checks out, run your broader regression suite to catch side effects elsewhere.

Sanity testing is often described as a subset of regression testing focused on recent changes, while smoke testing sits earlier as its own build-acceptance gate. They are complementary, not interchangeable.

How this maps to modern, automated QA

Smoke tests are the highest-value thing to automate because they run on every build and rarely change — a small, fast, end-to-end suite covering login, core navigation, and one or two revenue paths catches most catastrophic breakages before a human looks at the build. The catch is maintenance: when a selector or flow changes, a brittle smoke suite starts failing on the test rather than the product, and teams learn to ignore it.

That's the failure mode AutoSim is built to prevent. Self-healing end-to-end tests repair broken selectors automatically when the UI shifts, so your smoke suite keeps guarding the critical paths instead of flaking out. And when a sanity check does surface a real regression, Snap captures the screenshot, console, and network evidence in one click so the fix round-trips fast. Keep the discipline — smoke first, sanity after — and let automation carry the parts that repeat.