A new build lands and the first question is simple: is it even worth testing? Smoke testing answers it. It runs a handful of checks on the most important features, and if any fail, the build is rejected before anyone spends time on deeper testing. The name comes from hardware: power it on and see if it smokes.
What is smoke testing?#
Smoke testing is a shallow, wide check that a build's critical paths work. It confirms the app starts, the main features respond, and nothing core is obviously broken. It is also called build verification testing, because its job is to decide whether a build is stable enough to test further.
What it catches#
Smoke tests catch show-stoppers: the app won't boot, login is down, the homepage 500s, the database won't connect. These are the failures that make every other test pointless, so you want to find them in seconds, not after a full suite has run.
Smoke vs sanity vs regression#
These three get mixed up constantly. The difference is depth and scope.
| Type | Scope | Depth | Question it answers |
|---|---|---|---|
| Smoke | Wide, all critical paths | Shallow | Is this build stable enough to test? |
| Sanity | Narrow, one area just changed | Focused | Did this specific change work? |
| Regression | Wide, existing functionality | Deep | Did this change break anything else? |
Smoke runs first and fast. Sanity is a quick targeted check after a small change. Regression is the deep, full safety net covered in the regression testing guide.
What goes in a smoke test#
Only the critical paths: app loads, user can log in, core action works (checkout, search, create), key API responds. Keep it small, a few minutes at most. The moment a smoke test grows deep, it stops being a smoke test.
When to run it#
Run it on every new build, before any deeper testing. In practice that means on each deploy to a test environment and as the first gate in CI, so a broken build fails immediately instead of wasting the rest of the pipeline.
Manual vs automated#
Smoke testing is run constantly on every build, so automation is the obvious fit. An automated smoke suite in CI gives a pass or fail in minutes with no human effort. Manual smoke checks make sense only for early or one-off builds before the automation exists.
Where automation fits#
The cost of an automated smoke suite is keeping its selectors working as the UI changes. ObserveOne's Autopilot generates Playwright checks for your critical paths and self-heals them when the app shifts, so your smoke gate stays green for the right reasons instead of breaking on every redesign.
The short version#
Smoke testing is a fast, shallow check that a build's core features work, run first to decide whether deeper testing is worth it. It is wider but shallower than regression, and broader than a focused sanity check. Keep it small, automate it, and make it the first gate in CI. For the full picture, see software testing strategies.