Book 10 · Testing & QualityPage 24 of 36

Smoke Test

Updated September 30, 20262 min read

In short

A smoke test is a quick, shallow check that the most important features of a build work at all, run before any time is spent on deeper testing.

What is a smoke test?

A smoke test is a small set of fast checks that confirms a new build or deployment basically works. It asks broad questions, such as whether the app starts, the home page loads, and a user can log in, without testing the details. If a smoke test fails, the build is treated as broken, and there is no point running the slower, more thorough test suites.

The name comes from hardware testing: when engineers powered on a new circuit board for the first time, the first check was whether it started to smoke. In software, smoke tests usually run right after a build in a CI/CD pipeline, or right after a deployment to a staging or production environment. They typically hit a few critical pages or endpoints and check for a successful response, and they should finish in seconds or a few minutes so they can run on every change.

Think of it like turning the key in a car you just repaired: if the engine won't start, you don't bother checking the radio. Teams use smoke tests as a gate before running a full regression suite, and as a post-deployment check that can trigger an automatic rollback when a release is clearly broken.

Smoke testing is often confused with sanity testing and regression testing. A smoke test checks that the whole build is stable enough to test at all, a sanity test is a narrow check that one specific fix or change works, and a regression suite checks in depth that existing features still behave correctly. In short, smoke tests are wide and shallow, while regression suites are wide and deep.

Key takeaways

A smoke test is a fast, shallow check that the critical parts of a build work.
A failed smoke test means the build is broken, so deeper testing is skipped.
Smoke tests commonly run after each build and after each deployment.
They should be few, fast, and focused on the most important user paths.
Smoke tests don't replace a full regression suite.

Example

A post-deployment smoke test in bashbash

#!/usr/bin/env bash
# Stop at the first failed check
set -euo pipefail
BASE_URL="https://staging.example.com"

# 1. The health check endpoint responds successfully
curl --fail --silent "$BASE_URL/health" > /dev/null

# 2. The home page loads and contains a page title
curl --fail --silent "$BASE_URL/" | grep -q "<title>"

echo "Smoke test passed"

Readers ask

What is the difference between smoke testing and sanity testing?

Smoke testing checks that a whole build is stable enough to test by broadly exercising its most important features. Sanity testing is a narrow, focused check that a specific bug fix or small change works, usually on a build that already passed its smoke tests.

Why is it called a smoke test?

The term comes from hardware and plumbing: you power on a new device, or push smoke through new pipes, and look for smoke where it shouldn't be. If you see it, something is fundamentally wrong and further testing can wait.

Should smoke tests run in production?

Many teams run a small set of smoke tests right after each production deployment to confirm the release works. These tests should avoid changing real data, for example by only reading pages or by using dedicated test accounts.