Learning Objectives
By the end of this lesson, you'll be able to:
- 📊 Compare smoke and sanity testing across six dimensions
- 🔀 Use a simple decision flowchart to pick the right test type instantly
- 🚫 Recognize the most common way these tests are confused
- 💬 Explain the difference clearly to a developer or PM
The Big Idea
Two tests. Both fast. Both important. Completely different purposes.
If there's one confusion that haunts junior QAs, it's this one: "Is this a smoke test or a sanity test?"
By the end of this lesson, you'll never mix them up again. We'll build your mental model with a comparison table, a decision flowchart, and three practice scenarios.
The Side-by-Side Comparison
| Dimension | Smoke Test | Sanity Test |
|---|---|---|
| Trigger | New build received | Specific bug marked "Fixed" |
| Scope | Wide — whole product at surface level | Narrow — one specific area |
| Depth | Shallow — just verifying it works at all | Deeper — verifying logic and adjacent paths |
| Who initiates | QA team, when a new build arrives | QA, after a developer closes a bug |
| Frequency | Every new build | Every time a bug is "Fixed" |
| Documentation | Optional checklist | Driven by the bug report |
| Outcome | Accept or reject the build | Verify or reopen the bug |
The Decision Flowchart
A new build arrived?
└── YES → Run SMOKE TEST
├── Passes → Hand to full testing team
└── Fails → Reject build, send back to devs
A developer marked a bug as "Fixed"?
└── YES → Run SANITY TEST
├── Passes → Close bug, mark "Verified"
└── Fails → Reopen bug, add test evidence
The one-sentence rule:
🔥 Smoke = "Is this build worth opening?" → Wide and shallow 🧠 Sanity = "Did this specific fix actually work?" → Narrow and deep
The Most Common Confusion
Here's what actually trips people up:
Confusion 1: "I do a smoke test after every bug fix."
❌ No. After a bug fix, you do a sanity test. Smoke testing happens when a new build arrives — not after individual fixes within a build.
Confusion 2: "My sanity test covers the whole app."
❌ No. If you're testing the whole app, that's regression testing. A sanity test covers only the specific area of the fix plus a couple of adjacent paths.
Confusion 3: "Both tests are basically the same — just quick checks."
❌ No. They differ in trigger, scope, depth, and purpose. The fact that both are fast doesn't make them equivalent.
Practice Scenarios
Scenario A: The team deploys a new version of the mobile app to the test environment. You receive an email saying "Build 4.2.0 is ready."
🤔 Smoke or Sanity?
✅ Smoke test. A new build arrived. Your job is to verify the critical path before the full testing team digs in.
Scenario B: A developer just updated a ticket: "Fixed: profile photo upload was failing on iOS. Now sends correct Content-Type header."
🤔 Smoke or Sanity?
✅ Sanity test. A specific bug was fixed. Go to iOS, try uploading a profile photo, confirm it works, test one adjacent path (e.g., uploading an oversized file).
Scenario C: After a big sprint, the team releases a build with 15 bug fixes. The PM wants to know if it's ready for staging.
🤔 Smoke or Sanity?
✅ Smoke test first (is the build stable?), then 15 sanity tests (one per bug fix), then consider whether any changes warrant regression testing of nearby areas.
The Bookmark-Worthy Cheat Sheet
SMOKE TEST
When? → New build arrived
What? → Critical path only (login, navigate, core action)
How? → Wide and shallow
Result → Accept build or reject it
SANITY TEST
When? → Bug marked "Fixed"
What? → The specific area of the fix + 1–2 adjacent paths
How? → Narrow and deep
Result → Verify and close, or reopen with evidence
Pro Tips
💡 In fast-moving teams, both tests are often informal. You don't need a Jira ticket or a test plan document. A quick note in the bug comment or Slack is enough.
💡 You can combine them. When a new build arrives that also includes bug fixes, run a smoke test first. If it passes, run sanity tests on the fixed bugs. Then escalate to regression if the changes are risky.
💡 Both tests are "done" when you have a clear decision. "The build is stable" or "the bug is verified" — these are your exit criteria. Don't keep testing past the decision point.
Summary
- 🔥 Smoke → triggered by a new build → wide + shallow → accept or reject
- 🧠 Sanity → triggered by a fix → narrow + deep → verify or reopen
- 🚫 They are NOT the same, not interchangeable, and not "just quick tests"
- 📋 Use the comparison table and flowchart whenever you're unsure
Module 1 complete! 🎉 Ready for Module 2? Lesson 2.1 covers re-testing — the precise science of confirming that a specific closed bug is actually gone. 🔁