Smoke vs Sanity Testing
Quick Answer
- Smoke testing asks: "Is this new build stable enough to test at all?" It's broad and shallow — the core flows across the whole application.
- Sanity testing asks: "Does this specific fix or change work, and does the area around it still make sense?" It's narrow and focused.
Smoke = wide and shallow. Sanity = narrow and deep. Smoke comes first on every new build; sanity follows for the parts that changed.
Comparison at a Glance
| Aspect | Smoke testing | Sanity testing |
|---|---|---|
| Question | Is the build testable? | Does this change work? |
| Scope | Broad — critical flows across the application | Narrow — the fixed or changed area and its neighbors |
| Depth | Shallow | Deeper, within the changed area |
| When | On every new build, before anything else | After a fix or small change, once the build is stable |
| Scripted? | Yes — a fixed, documented suite, usually automated | Often unscripted or lightly scripted, chosen per change |
| Relationship | Often called Build Verification Testing (BVT) | A focused subset of regression testing |
| Who | QA (or the CI pipeline); sometimes developers before handover | QA |
| If it fails | The build is rejected — no further testing | The fix is reopened; the release of that change is blocked |
| Typical time | Minutes | Minutes to an hour |
One Example, Both Tests
The situation: an e-commerce site gets build 2.4.1. It contains a fix for a bug where the discount coupon was applied twice at checkout.
Smoke test (first, on the whole build)
- The home page loads.
- A user can log in.
- Search returns products.
- A product can be added to the cart.
- Checkout reaches the payment page.
If login fails, testing stops here and the build goes back to development — there's no point testing a coupon on a site where nobody can log in.
Sanity test (next, on the change)
- Apply the coupon — the discount is applied once.
- Apply it again — the second attempt is rejected with a clear message.
- Remove it and re-apply — the total is correct.
- Check the order total, tax and the order confirmation reflect the single discount.
If the discount is still applied twice, the defect is reopened. The rest of the build may still be tested — it's the fix that failed, not the build.
Smoke Testing in Detail
Smoke testing verifies the application's critical functionality immediately after a new build is deployed to a test environment. Its purpose is to decide whether the build deserves detailed testing.
- Covers the most important end-to-end flows, not edge cases.
- Uses a fixed, documented set of tests — the same every build.
- Runs fast: a good smoke suite takes minutes.
- Is the first thing to automate and run in CI on every deployment.
The name comes from hardware testing: power on a new device and see if it starts smoking.
Sanity Testing in Detail
Sanity testing checks that a specific change behaves correctly and hasn't obviously broken the functionality right around it. It's typically done:
- After a defect fix, alongside retesting the original defect.
- After a small change or configuration update.
- When there's no time for full regression before a release.
Because it verifies existing behavior around a change, it's usually described as a focused subset of regression testing. Note that terminology varies between companies — some teams use "sanity" for what others call a quick smoke check. In interviews, give the standard definitions and say your team's usage if it differed.
Where BVT Fits
Build Verification Testing (BVT) is a set of tests run on every new build to decide whether it's accepted for testing — in practice, another name for the smoke suite, and nearly always automated.
A good BVT / smoke suite
- Covers only critical, stable functionality.
- Finishes in minutes.
- Runs automatically on every deployment.
- Has reliable tests — a flaky smoke test blocks everyone.
- Fails loudly, with clear evidence of what broke.
In a TestNG framework, tag these tests groups = "smoke" and run them in CI with mvn test -Dgroups=smoke; in Cucumber, tag scenarios @smoke. See The Complete Jenkins Tutorial.
The Order: Smoke → Retesting → Sanity → Regression
- Smoke — is the new build stable enough to test?
- Retesting — are the reported defects actually fixed?
- Sanity — do the changed areas behave correctly around those fixes?
- Regression — did the changes break anything elsewhere?
More on each testing type: Functional Testing Types.
Common Mistakes
- A smoke suite that grows into a regression suite — if it takes an hour, it's no longer smoke.
- Skipping smoke on "small" builds — a broken deployment wastes everyone's afternoon.
- Treating sanity as a replacement for regression — it reduces risk around a change; it doesn't prove the rest of the application still works.
- Unreliable smoke automation — false failures teach the team to ignore it.
Practice deciding what to smoke-test and what to sanity-test on realistic builds in the Manual Testing Simulator.
The Interview Answer
"Smoke testing is a broad, shallow check on every new build to decide whether it's stable enough to test — login, search, cart, checkout. If it fails, we reject the build. Sanity testing is narrower: after a fix or small change, I check that the change works and the area around it still behaves. For example, after a coupon fix, I'd verify the discount applies once, can't be applied twice, and the totals are right. If sanity fails, I reopen the defect. In our framework, the smoke suite is automated and runs in Jenkins on every deployment."
From Real Projects
Before any automation, my work on each project started with the requirement: understanding the business flow, identifying scenarios, writing test cases and getting them reviewed. On Canolog, where sales, inventory, finance, service and parts all connect, that analysis is what found the gaps between modules. Execution was tracked in TestRail and defects in Jira. On Apkope, prospect and customer data arrives from email, phone, social media and chatbots, so test scenarios had to cover every channel that feeds the same records. Smoke asks whether the build is testable; sanity asks whether a specific change works.
📚 Official documentation: ISTQB Glossary of testing terms
Frequently Asked Questions
What is the difference between smoke and sanity testing?
Smoke testing checks that a new build's critical functions work so testing can continue; sanity testing checks that a specific fix or change works and hasn't broken its immediate area.
Which comes first?
Smoke — then retesting of fixed defects, sanity around the changes, and regression.
Is sanity testing part of regression testing?
It's usually treated as a focused subset of regression, because it re-checks existing behavior around a change.
What happens if smoke or sanity testing fails?
A failed smoke test rejects the whole build. A failed sanity test reopens the fix and blocks that change, though other testing may continue.
Is BVT the same as smoke testing?
In practice, yes — BVT is the (usually automated) smoke suite run on every build.
Should smoke tests be automated?
Yes. They run on every build, so they're the highest-value tests to automate and run in CI.
