Smoke testing
Smoke testing is a quick pass over a build's most important paths to decide whether it is worth testing further. It is a go or no-go check, not a thorough one: if the smoke test fails, the build is rejected before anyone spends time on deeper testing.
The longer version
The name comes from hardware, where powering on a new board and watching for smoke told you whether to continue. The software version answers the same question. A build that cannot load its home page, sign a user in, or complete its central action does not need a full regression suite run against it; it needs to go back.
A smoke test is defined by what it leaves out. It covers the handful of paths that would make every other test meaningless if broken, and it is short enough to run on every build without anyone weighing whether it is worth it. Teams usually keep it to a few minutes. Once it takes long enough that somebody considers skipping it, it has stopped being a smoke test.
It is often confused with sanity testing. The distinction most teams use: a smoke test is broad and shallow, run against a whole new build to check it is stable enough to test; a sanity test is narrow and targeted, run after a specific change to check that one area behaves. The line between them is not universally agreed, and the difference matters less than having both habits.
In a continuous integration pipeline the smoke test is usually the first automated stage after the build, and its failure stops the pipeline. That placement is the whole value: it converts a broken build from something a tester discovers an hour in to something the pipeline rejects in minutes.
Common questions
What is the difference between smoke testing and regression testing?
A smoke test checks whether a build is stable enough to be worth testing, covering a few critical paths in a few minutes. Regression testing checks that previously working behaviour has not broken, and it is broad and slow by design. The smoke test runs first and decides whether the regression run happens at all.
Should smoke tests be automated?
Almost always. A smoke test runs on every build, and anything that runs that often and must never be skipped belongs in the pipeline rather than in someone's routine. Its short runtime is what makes automating it cheap.
How long should a smoke test take?
Short enough that nobody is tempted to skip it, which in practice means minutes rather than tens of minutes. If it grows past that, the usual cause is that deeper checks have drifted into it and belong in the regression suite instead.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.