Smoke testing
The name comes from hardware testing, where powering on a new circuit and checking it doesn't literally start smoking is the first, most basic check before anything more detailed. Software borrowed the idea: before a team spends real time on a full regression pass, they run a short set of checks against the handful of things that absolutely have to work, does the app start, can a user log in, does the main page load, does one core transaction go through end to end.
Smoke testing is deliberately shallow. It isn't trying to catch a subtle bug in an edge case, it's trying to catch the build that's fundamentally broken, a failed deployment, a missing dependency, a database connection that never got configured. Those failures make every other test pointless, so finding them in minutes instead of after a full suite has already run is the entire point.
That makes smoke testing a natural gatekeeper. Many teams run it as the very first stage of a CI/CD pipeline, right after a build succeeds, and only trigger a slower, fuller suite, like a full regression pass, once the smoke test comes back clean. A failed smoke test usually stops the pipeline there, since running everything else against a build that can't even start wastes time nobody wants to spend.
What a smoke test typically checks
- The application starts or deploys successfully, without crashing on launch.
- A user can log in and reach the main screen or dashboard.
- Core navigation works, the main pages load without errors.
- One critical transaction, like adding an item to a cart, completes end to end.
- Key integrations, like a database or a required external API, respond at all.
Where it shows up
- As the first stage of a CI/CD pipeline, gating whether slower test suites even run.
- Right after a new build or deployment to a staging or test environment.
- Before a QA team starts a longer manual testing pass, to avoid wasting it on a broken build.
- After a hotfix, to confirm the fix didn't break something as basic as the app starting.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| Catches a badly broken build in minutes, instead of after a full suite already burned an hour on it. | Covers so little that a passing smoke test says almost nothing about whether the details are actually right. |
| Cheap to run on every single build, since it only touches a handful of critical paths. | Deciding what counts as critical enough to include takes real judgment, leave out the wrong path and a broken build sails through. |
| Gives a fast go or no-go signal that gates whether a slower suite is even worth starting. | A green smoke test can create false confidence if a team starts treating it as more than a check on the basics. |
Frequently asked questions
What's the difference between smoke testing and sanity testing?
Smoke testing is broad and shallow, checking that a handful of critical paths work at all right after a new build. Sanity testing is narrower and deeper, usually run after a specific bug fix or small change to confirm that one area still works as expected, without retesting the whole application.
Is smoke testing manual or automated?
Either, though automated is far more common today. A smoke test often runs on every build, sometimes many times a day, so automating it is usually the only way to keep it from turning into a bottleneck. Manual smoke testing still shows up on teams without the infrastructure to automate it yet.
Where does smoke testing sit in a CI/CD pipeline?
It typically runs as one of the earliest stages, right after a build succeeds and before slower suites, like a full regression pass, get triggered. A failed smoke test usually stops the pipeline there, since running the rest of the suite against a badly broken build wastes time everyone would rather spend elsewhere.
How Klarent helps
Klarent's AI agents can run a smoke test as the first stage of a CI/CD pipeline, checking an application's core paths within minutes of a new build and only kicking off a full regression pass once that basic check comes back clean.