Both are short. Both run before the detailed testing. Both get described as “a check”. That is where the similarity ends, and mixing them up wastes time in a specific way: it produces a result you cannot interpret.
The one-line version is that smoke testing asks whether the build works at all, and sanity testing asks whether one particular change did what it was supposed to without breaking its neighbours. Smoke is about the build. Sanity is about the change.
The difference in one table
| Smoke testing | Sanity testing | |
|---|---|---|
| Question | Is this build stable enough to test? | Did this specific change work, and what did it affect? |
| Trigger | A new build arrives | A targeted fix or small feature is deployed |
| Scope | Broad and shallow, many areas one level deep | Narrow and deep, one area and what touches it |
| Depends on | Nothing, it runs first | A build that has already passed smoke |
| Typical size | 10 to 30 checks | 5 to 15 checks, chosen per change |
| Scripted? | Yes, the same suite every time | No, decided after reading what changed |
| Automation | Almost always, in CI on every build | Sometimes, for areas that change often |
| Failure means | Reject the build entirely | Return the fix to development |
| Typical duration | 15 minutes | An hour or two |
The row that carries most of the meaning is “scripted”. A smoke suite is fixed and the same on every build, which is what lets it be automated and run unattended. A sanity check is chosen after looking at what the change touched, which is why it resists automation and why it needs someone who understands the change.
What each one looks like in practice
Take a payment bug: card validation is wrongly rejecting one card brand, a developer fixes the validation rule, the fix is deployed.
The smoke test on that build does not know or care about the payment bug. It runs its usual fixed set. Is the app up and is it the right commit, can each role log in, does the main list view render, can the core object be created and reloaded, do the database and payment provider answer their health checks. It takes twelve minutes and it passes. That result means one thing: the build is not fundamentally broken, so testing the fix is now worth doing.
The sanity check is chosen by reading the diff. The change touched the validation rule, so the checks are: the previously rejected card brand is now accepted, the other brands still work, genuinely invalid numbers are still rejected, and an expired card is still refused. Then the neighbours, which is the half people skip: validation usually runs in more than one place, so if the same rule is applied at saved-card creation or at subscription renewal, those get checked too.
Notice that the fourth and fifth checks exist because of what the code does, not because of what the ticket said. That is the whole skill in sanity testing, and it is why a fixed checklist cannot do this job.
If the sanity check fails, the fix goes back. You do not reject the build, because the build was fine; one change in it was not.
Choosing between them
There is no choosing, in most situations. They are sequential, not alternatives.
A new build arrives, so you smoke it. It passes, so you sanity check whatever changed in it. Both of those happen before the detailed functional and regression work. The only real decision is what goes into the sanity check, and that is answered by reading the change rather than by a rule.
Two situations where people get the order wrong are worth naming. Running sanity before smoke means a failure is uninterpretable: you cannot tell whether the fix is bad or the build is. And running only smoke on a build that contains a specific fix means nobody actually verified the fix, because the smoke suite is fixed and knew nothing about it. A build can pass smoke perfectly while the one change it was built for does not work.
Where regression testing fits
This is the question that usually follows, because all three are described as “checking that things still work”.
Sanity testing is narrow and immediate: the area around one change, straight after that change, often manual, usually under two hours. Regression testing is broad and scheduled: a maintained suite covering everything the product already promised, run before a release or nightly, almost entirely automated, and it takes as long as it takes.
Sanity testing is not a smaller regression run and does not replace one. It is a fast answer to “is this fix worth keeping” while the change is still fresh in someone’s head. The regression suite is what catches the damage nobody predicted, in a part of the system nobody connected to the change. Both are needed, and a team that runs only sanity checks will ship a regression eventually, because the whole nature of a regression is that it appears somewhere you did not think to look.
What about acceptance testing?
Acceptance testing is the third check in this family and it is easy to separate from the other two, because it is the only one that is not asking a technical question. Smoke and sanity are run by QA and ask whether the software works. Acceptance testing is run by users, the product owner or the client, and asks whether the software does the right thing.
It happens at the end rather than the beginning, it works from business scenarios rather than from a build or a diff, and a failure blocks the release rather than rejecting a build. It also takes days rather than minutes, because it involves people whose main job is not testing.
The mistakes worth avoiding
Letting the smoke suite absorb sanity checks. Every escaped bug creates pressure to add “just one more” case to smoke. Do that for a year and smoke takes ninety minutes and gets skipped on busy releases. Keep the budget: if a case would not cause you to reject the entire build, it belongs in regression, not smoke.
Writing sanity checks from the ticket instead of the diff. The ticket describes intent; the diff describes what actually changed. The regressions that get through are almost always in code the ticket never mentioned.
Treating a passed sanity check as release confidence. It confirms one change behaves. It says nothing about the other forty things in the release, which is the regression suite’s job.
Sources
The ISTQB glossary gives the standard definitions used here, and the wider documentation standard is ISO/IEC/IEEE 29119.
For the longer treatment of either one on its own, see what smoke testing is and what belongs in the suite, and for where both sit in the overall process, the software testing life cycle.
BetterQA runs both as part of embedded QA work. The usual first job is not adding checks but cutting a smoke suite back to something that runs fast enough to be run every time.
Built by BetterQA
Need help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
