04 Nov 2026 Smoke testing: the quick check that tells you a build is worth testing

In short: Smoke testing is a short set of checks on your most critical functions, run right after a build or a deploy. It tells you within minutes whether the software starts, responds and can do its main jobs. If the smoke test fails, deeper testing can wait. Automate it, keep it small and run it in every environment.

Few things waste a tester’s morning like this. A new build lands in the test environment, the regression run starts, and two hours later every test is red. The cause was a missing setting that broke the login. A two-minute check would have caught it before anyone started. That two-minute check is a smoke test. It’s one of the cheapest tests you can have, and one of the most neglected.

What is smoke testing?

Smoke testing is a quick, shallow check that the most important parts of your software work at all. It runs right after a new build or a deploy, before anyone spends time on deeper tests. The name comes from hardware: switch a new device on, and if smoke comes out, you don’t need to test further. In software, the smoke is a login that fails, a page that won’t load or a payment service that doesn’t answer. The ISTQB glossary describes it as a subset of tests that covers the main functions, to decide whether further testing makes sense. It’s also called a build verification test. A smoke test doesn’t look for subtle bugs. It answers one question: is this build worth testing, or is this release safe to keep? Because it has to answer that fast, it stays small, usually something that runs in minutes.

The Google SRE book describes smoke tests in the same spirit: simple checks on critical behaviour that stop a broken build early.

What is the difference between smoke, sanity and regression testing?

Each answers a different question, at a different depth. A smoke test checks whether the whole build is alive. A sanity test checks whether one specific change or fix works, after a smoke test has passed. A regression test checks that everything that worked before still works. The terms get mixed up a lot, so it helps to agree in your team what you mean by each. This table shows the usual split.

They build on each other. When the smoke test fails, there’s no point starting the others. Our guide to regression testing covers the deepest layer.

What belongs in a smoke test?

Put in the few things your business can’t do without, checked from start to end at a shallow level. Think about what would make you roll back a release within the hour. That list is usually short. For a web shop it might be logging in, searching, adding to the cart and reaching the payment page. For an internal system it might be logging in, opening a record and saving a change. These are the parts most smoke sets need.

• Start and login. The application loads and a test user can sign in.
• The main flows, shallow. Each critical flow gets one quick pass, without every variation.
• The integrations around them. Payment, stock, email and other connected systems answer.
• Key pages and services. The pages and API endpoints most users hit respond without errors.

The integrations are the part that gets forgotten. At clients we often see a new integration tested carefully once, at go-live. After that it never makes it into the regression or sanity tests. So when a later change breaks the connection, nobody notices until a customer does. A quick check through the API, the layer where systems exchange data, catches that in seconds. Our post on API testing shows how.

What stays out matters just as much. No edge cases, no long data checks, no rare settings. Those belong in the regression set. Every test you add makes the smoke test slower, and speed is its whole point.

How do you keep a smoke test useful?

Automate it, run it after every deploy, and never let it fail without a real reason. A smoke test that someone has to start by hand gets skipped when time is short, which is exactly when you need it. Run it in every environment: test, acceptance and production. In production, use test accounts and test orders that don’t touch real customers or real money. Agree on what happens when it fails: the deploy stops, or the release is rolled back.

The biggest risk is a smoke test that fails at random. If it goes red without a real problem a few times, people start to ignore it. Then it protects nothing. Treat a flaky smoke test as an urgent bug, and fix or remove the test that same day. Our post on flaky tests explains the usual causes. DORA’s research on test automation makes the same point: tests are only useful when a failure means a real problem.

Be clear about what a smoke test can’t do. A green result means the build isn’t broken. It doesn’t mean the build is good. Deeper regression tests still need to run. Exploratory testing by people still finds what no script checks. And acceptance testing by your business users still decides whether a change fits how they work.

What this means for your team

Writing a first smoke test takes a day or two. Keeping it right is the ongoing job. Every new feature or integration can change what counts as critical. Logins change, test accounts expire, and a test that was stable starts to fail at random. In many teams nobody owns that work, so the smoke test slowly falls out of date. Then it’s back to finding out two hours into a regression run.

That ongoing work is part of what we do with Test Automation as a Service. Together with your team, we set up smoke checks and a regression set that cover your critical flows and the integrations around them. Your tests run every night, and we keep them reliable. You get a stable test suite your team can trust, one that doesn’t depend on a single person. Your team decides what ships.

A first step for this week: write down the five things that would make you roll back a release within the hour. Then check which of them your team tests automatically after every deploy.

Frequently asked questions

What is the difference between a smoke test and a sanity test?

A smoke test checks whether the whole build works at a basic level. A sanity test checks whether one specific change or fix works. You usually run the smoke test first, then the sanity test.

How long should a smoke test take?

Minutes, not hours. Many teams aim for under ten or fifteen minutes. If it takes longer, it has probably grown into a regression set, and some tests should move out.

Should you run smoke tests in production?

Yes, right after every release. Use test accounts and test orders that don’t touch real customers or money. It’s the fastest way to know whether to keep the release or roll it back.

Who should write the smoke tests?

Testers and developers together, with input from the business on what is critical. Testers know what tends to break, developers know what changed, and the business knows what can’t stop.