Smoke testing asks whether a build is stable enough to test at all. Sanity testing asks whether one specific change or bug fix works, and whether it broke anything right next to it. Smoke is wide and shallow across the whole product. Sanity is narrow and a little deeper, around one area.
People mix the two up because both are quick and both come before the big regression run. The difference is what triggers them and how much of the product they touch.
Sanity testing vs smoke testing
| Smoke testing | Sanity testing | |
|---|---|---|
| Question | Is this build alive? | Does this change work, and is the area around it still sane? |
| Scope | Whole product, critical paths only | One feature or fix and its neighbours |
| Depth | Shallow | Narrow but deeper |
| Trigger | A new build or deployment | A bug fix or a small change landing in a build that already passed smoke |
| Scripted? | Almost always automated | Often manual or a hand-picked subset of automated tests |
| Typical size | A few to a few dozen tests | A handful of checks chosen for this change |
| On failure | Reject the build | Send the change back to the developer |
| Documented? | Yes, a maintained suite | Often informal, sometimes a checklist in the ticket |
The “scripted” row is the one where sources disagree. Some textbooks say sanity is always unscripted. Plenty of teams also run it as a small tagged set of automated tests. Use what fits your team and write down which one you mean, because the argument about definitions costs more than the tests do.
For regression, which is the third term in this family, I do not repeat it here. Smoke testing vs regression testing has the comparison.
A smoke example
Say a team deploys a new build of an online shop to staging. The smoke suite runs:
- The home page loads.
- A user can log in.
- A product page opens.
- An item can be added to the cart.
- The checkout page opens.
None of these go deep. Checkout opens, but nobody pays. If step 5 fails, the build goes back, and nobody starts exploratory testing on something that cannot reach checkout.
A sanity example
Now a bug report comes in. Hypothetical, but typical: “Applying a percentage discount code on the checkout page gives the wrong total when the cart has two or more items.” A developer fixes it and the fix lands in a build that has already passed smoke.
A sanity check for this fix looks like this:
- Add two items to the cart and apply the discount code. Is the total right?
- Add one item and apply the same code. Is the total still right?
- Apply an invalid code. Does the error message still appear?
- Remove the code. Does the total go back to normal?
- Proceed to payment. Does the discounted total carry over to the payment step?
That is five checks, all around the discount feature. Nobody tests login or the product search here. The goal is to learn quickly whether the fix is real and whether the code next to it still behaves, before spending an hour on a full regression pass.
Do you need both?
If your team ships often and has automated tests, yes, though they cost different amounts.
Smoke is almost free once it exists. It runs unattended on every deploy. You need it because deployment failures (a wrong config, a missing migration) look nothing like logic bugs, and you want to catch them in two minutes.
Sanity is a habit more than a suite. Before you hand a fix to someone for full testing, run the checks around it. A developer can do this. So can QA, who often write the list as a comment on the ticket.
You can skip a formal sanity step when:
- the change is covered by an automated test that already ran in the pull request,
- the area is small and the fix is one line,
- smoke plus regression already run on every build quickly.
You should keep it when a fix touches shared code, when a regression run takes hours, or when a build will sit in front of a manual tester who should not waste time on a fix that does not work.
Where each fits in the release flow
A common order for one change:
- Developer opens a pull request. Unit and integration tests run.
- Merge to main triggers a build and deployment to staging.
- Smoke runs. If it fails, the build is rejected.
- Sanity checks run on the specific change.
- The full regression suite runs, nightly or before release.
The full pipeline version, including how to split a suite by tags, is in what is smoke, sanity, regression testing and how to use them in CI/CD.
FAQ
Is sanity testing a subset of regression testing? Mostly, yes. Sanity checks use the same kind of tests, narrowed to the area you changed. Regression has the wider job of rechecking everything.
Is smoke testing manual or automated? Automate it. It runs often and has to be fast, which is the case for automation.
Can one test be both smoke and sanity? It can be tagged for both. A checkout test might be in the smoke suite every time and in the sanity set when the change is about payments.
What about sanity vs regression? Sanity looks at one change and its neighbours, so it takes minutes. Regression rechecks the whole product, so it takes much longer and runs less often. Sanity tells you whether it is worth starting regression.
Which one runs first? Smoke. There is no point checking a fix in a build that does not start.
A first step
On your next bug fix, write the five checks you would run around it as a comment on the ticket before you ask anyone to test. If you notice the same checks again and again, that is your first candidate for a tagged automated set.