What is Smoke Testing?

What is Smoke Testing?

Smoke testing is a fast, shallow set of checks that runs against a fresh build to confirm the system is stable enough to deserve deeper testing. It exercises only the most critical paths, such as whether the application starts, whether login works, and whether a core endpoint responds, and it answers a single yes-or-no question: did this build break something so fundamental that no further testing will give useful signal? If the answer is yes, the build is rejected immediately and the rest of the pipeline is skipped, surfacing the regression in seconds rather than after a long full-suite run.

Origin and Meaning of the Term

The name comes from hardware engineering. When an engineer powered on a newly assembled circuit board for the first time, the immediate concern was simple: if smoke came out, the board was defective and there was no point continuing any other test. Software borrowed the metaphor almost unchanged. A smoke test is the first power-on of a build. It does not measure quality, correctness, or completeness. It only confirms that the build is intact enough to be worth the time and cost of the deeper test stages that follow. This is why smoke testing is also called build verification testing (BVT) or build acceptance testing.

What Smoke Testing Covers and What It Does Not

A smoke test deliberately touches breadth, not depth. It walks across the widest, most business-critical paths and confirms each one is alive, without probing the edge cases inside any of them.

• Application start. The process boots without crashing and the health endpoint returns 200.
• Critical user flows. Sign-in, the primary feature path, and checkout on a commerce app all reach a successful state.
• Integration handshake. The app connects to its database, cache, and message queue with no timeout at boot.
• Static asset availability. The main JavaScript bundle and CSS load from the CDN with a 200, not a 404 from a stale hash mismatch.
• Configuration sanity. Required environment variables resolve and there is no undefined in the rendered output.

What a smoke test does not cover: validation errors, every branch of a workflow, boundary values, security assertions, or behavior under load. Those belong to regression testing, functional testing, or a dedicated load test. Overloading a smoke suite with these concerns is the most common way teams accidentally turn a 30-second gate into a slow, flaky mini-regression suite.

When Smoke Testing Runs

Smoke testing runs at the boundaries where a new artifact first meets a real environment. There are four common triggers.

1. On every CI build. It is the first stage of the pipeline. If it fails, the pipeline stops and no downstream stage runs, so a broken build never consumes the full CI budget.
2. Post-deploy to staging or production. It confirms the deploy actually came up before traffic is routed to it. Blue-green and canary rollouts gate the cut-over on a passing smoke test.
3. After infrastructure changes. A new DNS record, TLS certificate, or database failover target can break integration even when the application code is untouched. Smoke verifies the path end to end.
4. Before a load test. There is no value in running a 30-minute load test against a build whose login is already broken. Smoke first, load second.

Smoke Testing vs Sanity Testing

Smoke and sanity testing are often confused because both are quick and both gate deeper work. The difference is scope and intent. Smoke testing is wide and shallow: it touches many critical features once each to confirm the whole build is stable. Sanity testing is narrow and slightly deeper: after a small change or bug fix, it checks that one specific area now behaves correctly, without re-verifying the entire system. Smoke testing is usually scripted and runs on every build; sanity testing is often a targeted, sometimes manual, check performed on a specific release candidate.

Smoke Testing vs Regression Testing

Regression testing answers a different question than smoke testing: not "is the build runnable at all?" but "did this change break anything that used to work?" Regression suites are broad and deep, cover many features and edge cases, and take minutes to hours. Smoke is the fast gate that runs first; regression is the thorough pass that runs only after smoke confirms the build is worth the effort. Skipping smoke means a broken deploy slips straight into the regression suite and burns the entire CI budget before the failure is even reported. The table below places all three practices side by side.

Dimension	Smoke Testing	Sanity Testing	Regression Testing
Question answered	Is the build runnable at all?	Does this specific fix work?	Did this change break anything that worked before?
Scope	Wide, all critical paths	Narrow, one changed area	Wide and deep, many features
Depth	Shallow, one pass each	Focused, moderate depth	Deep, edge cases included
Typical duration	Seconds to a couple of minutes	Minutes	Minutes to hours
Automation	Almost always scripted	Often manual or targeted	Usually fully automated
When it runs	First, on every build	After a specific change	After smoke passes

Manual vs Automated Smoke Tests

Early in a project, a manual smoke test can be a short written checklist that a developer walks through by hand: open the app, log in, load the main screen, place one order. This is cheap to start and needs no tooling, but it does not scale and it cannot gate an automated pipeline. As soon as the build runs in CI, the smoke suite should be automated so it can block a deploy without a human in the loop. Automated smoke tests are code: a handful of HTTP requests with status and body assertions for services, or a short browser script for user-facing flows. The rule of thumb is that anything you would check by hand on every single release is a candidate for an automated smoke test.

How to Design a Smoke Test Suite

A good smoke suite is small, fast, deterministic, and build-blocking. Keep these principles in mind.

• Cover breadth, not depth. Pick the five to fifteen paths whose failure would make the whole release worthless, and check each one exactly once.
• Stay fast. Target seconds, not minutes. If the suite creeps past a few minutes it has become a regression suite and stops being run first.
• Be deterministic. Flaky smoke tests destroy trust in the pipeline. Remove timing dependencies and retry only on genuinely transient network errors.
• Block the build. A failed smoke test must stop the pipeline. There is no "yellow" smoke status; the answer is pass or fail.
• Keep it cheap to author. A few HTTP checks plus a short browser assertion is enough. Do not over-engineer the gate.

Smoke Testing for APIs and Web Apps

For HTTP services, a short script with 5 to 15 critical-path requests is a solid smoke harness. In a tool like k6 you set one virtual user and one iteration and add check() assertions on status and body; in JMeter you use a Thread Group with one user and one loop and a Response Assertion on every sampler. For browser-side flows, a 60-second script that logs in, lands on the main feature, and asserts on a known element is enough. Crucially, a smoke test that runs on a developer laptop does not prove that the production CDN, DNS, and TLS chain work. Running the same checks from a real cloud region against the public endpoint does. This is where continuous smoke testing and monitoring overlap: an API monitor that hits your critical endpoints on a schedule from the cloud, like the ones you can build in LoadFocus API monitoring, is effectively a smoke test that never stops running, catching a broken deploy or an expired certificate within minutes. Teams that want the gate wired directly into a pipeline can run the same critical-path checks from LoadFocus before promoting a build to a full load test.

Benefits and Limitations

The benefit of smoke testing is early, cheap, high-confidence rejection of broken builds. It fails fast, protects the more expensive test stages from wasted effort, and gives every deploy a clear go or no-go signal. Its limitation is exactly its design: it is shallow by intent, so it will never catch a subtle logic bug, a boundary error, or a slow memory leak. A passing smoke test means "the build is worth testing further," not "the build is correct." Treating a green smoke run as full validation is the single most dangerous misuse of the practice.

Best Practices

• Run it first and everywhere. Make smoke the opening gate of CI and repeat it after every deploy to a new environment.
• Keep it ruthlessly small. Resist the urge to add "just one more" check; a bloated smoke suite gets skipped.
• Test from where users are. Prefer running post-deploy smoke from the cloud against public endpoints, not from a build agent inside your own network.
• Alert loudly on failure. A failed smoke test should page or block, never silently pass a warning downstream.
• Review the suite as the product changes. When a new critical flow ships, add it to smoke; when a path is retired, remove it.

FAQ about Smoke Testing

Is smoke testing the same as build verification testing?

Yes. Build verification testing (BVT) and build acceptance testing are the formal names for the same practice: a quick set of checks that confirms a new build is stable enough to proceed to deeper testing. The term smoke testing is more common in everyday use.

How long should a smoke test take?

Seconds to a couple of minutes at most. The whole point is to fail fast and gate the pipeline. If your smoke suite takes ten minutes, it has drifted into regression territory and should be split, with only the truly critical checks kept as smoke.

Should smoke tests be automated or manual?

Automated wherever a pipeline exists, because a build-blocking gate cannot depend on a human being available. A manual checklist is a fine starting point for a young project, but any check you repeat on every release should become an automated smoke test.

What is the difference between smoke testing and sanity testing?

Smoke testing is wide and shallow and runs on every build to confirm overall stability. Sanity testing is narrow and slightly deeper and runs after a specific change to confirm that one area now works. Smoke asks "is the build alive?"; sanity asks "did this fix land correctly?"

Can smoke tests run against production?

Yes, and they should. Post-deploy smoke tests against staging or production confirm the release actually came up before traffic is routed to it. Running them continuously from the cloud, as a scheduled API monitor does, turns smoke testing into always-on production verification.

Does a passing smoke test mean the software is bug-free?

No. A passing smoke test only means the build is stable enough to justify deeper testing. It is shallow by design and cannot catch edge-case logic errors, boundary bugs, or performance problems. Those require regression, functional, and load testing.