Smoke vs Sanity Testing
Once you know how to design a test case and tell a test scenario from a test case, the next question a real QA job throws at you is: when do I actually run all these tests? You can't run your entire test suite every single time someone touches the code — there isn't time, and most builds don't deserve it. Smoke testing and sanity testing are the two "quick check first" techniques that decide whether a build is even worth testing further. They sound similar, get confused constantly in interviews, and are actually used for two completely different moments in the testing timeline. This lesson nails down exactly when each one applies, using RecipeBox as the app under test.
What Is Smoke Testing?
Smoke testing is a shallow, wide check run on a freshly built or freshly deployed version of the application, before any detailed testing begins. The goal isn't to find subtle bugs — it's to answer one blunt question: "Is this build stable enough to test at all?" The name comes from hardware testing: you power on a circuit and check whether it literally starts smoking. If it does, you don't bother measuring voltages — you send it back.
For RecipeBox, a smoke test would be a short checklist run against every new build, such as:
- Does the RecipeBox app actually launch without crashing?
- Can a user log in with valid credentials?
- Does the Recipe List screen load and show at least the sample data?
- Does tapping "Add Recipe" open the Add/Edit Recipe form at all?
- Does Search return to a results screen instead of crashing or freezing?
None of these checks look closely at correctness (they don't check whether search results are accurate, only that search doesn't blow up). If any one of these fails, the build is rejected and sent back to development — testers don't waste hours writing detailed bug reports against a build that can't even log in.
What Is Sanity Testing?
Sanity testing is also a quick, narrow check — but it happens at a completely different point in time. It's run after a developer has fixed a specific bug or made a small, targeted code change, to verify that that particular fix works as intended, without re-running the full regression suite. It doesn't ask "is the whole build okay?" (that's smoke testing's job). It asks "did this one fix actually work, and did it break the immediately related functionality?"
For example, say a bug was logged: "RecipeBox's Prep Time field accepts negative numbers on the Add Recipe screen." A developer pushes a fix. A sanity test for that fix would be:
- Enter
-5into Prep Time on Add Recipe → confirm it's now rejected with a validation error. - Enter a valid value like
20→ confirm the recipe still saves normally. - Check the same field on the Edit Recipe screen, since it shares the form → confirm the fix applies there too.
That's it. A tester doing sanity testing does not also re-test Login, Search, and the entire Recipe List just because a Prep Time fix went in — that broader check is what regression testing is for (the next lesson).
Smoke vs Sanity: Side-by-Side
| Aspect | Smoke Testing | Sanity Testing |
|---|---|---|
| When it runs | On a new build, before deeper testing starts | After a specific bug fix or small code change |
| Scope | Wide but shallow — touches every major area briefly | Narrow but focused — only the fixed area and its close neighbors |
| Goal | Decide whether the build is stable enough to test at all | Decide whether a specific fix actually works |
| Depth | Very shallow — "does it load," not "is it correct" | Somewhat deeper, but only for the changed feature |
| Scripted? | Usually a fixed, repeated checklist | Usually improvised on the spot, based on what changed |
| If it fails | Whole build is rejected and sent back untested | Just that fix is reopened; rest of the build stands |
| Often automated? | Yes — smoke suites are common early automation candidates | Rarely — it's usually manual and ad hoc since fixes vary each time |
Worked Example: RecipeBox Smoke Test Checklist
A tester receives build RecipeBox v2.4.0-rc3 from the dev team. Before logging a single detailed test case, they run this 10-minute checklist:
| # | Check | Pass/Fail |
|---|---|---|
| 1 | App installs and launches on a test device | Pass |
| 2 | Login screen accepts valid credentials and reaches the Recipe List | Pass |
| 3 | Recipe List loads existing recipes without crashing | Pass |
| 4 | Add Recipe screen opens and its fields (title, ingredients, steps, photoUri, category, prepMinutes) render | Pass |
| 5 | Saving a simple new recipe returns to the Recipe List and shows it | Fail — app crashes on Save |
Because check #5 fails, the tester rejects this build outright and sends it back with a one-line note: "Crash on Save from Add Recipe — smoke test failed, build not accepted for further testing." No one spends time checking whether photoUri handles large images correctly, because there's no point testing depth on a build that can't complete its most basic flow.
Worked Example: RecipeBox Sanity Test After a Fix
A day later, a new build RecipeBox v2.4.0-rc4 arrives with a changelog note: "Fixed
crash on Save when ingredients list is empty." The tester doesn't repeat the whole smoke checklist
from scratch — instead they sanity-test just this fix:
- Add a recipe with an empty ingredients list and tap Save → confirm it no longer crashes.
- Add a recipe with a populated ingredients list and tap Save → confirm normal recipes still save correctly (no regression in the common case).
- Open the newly saved recipe in Edit mode → confirm the data persisted correctly.
All three pass, so the fix is verified. The tester then re-runs the smoke checklist to confirm the build overall is stable, and testing continues.