Smoke testing: does the build even power on?

A smoke test answers a single question before any other: does the build power on? If it boots, if you open the app and the core features respond without crashing, the build has earned real testing. If not, you reject it right there and spare the team hours spent testing something that was dead from the start.

The name comes from electronics, not software. When you assembled a new circuit, you plugged it in and watched for smoke. If smoke appeared, there was no point reaching for the multimeter: the device was fried. That same idea (a crude, lightning fast check to decide whether it is worth continuing) is what we call smoke testing today.

01 · the gateWhat a smoke test is and what it is not

A smoke test is a small set of checks that verify the most critical features of a build work at a basic level. It is not after depth: it is after shallow breadth. It touches the essentials (does the application start?, does the main screen load?, can you log in?, does the core flow respond?) and stops there.

The ISTQB defines it as a subset of all defined test cases that covers the main functionality of a component or system, meant to confirm that crucial functions work without bothering with fine detail [1]. That is the point: it is an entry gate, not a full inspection.

A smoke test does not say "this works well". It says "this deserves to be tested seriously".

What a smoke test is not: it is not a regression suite, it does not validate business rules in depth, it does not cover edge cases or odd paths. If you try to cram all of that in, it stops being a smoke test and loses its only virtue, which is speed. A smoke test that takes forty minutes has already failed as a smoke test.

02 · the confusionSmoke and sanity are not the same thing

Almost everyone mixes up smoke testing with sanity testing, and it is easy to see why: both are quick, shallow checks. But they answer different questions and arrive at different moments.

The smoke test looks at breadth: it touches the main features across the whole build, freshly arrived, to decide whether it is stable enough to test. The sanity test looks at narrow depth: once a fix or a small change has landed, it checks that that specific area behaves reasonably before you invest in a full regression. The ISTQB describes the sanity test as the run that determines whether a part of the system still works reasonably after a minor change [1].

One way to remember it: smoke asks "is the whole build alive?"; sanity asks "does this one patch make sense?". Smoke usually runs on every build; sanity runs on builds that were already stable and had something specific touched.

03 · the pipelineWhere the smoke test fits in your flow

The smoke test shines in continuous integration. Every time a build is produced (by a merge, by a deploy to a test environment), an automated smoke test runs first and decides in minutes whether the build is still alive. If it fails, the pipeline stops, raises a flag, and no one else wastes time on that version.

Order matters for economy: the cheapest, fastest tests go first. Running an hours long full suite on a build that barely compiles is throwing away resources. The smoke test is the low cost filter that protects the expensive tests that come after it. This idea of tiering (many cheap checks at the bottom, few expensive ones at the top) is the logic of the test pyramid described by Cohn [2], and the smoke test is the first gate on that climb.

A good smoke test has three properties: it is fast (seconds or a few minutes), it is stable (if it fails, it is because the build failed, not because the test is flaky) and it is automated (it runs on its own, on every build, without anyone remembering to). A manual smoke test that someone runs "when they remember" loses almost all its value as a gate.

To position this in your process you need nothing exotic: five or ten cases covering the paths that hurt most when they break are enough. Start up, authenticate, load the main data, complete the core action. If those four are breathing, the build is alive and you can unleash the real suite. If one falls over, you already know there is no point continuing: there is smoke, and the work goes back to development.

Five minutes of smoke buy hours of testing you do not waste.

Smoke testing is neither glamorous nor deep, and that is exactly its charm. It is the cheapest question you can ask a build, and the answer that saves you the most time. Before you test in depth, check that it powers on.