Smoke Testing — Closing the PM and Developer Gap on ‘Did You Test?
On small teams with no dedicated QA, the question ‘Did you test it?’ lands sideways more often than it should. A one-page guide to smoke testing — the definition, the origin, the pipeline, and the e-commerce example — so PMs and developers can stop arguing past each other.
"Did You Test It?" — Why One Question Lands Sideways
On small teams without dedicated QA, the PM usually ends up running the test pass too — and that's exactly where the term smoke testing quietly becomes a source of friction. The scene is familiar. The build comes in, the PM walks through the spec scenario by scenario, and defects pile up fast. "Did you test it?" slips out, and the developer's face shifts. They sound genuinely wounded: "I tested it a lot."
Most of the heat in that exchange comes from one thing. The word "test" means different things on each side of the table. The developer has been running smoke testing on every commit. The PM is thinking about scenario-grade verification with a defect table. Both are right, neither is talking about the same artifact. This post is a one-page guide to smoke testing — the unglamorous gate that sits between those two definitions.
What Smoke Testing Actually Means — The First Pass/Fail Gate
One line, then we dig in. Smoke testing is the first pass/fail gate run right after a build, confirming that the core features of a service at least start up and respond. Right after the build completes, you boot the system and ask: "Is anything on fire? Any smoke?" If yes, no point running the detailed suite — kick it back.
What matters here is the goal. Smoke testing is not trying to catch all the bugs. It's the bouncer at the door. Pass and you've earned the right to be checked properly. The scope stays small on purpose, and the result is binary: pass or fail.
Where the Word Came From — Boards, Solder, and Actual Smoke
The term started in hardware. After freshly soldering a circuit board, engineers would flip the power on and watch for smoke. If a wisp came up, the board failed — no need to check anything else. Software borrowed the metaphor cleanly: "turn it on, see if it bursts into flames." The wording stuck because the intuition is correct. A build that won't even boot doesn't deserve a detailed pass.
The Build Pipeline — Why People Say "Run Smoke"
The code changes constantly during development. Running every feature end-to-end after each commit would take forever. So the flow usually looks like this:
[code lang="text"] [Developer commits code] ↓ [Automated build] ↓ [Smoke test (5–10 min, usually automated)] ↓ ┌────┴────┐ ▼ ▼ [Pass] [Fail] │ │ ▼ ▼ [Detailed [Reject / QA pass] urgent fix] [/code]
Most smoke testing is automated and finishes in five to ten minutes. "Running smoke" doesn't mean a one-time event — it means the gate fires on every push, so any showstopper that breaks the whole system surfaces in real time. When a developer says "I tested it," that automated gate is almost always part of what they're counting.
Smoke Testing on an E-commerce App — What's In, What's Out
An online store makes the line easy to draw. Same word "test," very different scope on each side.
| Aspect | Smoke testing | Detailed QA |
|---|---|---|
| What it covers | Core flows that, if broken, take the service down | Edge cases — service still runs even if they're off |
| Run by | Usually automated (5–10 min) | A person walking the spec scenario by scenario |
| Result | Pass / Fail, binary | Defect counts, repro rates, expected vs actual |
In Scope — Core Flows That Break the Service
- Does the app launch?
- Can a user log in or sign up?
- Does the product detail page open?
- Do "add to cart" and "checkout" work?
If any of these is broken, there's no point running anything else. Smoke testing exists to catch exactly this class of failure before a human spends an hour writing up a defect report on it.
Out of Scope — Detailed QA Territory
- Does the "orders from 3 years ago" filter on My Page work correctly?
- Is the percentage math right on a specific card-issuer instant-discount coupon?
- Does a specific icon switch color correctly in dark mode?
- Do push notifications render cleanly across iOS and Android wording quirks?
These need a human walking through scenarios with a defect table. When a PM uses the word "test," this is usually the picture in their head.
How PMs and Developers Agree on the Word "Test"
Two people using one word to mean different things is a familiar pattern. It shows up between seniors and new hires too. A previous post on delegating to new hires covered how the same verb lands differently depending on where you sit. The word "test" works the same way.
The fastest fix on a team is splitting the word into two layers and using both:
- "Smoke passed." The build came up and the core flows didn't fall over. The developer's first-pass gate.
- "Detailed QA done." Someone walked the spec scenarios and filled out a defect table. The PM-or-QA second-pass gate.
Once those two phrases are in rotation, "Did you test it?" gets a useful answer: "Smoke passed, detailed QA not yet." One more thing — if the smoke gate falls over, the primary path is down, and detailed QA on top of that is wasted effort. The same independence-of-paths idea from the fallback design post applies here: smoke testing is the first checkpoint that confirms the primary path is even alive.
One-line Summary
Next time you hear "smoke testing in progress," translate it as "before any detailed verification, we're confirming the skeleton boots and the core flows respond" — that's exactly the part most developers fold into the phrase "I tested it." It's quiet, automated, and easy to miss from outside the codebase.
On the PM side, one small habit pays off. When defects pile up, the first question worth asking is not "did you test it?" but "did smoke pass — and which scenarios did you walk?" Splitting the word into layers gets more information across in the same minute, and stops two people who agree about the goal from arguing about the vocabulary. Smoke testing isn't really one technical term — it's the shared word a team agrees on so both sides see the same picture.