Learning Objectives
By the end of this lesson, you'll be able to:
- 🎯 Define smoke testing and explain its purpose to a teammate
- 🔍 Identify what belongs in a smoke test — and what doesn't
- ⚡ Make a build acceptance/rejection decision in under 15 minutes
- 📋 Explain why a failed smoke test means stopping, not continuing
The Big Idea
A new build arrives. You have 15 minutes. What do you test?
Not everything. Not even most things.
You test the critical path — the core functionality that must work for the product to be usable at all. If that doesn't work, nothing else matters.
This is smoke testing. And the name? It comes from hardware engineering: when you power on a new circuit board for the first time, you watch for literal smoke. If smoke appears, you power it off immediately. There's no point testing the nuanced functions of a circuit board that's actively on fire. 🔥
What Is a Smoke Test?
A smoke test is a shallow, wide check of the most critical functionality in a build.
- Shallow = you don't go deep into any single feature
- Wide = you touch all the major areas at a surface level
The goal is simple: is this build stable enough to be tested further?
Think of it as a triage decision. You're not the surgeon — you're the triage nurse who decides whether the patient goes to surgery or gets sent home with an aspirin.
What to Include in a Smoke Test
- ✅ Can the app launch / open without crashing?
- ✅ Can a user log in with valid credentials?
- ✅ Do the main navigation items render?
- ✅ Can the user reach the primary feature of the app?
- ✅ Does the most critical user action (buy, submit, send) complete without error?
What NOT to Include in a Smoke Test
- ❌ Edge cases (empty fields, invalid inputs)
- ❌ Error message text and formatting
- ❌ Performance measurements
- ❌ Visual pixel-perfection checks
- ❌ Any feature that isn't on the critical path
The Decision Rule
Smoke test passes → Hand the build to the full testing team. 🟢
Smoke test fails → Reject the build. Send it back to developers with a clear note: "Build failed smoke test: [specific failure]. Not ready for testing." 🔴
This is the most important part. When smoke testing fails, you stop. You don't log the other failures. You don't continue testing secondary features. You don't hope the devs fix it later. You reject the build and wait for a new one.
Why? Because if the critical path doesn't work, there's a high chance the underlying infrastructure is broken, and any testing you do on top of it produces unreliable results.
Real-World Example
Scenario: A new build of an e-commerce app arrives on a Tuesday morning.
Smoke test steps:
- Open the app → it loads ✅
- Log in with test credentials → success ✅
- Navigate to the product catalog → renders ✅
- Add a product to the cart → 500 Internal Server Error ❌
Decision: Build rejected. You send a message to the dev channel: "Build v2.3.1 failed smoke test at step 4: Add to Cart returns 500. Please investigate and re-deploy."
Time spent: 4 minutes. Time saved: 3 hours of testing on a broken build.
Pro Tips
💡 Write your smoke test checklist once, reuse it forever. A 5–10 item checklist that covers your critical path takes 30 minutes to write and saves hours on every sprint.
💡 Smoke tests should be the same every time. If your smoke test varies based on who's doing it, it's not reliable. Standardize it.
💡 Failed smoke tests are good news. They catch serious issues early, before you waste hours testing a broken system. Celebrate them.
Summary
- 🔥 A smoke test is a fast, wide, shallow check of the critical path
- 🚫 It does NOT cover edge cases, error states, or secondary features
- ✅ A passing smoke test means: "safe to test further"
- ❌ A failing smoke test means: "reject the build immediately"
- ⏱️ It should take 5–15 minutes maximum
Up next: Lesson 1.2 — Sanity Test: when the build passes smoke, but you still need to verify that specific fix actually works. 🧠