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.
Senior engineer insight
The moment that changed how I think about smoke testing was watching a team spend a full afternoon running regression tests on a build where the database connection string had been misconfigured — every single test passed locally but failed in staging, and no one noticed until a product demo. A smoke test that checks end-to-end data flow in the first five minutes would have surfaced it before anyone wasted a day. The real job of a smoke test is not to find bugs: it's to confirm the environment is sane enough for bug-finding to mean anything.
The most common mistake Grad testers make is treating a smoke test as a checklist to complete rather than a gate to enforce — they note the failure, keep testing anyway, and hand results to the team with an asterisk.
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.
From the field
During a go-live for a NZ central government benefits portal, the team assumed the RealMe identity federation had been configured by the infrastructure team during the deployment window. The smoke test was skipped to save time — the environment had "looked fine" in a quick browse. Four hours into UAT sign-off, a Ministry representative attempted to log in and was bounced back to an unconfigured error page. The RealMe redirect URI was pointing at the old staging hostname. Everything else had passed. The go-live was deferred 48 hours while the change request was raised, approved, and deployed through the production change process. The lesson that generalises: third-party auth flows must be in your smoke test on every deployment — they are invisible until they're not, and the blast radius of missing them is maximum.
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.
Why teams fail here
- Smoke tests grow over time — items get added after incidents but never removed, and within six months the "5-minute check" takes 45 minutes, so teams skip it under pressure.
- The smoke test lives in someone's head or an outdated spreadsheet, so when that person is on leave during a deployment the new build goes straight to regression with no gate check.
- Teams run smoke tests against the wrong environment — passing on staging but never verifying the same critical paths once the build promotes to production, which has different config, certificates, or data.
- A smoke test failure is logged as a known issue and testing continues anyway — the gate becomes advisory rather than mandatory, defeating its entire purpose as a build health signal.
Key takeaway
A smoke test is not a test of the software — it is a test of whether the environment is trustworthy enough for your other tests to mean anything.
8 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Smoke Testing at the Grad level.
Q1. What is a smoke test and when do you run one?
Strong answer: A smoke test is a quick, high-level test of the most critical system functions — enough to verify "is this build worth testing further?" It is run after each deployment to staging or production before the full test suite. A smoke test for a login system might be: can a user log in, can they access their account, and can they log out? If the smoke test fails, you stop and report — there is no point running 2 hours of regression tests against a build that cannot do the basics.
Q2. How is a smoke test different from a regression test?
Strong answer: A smoke test checks the critical paths — the minimum viable functionality. A regression test suite checks everything that has ever worked to ensure it still works after a change. Smoke tests are fast (minutes), regression tests are comprehensive (minutes to hours). Smoke tests run first, on every deployment. Regression tests run on a scheduled basis or before releases. If the smoke test fails, regression testing does not start.
Q3. You are the only tester on a project and you have 10 minutes before a release. What do you test?
Strong answer: I run the smoke test — the minimum viable functionality for this release. I identify what changed and test those specific areas first. I test the single most important thing users will do with the new feature. I check that the deployment did not break anything critical by testing the most-used user flow. I document what I tested and what I did not test, so stakeholders know the scope of my sign-off. A conscious, documented partial test is better than an implicit assumption of full coverage.
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.