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

It is 4:45 on a Thursday and the release is supposed to ship at 5. QA gets pinged with "can you just sanity check the build real quick." Someone else, ten minutes later, asks "did smoke testing pass yet." Half the team treats these as the same request. They are not.

Mixing up sanity testing vs smoke testing is how a team burns 40 minutes rerunning the wrong five minute check while the release window closes. This post settles the difference in one sentence, then walks through a real fix so you can see exactly where each check belongs.

The one sentence difference

Smoke testing asks "did the build even work." Sanity testing asks "did this one fix work." That is the whole distinction. Everything else follows from it.

• Smoke testing runs right after a new build or deployment, before anyone trusts it enough to test anything specific.
• Sanity testing runs right after a targeted code change or bug fix, to confirm that one change behaves and did not break its immediate neighbors.

Smoke testing is broad and shallow. Can you log in, does the homepage load, does checkout open. Sanity testing is narrow and specific. Does the "apply discount code" button now actually apply the discount, and did fixing it break the cart total nearby.

Why teams keep confusing them

Both checks are quick. Both happen under time pressure. Both get called "a quick check" in Slack, which is exactly how they get swapped.

A team that runs a full smoke test every time someone asks for a sanity check wastes time on 20 unrelated screens when the actual question was about one login bug. A team that runs a two minute sanity check when what they needed was a smoke test ships a build where the login page itself is broken. Nobody ever checked the build as a whole.

The cost shows up in specific, recognizable ways:

• The release held on a Thursday because "sanity testing" of a checkout fix never touched the payment gateway, and the gateway was down.
• The 15 minute smoke test that got skipped because someone assumed the sanity check on the search bar covered "the app works." It only covered search.
• The Safari only checkout bug that reached a customer because the sanity check for a price rounding fix ran only in Chrome.

None of these are exotic failures. They are what happens when a five minute check gets asked to do a job it was never scoped for.

A worked example

Say a developer fixes a bug where the "remove item" button in the shopping cart wasn't actually removing the item. The fix is a five line code change.

Here is what a sanity check on that fix looks like:

1. Add three items to the cart.
2. Click "remove" on one item.
3. Confirm it disappears and the cart total updates correctly.
4. Confirm the other two items are untouched.
5. Confirm the cart count in the header updates too.

That's it. Five steps, maybe 3 minutes, entirely focused on the one behavior that changed and its closest neighbors. You are not touching login, checkout, or the product catalog page. Those are out of scope for a sanity check on this fix.

Now compare that to the smoke test that should happen after this fix is deployed to a shared environment:

• Can a user log in.
• Does the product listing page load.
• Can a user add an item to the cart.
• Can a user reach the checkout page.
• Does the order confirmation page render after a test purchase.

That smoke test doesn't care about the "remove item" fix specifically. It cares whether the build, as a whole, is stable enough to hand to the rest of the team for deeper testing.

When to run which one

• Run a smoke test after every new build, every deployment to a shared environment, and before a release candidate goes to the wider QA team.
• Run a sanity check after a specific bug fix or small change, focused only on that change and its immediate surroundings.
• If a build fails smoke testing, stop. There is no point running sanity checks on individual fixes inside a build that doesn't load.
• If a sanity check fails, the fix goes back to the developer. That does not mean the whole build is broken. It just means this one change isn't done yet.

A 900 test suite that takes 50 minutes to run is neither of these. Full regression testing is a separate, much larger exercise. Treating a smoke test or a sanity check as a substitute for it is its own separate mistake.

Writing these checks down so they don't drift

The confusion between sanity and smoke testing rarely comes from a lack of understanding. It comes from these checks living only in someone's head, or in a Slack thread that scrolls away.

Once a smoke test is written down as a documented test case, with a clear scope and a fixed list of steps, anyone on the team can run it and know exactly what it does and doesn't cover. The same goes for a sanity check tied to a specific bug fix.

That documentation habit is small, but it is what actually prevents the Thursday afternoon confusion. When a ticket says "run the sanity check for TICKET 4821," a documented test case answers the question in seconds instead of starting a debate about what that even means this time.