Smoke Testing
The 5-minute health check every tester does first. If the core features don't work, stop. Don't waste time on details.
1 The Hook
A tester at an NZ government portal spent three hours writing detailed test cases for every form field. Then they tried to log in. The login button was broken. Three hours wasted. A 5-minute smoke test would have caught it immediately. Smoke testing is always Step One.
2 The Rule
If the core features don't work, stop. Don't waste time on details.
Smoke testing is not deep testing. It checks that the most important parts turn on. Like checking if a light switch works before you worry about the wallpaper.
3 The Analogy
Turning on a car.
Before a road trip, you turn the key. Does the engine start? If it won't start, you don't test the radio. Smoke testing is the same: check the big things first. Only then worry about the small things.
4 Watch Me Do It
Follow these four steps every time a new build arrives.
- Identify 5–10 critical features Ask: "If this breaks, can users do anything at all?"
- Write one simple test case per feature Keep it short. "Load homepage." "Log in with valid user." No edge cases.
- Run the tests after every build New build? Run smoke tests first. Every time.
- Pass or fail, then document If everything passes, the build is ready for deeper testing. If anything fails, stop and reject it.
| # | Test | Result |
|---|---|---|
| 1 | Homepage loads | Pass |
| 2 | RealMe login works | Pass |
| 3 | Service finder returns results | Pass |
| 4 | Contact form submits | Pass |
| 5 | PDF download works | Fail |
Test #5 failed. Stop here. Don't test form validation or notifications. Send the build back.
Scenario 2: Different smoke test by project size
A large e-commerce platform has more critical paths than a small brochure site. The smoke test must reflect the complexity of the application.
| Project Type | Smoke Test Count | Critical Paths Tested |
|---|---|---|
| Simple brochure site | 3-4 tests | Homepage loads, contact form, navigation links |
| e-Commerce site | 8-10 tests | Browse, search, cart, checkout, payment, account |
| Government/financial portal | 10-12 tests | Login, data retrieval, form submission, security features |
The principle is the same: test the critical paths, then stop. But the number of paths scales with project complexity. Know your product's core features.
5 When to Use It / When NOT to Use It
✅ Do it when...
- A new build arrives
- The environment changes
- You need a quick yes/no on build health
❌ Skip it when...
- You need deep feature coverage
- You are testing edge cases
- The core features are already stable
Before you apply this technique, ask:
- Is your build complete enough to test core features, or is it still incomplete?
- Do you have 5-10 minutes uninterrupted for a quick health check?
- Are the environments (staging, test) stable enough to run smoke tests?
- Is this a new build or an incremental change that might affect core paths?
6 Common Mistakes
🚫 Going too deep
I used to think: More tests means better smoke testing.
Actually: If your smoke test has 30 steps, it's not a smoke test. Pick 5–10 important things. Save detail for later.
🚫 Testing the same thing on every page
I used to think: I should check the footer on every page.
Actually: Smoke tests check core functions once each. Focus on different features, not the same one in 20 places.
🚫 Not rejecting failing builds
I used to think: I can keep testing around the broken part.
Actually: If login is broken, stop. Every test after that might be invalid. Reject the build immediately.
🚫 Testing an unstable or incomplete build
I used to think: I should smoke test builds as soon as they're available.
Actually: If the build is broken at the core level (won't deploy, database offline, missing critical files), smoke tests will all fail but won't tell you anything useful. Wait until the build is stable enough to navigate. Smoke testing on a broken build wastes time.
When this technique fails
Smoke testing fails when you run it on an incomplete or unstable build. If core deployment or database connectivity is broken, every test will fail, producing noise instead of signal. Also fails if you test too deeply; a 30-step "smoke test" is not a smoke test—it's a full regression test. Smoke testing is only 5-10 critical paths. Anything more means you're testing wrong.
7 Now You Try
Scenario: You are testing an online booking site for a Christchurch adventure park. A new build just arrived. Write a 5-item smoke test checklist.
Suggested checklist:
| # | Test | Why it matters |
|---|---|---|
| 1 | Homepage loads | If this fails, nothing else matters |
| 2 | Booking calendar opens | Core business feature |
| 3 | Add to cart works | Users must select items |
| 4 | Checkout page loads | The business takes money here |
| 5 | Contact page opens | Users need help |
Tip: Your list might differ. The key is: if any fail, you stop.
8 Self-Check
Click each question to reveal the answer.
Q1. How long should a smoke test take?
About 5 minutes. It is a quick health check, not a full exam.
Q2. A smoke test fails on the login page. What do you do?
Stop and reject the build. If users can't log in, other tests may be invalid.
Q3. Should smoke tests check spelling mistakes?
No. Spelling is a detail. Smoke tests only check if core features turn on.