Smoke Testing
Smoke testing runs a small, fast set of checks to confirm a build is stable enough for deeper testing or release.
Definition
Smoke testing is a shallow, rapid check of the most critical paths of a build — does the service start, does login work, is the home page reachable — used as a gate before committing to exhaustive testing or deployment. The name comes from hardware: power on, see whether smoke appears. It is breadth over depth, designed to fail fast and cheaply when a build is fundamentally broken, so expensive test suites are not wasted on it.
Context and scope
Immediately after a build or deployment, and as the final gate before promoting an artefact to production.
Common misconceptions
- Smoke testing finds most bugs — it intentionally checks almost nothing deeply; it detects gross breakage, not subtle defects
- It replaces the full suite — smoke tests decide whether to run the full suite, not what it would have found
- It must be exhaustive to be useful — its value is speed; a slow smoke test that duplicates the suite loses its purpose
Anti-patterns
- Making the smoke suite so large it takes as long as the full suite
- Skipping smoke tests after a hotfix, when risk is highest
- Treating a green smoke run as proof the release is correct
Related concepts
Authoritative source
What it is
A smoke test is a short, broad check that a build is fundamentally alive. It starts the service, hits a few critical endpoints, verifies that authentication and the primary user journey respond, and stops. It is deliberately shallow: it does not explore edge cases or verify correctness in depth. Its output is a go or no-go decision about whether the build is worth further attention.
Why it matters
When a build is broken at the foundation — it will not start, a migration failed, a required secret is missing — running the full test suite wastes time and produces noise. A smoke gate catches that in seconds and fails the pipeline early, keeping feedback fast and stopping a doomed artefact from advancing. After deployment, the same check confirms the new version actually serves traffic.
How to use it well
Keep it fast and focused on the paths whose failure means “stop”: process health, database connectivity, the login and one core transaction. Run it immediately after build and again right after deploy, so a bad deployment is caught before traffic fully shifts. Do not let it grow into a second regression suite — if it becomes slow, it has stopped doing its job, and a green smoke run should never be mistaken for a guarantee of quality.