Smoke Test
A smoke test is a short, predefined set of checks run immediately after a deployment to confirm the system is up, connected and minimally functional. Each check has an expected result, an owner and a recorded outcome. It is not a test of correctness; it establishes whether the system is fit to proceed to fuller verification or business validation.
The purpose of a smoke test is speed and coverage of the obvious. It answers one question: is this thing broken in a way that makes everything after it pointless? A failed smoke test stops the sequence early, before hours are spent on validation of a system that cannot log a user in.
What it contains
| Field | What it records |
|---|---|
| Check ID | Reference used in the runbook and in the results record |
| Area | Access, core transaction, interface, batch, reporting, printing, integration with a downstream system |
| Steps | What to do, short enough to be executed without interpretation |
| Expected result | The specific outcome that counts as a pass |
| Owner | The named person running it, often split between technical and business checks |
| Duration | Estimated minutes, because the whole set has a slot in the runbook |
| Evidence | Screenshot, transaction reference or log entry captured as proof |
| Result and time | Pass or fail, and the time it was run |
| Blocking | Whether a failure stops the sequence or is carried as a defect |
A typical set covers login and authorisation for each user role, one core transaction end to end, each critical interface sending and receiving, a batch job starting, and one report producing output. The UAT Template (Excel) holds test cases and a defect log in the same structure, which is where smoke checks are usually drawn from.
How it is used
Smoke tests appear at several points: after each deployment to a test environment, during the dress rehearsal, and inside the cutover runbook as a numbered step immediately after the release. In the runbook they are treated as a gate — the following steps are not started until the results are recorded.
They also serve after go-live, in the first hours and on the first business morning, as a quick confirmation that overnight batch and the interfaces are still behaving. The go-live checklist guide covers where these checks sit alongside the wider verification.
Where it goes wrong
Undefined smoke tests are the usual problem. "Check it works" produces a different check every time and no evidence afterwards. Written checks with expected results are what make a pass mean something.
The second is scope inflation. A smoke test that has grown into a two-hour regression run no longer fits the slot it occupies in the runbook, and gets abbreviated under pressure by whoever is running it. The third is technical checks only: the system responds, the interfaces are connected, and nobody has confirmed a business user can complete an actual transaction. The fourth is running the checks and not recording the results, which leaves the go-live sign-off with nothing to point at.
The fifth is checks that only ever run in one environment. A smoke set built against the test environment often depends on data or configuration that does not exist in production, and the failures on the night are the checks themselves rather than the system. Running the same set during the dress rehearsal, against production-like configuration, is what removes that class of false alarm.
Related terms
See also go-live, cutover runbook and hypercare.
Questions
What is the difference between a smoke test and regression testing?
A smoke test is a short check that the system is minimally functional. Regression testing is a broad confirmation that existing behaviour still works, and takes far longer.
How long should a smoke test take?
Short enough to sit inside the cutover sequence without consuming contingency. The duration is fixed in the runbook, so the set of checks is sized to it.
Who runs the smoke tests at go-live?
Usually both technical and business owners: technical checks for access, interfaces and batch, and business checks for at least one real transaction per critical process.
What happens if a smoke test fails?
It depends on whether the check is marked blocking. A blocking failure stops the sequence and puts the rollback triggers into play; a non-blocking failure is logged as a defect and carried.