A smoke test is a small, fast set of checks that confirms a new build is stable enough for further testing or release. In software testing, it answers one blunt question: does the application start, and do its most critical paths work at all? If the answer is no, the build is rejected immediately, and nobody wastes hours running a full test suite or deploying it to users.
The practice, also called smoke testing or build verification testing, is deliberately broad and shallow. It touches many parts of the system with one or two checks each, rather than examining any single feature in detail, and it typically finishes in seconds to a few minutes.
What a smoke test checks
A smoke test targets the minimum conditions for a usable build. The exact list depends on the product, but most suites check that the artifact deploys, the process starts, configuration loads and the few user journeys that justify the product’s existence respond correctly. A web shop, for example, must show the home page, return search results, add an item to the cart and reach the payment step.
- Startup: the service boots without fatal errors and reports healthy on its health endpoint.
- Connectivity: the database, message queue, cache and key external services are reachable.
- Authentication: a test account can sign in and receive a valid session or token.
- Critical paths: one representative call for each core feature returns the expected status.
- Static assets: pages load their scripts and styles without missing files.
Smoke tests deliberately avoid edge cases, detailed data validation and performance measurement. Those belong to other levels of the test pyramid. Keeping the scope tight is what makes the suite fast and trustworthy as a go or no-go gate.
Where smoke tests run in a delivery pipeline
Smoke tests appear at several points in continuous integration and delivery, each time protecting a more expensive step that follows. The table below shows typical placements and what each run protects.
| Pipeline stage | What is verified | What it protects |
|---|---|---|
| After the build | Artifact starts and core modules load | Time spent on full regression testing |
| After deployment to staging | Environment wiring and configuration | QA effort on a broken environment |
| After production deployment | Live service answers critical requests | Users from a failed release |
| During canary release | New version handles a small traffic slice | The rest of the user base |
| Scheduled in production | Ongoing availability of key journeys | Undetected outages between releases |
In production, a failing post-deployment smoke test should trigger an automatic rollback or at least stop a progressive rollout. This only works if the suite is reliable: a test that fails randomly will either be ignored or will block valid releases, and both outcomes erode trust in the pipeline.
Smoke tests compared with other test types
The smoke test is often confused with sanity testing and regression testing, and its boundaries with end-to-end tests are not always obvious. The comparison below clarifies how scope, depth and timing differ.
| Test type | Scope | Depth | Typical duration |
|---|---|---|---|
| Smoke test | Whole system, critical paths | Shallow | Seconds to minutes |
| Sanity test | One changed area | Narrow but focused | Minutes |
| Regression testing | Previously working features | Deep | Minutes to hours |
| End-to-end test | Complete user workflows | Deep | Minutes to hours |
| Unit test | Single function or class | Deep in isolation | Milliseconds each |
| Acceptance test | Business requirements | Requirement-driven | Varies widely |
A useful rule is that smoke tests ask whether the build works at all, sanity tests ask whether a specific fix works, and regression testing asks whether anything that used to work has broken. Smoke tests are often implemented as a tagged subset of existing end-to-end or integration tests, which avoids maintaining a separate code base.
Designing an effective smoke test suite
A good smoke suite is fast, deterministic and focused on business-critical behavior. Teams commonly aim for a runtime of under five to ten minutes, and many keep post-deployment checks below one minute so a rollback decision can be made quickly.
| Decision | Recommended choice | Reason |
|---|---|---|
| Number of checks | About 10 to 50 for most services | Wide coverage without long runtime |
| Test data | Dedicated, pre-seeded accounts | Repeatable results without side effects |
| Failure policy | Any failure blocks the build | Keeps the gate meaningful |
| Retries | None, or one for network calls | Hides real defects if overused |
| Ownership | The team that owns the service | Tests evolve with the product |
Checks should assert real outcomes, not merely an HTTP 200 status. A search endpoint that returns 200 with an empty result list may still be broken. In production, smoke tests that create data, such as test orders, must be clearly marked and cleaned up so they never affect reporting, billing or stock levels.
Limitations and common mistakes
The main limitation is built into the definition: a passing smoke test proves only that the build is not obviously broken. It says nothing about correctness in edge cases, security or performance under load, which need dedicated suites such as load testing and security scanning.
- Scope creep: adding detailed checks until the suite takes 40 minutes and no longer serves as a quick gate.
- Flaky tests: timing-dependent checks that fail randomly and train teams to rerun instead of investigate.
- Shallow assertions: checking only that pages load without verifying any content.
- Environment drift: smoke tests that pass in staging but rely on settings absent in production.
- False confidence: treating a green smoke run as proof that a release is ready.
In simple terms
The name comes from hardware: when engineers switched on a new circuit board for the first time, the first test was simply whether smoke came out of it. If it did, there was no point checking anything else.
In software, a smoke test is the same quick first look. Before anyone spends hours testing a new version in detail, a short automatic check makes sure it switches on and its most important functions respond. If even that fails, the version goes straight back to the developers.
A practical example
An online ticket seller deploys its booking service about fifteen times a week. After every production deployment, the pipeline runs a smoke suite of 22 automated checks that takes roughly 90 seconds: the health endpoint, sign-in with a dedicated test account, an event search, seat availability for a fixed test event, adding a ticket to the cart and reaching the payment page without paying.
One afternoon, a configuration change points the new release at an outdated database replica. The service starts and its health endpoint reports healthy, but the seat availability check returns no seats for an event that should have hundreds. The smoke suite fails, the pipeline rolls back automatically within three minutes, and customers see no disruption. The team then adds a configuration check to the build so the same mistake is caught even earlier.