tldr: A smoke test is a fast, shallow check that a build's most important paths work at all. If the smoke test fails, the build is rejected on the spot, before anyone spends time on deeper testing. The name comes from hardware: power the board on and see if it smokes.
Every build you ship starts with one question. Is this thing even worth testing further, or is it dead on arrival? A smoke test answers that question in minutes.
It does not try to be thorough. It touches the handful of flows that have to work for the software to be usable at all: can a user log in, does the main page load, does a core action complete. If any of those fail, the build goes back. There is no point running a two-hour regression suite against a build where login is broken.
Smoke testing has been part of QA for decades, but the reason it matters in 2026 is new. Teams ship far more often, and a lot of the code is now written by AI. That means more builds, more frequently, each carrying changes nobody typed by hand. A fast gate that rejects broken builds early is worth more when builds arrive every hour than when they arrived every sprint.
This guide covers what a smoke test is, how it differs from the term people confuse it with, what one actually looks like, and when to run it by hand versus automate it.
What is smoke testing?
Smoke testing is a shallow, wide check across the critical functions of a build to confirm it is stable enough for further testing. "Shallow" means it does not verify a feature in depth. "Wide" means it touches many features, one level deep each.
Think of it as a pass or fail gate, not a grade. A smoke test does not tell you the checkout flow handles every currency correctly. It tells you the checkout page loads and a basic purchase completes. That is enough to decide whether the build proceeds.
Smoke tests are sometimes called build verification tests, because that is their job. They verify a build is worth the team's attention before the team gives it any.
Smoke testing vs sanity testing
These two get mixed up constantly, and the difference is simple once you anchor it.
Smoke testing runs against a new build to confirm the whole thing is stable enough to test. It is broad and shallow, and it usually runs first, often automated.
Sanity testing runs against a build that already passed smoke, after a specific change or bug fix, to confirm that one area works as expected. It is narrow and slightly deeper, and it is usually more focused and often manual.
| Smoke testing | Sanity testing | |
|---|---|---|
| Goal | Is the build stable enough to test? | Does this specific change work? |
| Scope | Broad, shallow, many flows | Narrow, focused, one area |
| When | On every new build, first | After a fix or a small change |
| Typically | Automated | Manual or targeted |
If you remember one thing: smoke asks "should we test this build at all," sanity asks "did this particular fix land."
Smoke testing examples
Concrete beats abstract. A smoke test suite for a typical SaaS web app looks like this:
- A user can load the sign-in page and log in with valid credentials.
- The dashboard renders after login without an error.
- The primary create action works, for example creating a new project or record.
- Navigation to the three or four main sections loads each page.
- A core integration responds, for example the app can reach its API and return data.
That is the whole suite. Five to ten checks, each one level deep. Notice what is missing. No edge cases. No validation of error messages. No testing of the password reset flow's every branch. Those belong in regression, which only runs if smoke passes.
For an e-commerce build, the smoke set would be: homepage loads, search returns results, a product page opens, add-to-cart works, and checkout reaches the payment step. If any of those five break, the build is not ready, and you know in minutes.
When to run a smoke test
Run a smoke test at every point where a new build enters a new stage.
The most common trigger is a fresh build landing in a test or staging environment. Before that build gets a full regression run, smoke it. If it fails, it never reaches the slower suite, and you save the time that suite would have burned on a broken build.
The second trigger is a deploy. Running a smoke test against production right after a release confirms the deploy itself did not break a critical path. Configuration, environment variables, and infrastructure differ between staging and production, and a build that passed everything in staging can still fail on the first request in production.
The third trigger is a pull request. In teams that ship continuously, a smoke test on every PR is the gate that keeps a broken change out of the main branch. This is where automation stops being optional.
Manual vs automated smoke tests
You can run a smoke test by hand. Someone opens the build, logs in, clicks through the main flows, and gives a thumbs up. For a team that ships once a week, that is fine.
It stops working the moment you ship daily. A manual smoke test that takes twenty minutes and has to run on every build and every deploy becomes a full-time interruption. Worse, it gets skipped under pressure, which is exactly when broken builds slip through.
Automated smoke tests solve this. They run in minutes, on every build, without a person. The tradeoff has always been maintenance: hardcoded smoke tests break when the UI changes, and a smoke suite that cries wolf gets ignored.
This is the problem Bug0 removes. A forward-deployed engineer authors your smoke suite on Passmark, our AI testing engine, and the engine runs it on every build and deploy and re-resolves the steps when your UI shifts, so the suite keeps passing for the right reasons instead of flaking. You get the fast gate without owning the upkeep.
Smoke testing is the cheapest quality check you have. It catches the most expensive kind of waste, which is a whole team testing a build that was never going to work.
FAQs
What is smoke testing in software?
It is a shallow, broad check that a new build's critical functions work, run before any deeper testing. If it passes, the build proceeds to regression. If it fails, the build is rejected immediately. It is also called build verification testing.
What is the difference between smoke testing and sanity testing?
Smoke testing runs first, against a new build, to confirm the whole build is stable enough to test. Sanity testing runs later, against a build that already passed smoke, to confirm one specific change or fix works. Smoke is broad and shallow; sanity is narrow and focused.
What is the difference between smoke testing and regression testing?
Smoke testing is a quick gate that checks a few critical paths to decide if a build is worth testing. Regression testing is the deep, thorough suite that runs only after smoke passes, checking that existing features still work across many scenarios.
Is smoke testing manual or automated?
It can be either. Manual smoke testing works for teams that ship infrequently. Automated smoke testing is necessary once you ship daily, because it has to run on every build and deploy without a person and without slowing anyone down.
Who performs smoke testing?
In traditional teams, a QA engineer or a developer runs it. In teams that automate, it runs itself on every build and pull request. With a managed service like Bug0, a forward-deployed engineer builds and maintains the smoke suite and the engine runs it automatically.
How many test cases should a smoke suite have?
Few. A smoke suite usually has five to fifteen checks, each touching one critical flow at one level of depth. If it grows large enough to take more than a few minutes, it has stopped being a smoke test and started becoming a regression suite.
