Smoke Testing in Software Testing: A Practical Guide

What smoke testing means in software testing

Smoke testing is a shallow, wide pass over a build's most critical paths, run before deeper testing starts. It answers one question: is this build stable enough to be worth testing? It does not try to prove the release is correct, only that the parts every other test depends on still work.

The name comes from hardware, where a newly assembled board was powered on to see whether anything smoked. Software borrowed the image because the first pass has the same job: find out whether the thing runs at all before spending hours on it. A failed smoke check sends the build back to the developer; it does not become a ticket in the backlog.

The value comes from ordering rather than depth. A broken build found in five minutes costs a rebuild. Found after a full regression run, it costs a day of environment time and several people's attention. That makes smoke testing a queue-management tool as much as a quality check: it protects the expensive work standing behind it.

What a smoke pass should and should not cover

Cover the flows whose failure would make the build unusable. For most web applications that means sign-in, sign-up, the main transaction (checkout, booking, subscribe, submit), the primary create-and-save action, and a surface-level check of whatever this build changed. Ten to twenty checks is usually enough. If the list cannot be finished inside the time budget, it is too long.

The right-hand column is not unimportant; it is expensive. Detailed validation belongs in regression and feature testing, where a longer run is acceptable. A smoke suite that quietly absorbs all of it stops being a gate and becomes a second regression suite with a worse name.

When to run a smoke pass

Treat the smoke check as a gate attached to a build, not a ritual attached to a calendar. Run it whenever a build becomes a candidate for someone else's time.

• Before QA picks up a build. This is the classic build acceptance test: if sign-in or checkout is broken, the testing slot should go back to the team that owns the build, not to a tester who will spend an hour confirming it.
• Before deploying to staging or production. The build that passes smoke is the artifact that ships. Rebuilding afterward invalidates the result.
• After a hotfix. Hotfixes are written under time pressure against a narrow change, which is exactly when adjacent flows break. A five-minute pass is cheaper than a rollback.
• After configuration or infrastructure changes. Environment variables, feature flags, DNS, certificates, secret rotation, and third-party keys can break a working application without a single line of code changing.
• After a dependency upgrade or a data migration. A library bump or a restored database can change behavior everywhere at once, so the money flows deserve a fresh pass.
• After the deployment itself. A narrow production check — sign in, complete one transaction, load one read path — confirms that the artifact that shipped is the artifact that passed.

One caution: a suite that runs every morning regardless of deploys is a monitoring habit, not a release gate. If the team deploys three times a day, the check has to run three times a day, and yesterday's green badge should never be cited in today's release decision.

How to run a smoke pass in 15 minutes

1. Freeze the list. Each check gets a name, a starting state, and one expected result that a newcomer could verify without asking. "Checkout works" is not a check; "a card payment for one item reaches the order-confirmation page with the same total" is.
2. Make the data resettable. Seed accounts, test cards, sandbox credentials, and an inbox the run can consume and recreate. If a pass burns the only test account, the next pass starts with an investigation.
3. Order by risk, not by screen. Money flows first, then the areas this build touched, then navigation. If the run has to be abandoned halfway, the most expensive failures have already surfaced.
4. Record three states, not two. Pass, fail, and blocked are different outcomes. A check that could not run because the environment was down is not a pass, and collapsing it into one hides the build's real condition.
5. Stop on the first critical failure. Triage immediately: broken build, broken environment, or bad test? Fix the cause and restart from the beginning of the list, because a partial pass proves less than no pass.
6. Publish the result where the release decision happens. A build comment, a channel post, or a checklist entry should record the build, the environment, the time, and the outcome. A result that lives only in someone's memory cannot be audited later.

Entry and exit criteria that keep the gate honest

Write both sets down before the first run, or the gate will drift.

Entry criteria describe a build that is ready to be checked: deployed to a known environment, migrations applied, test data reset, third-party sandboxes reachable, and one named person available for the next half hour. Exit criteria describe a decision: every check has a recorded state, no blocked check is counted as passing, the money flows pass on the same build that will ship, and every failure has an owner and a decision — fix, revert, or ship under a written exception.

The exception clause matters most. Teams rarely fail because they lack a checklist; they fail because a red check gets talked into a green one at the end of a long day. Naming the person who accepts the risk, and writing down why, turns a hallway conversation into a decision somebody can review later.

Best practices that keep the check fast and focused

1. Keep one list, owned by one person. Shared ownership of a smoke suite usually means nobody notices when a check has been red for two weeks.
2. Test outcomes, not clicks. A password-reset flow that sends the email but returns a broken link is a failed check, not a passed one. Assert the end state the customer would see.
3. Include the asynchronous step. Confirmation emails, queued jobs, webhooks, and payment callbacks are where smoke suites are thinnest, because the assertion is harder to write than a button click.
4. Quarantine flakiness with a deadline. Move an unstable check out of the gate, give it an owner and a date, and keep the rest of the suite trustworthy in the meantime. A suite with two known-flaky checks trains people to rerun instead of read.
5. Never add without removing. Every new check spends part of the time budget. If the suite must grow, retire a check that has not failed in a year and is already covered by regression.
6. Review the suite after every incident. Ask which check, if any, would have caught it. Add the shortest version of that check, and delete the checks that exist only because of an old argument.
7. Run the same list in every environment. A check that passes in staging and fails in production usually describes an environment difference rather than a product defect, and a suite that differs by environment hides that signal.
8. Time the run and publish the number. Duration is the health metric of a smoke suite. When it creeps past the budget, cut scope before you cut quality.

Smoke, sanity, and regression testing: where the line sits

The three terms get used loosely, which is why teams end up arguing about labels instead of budgets. The useful distinction is the decision each one supports: smoke decides whether testing can start, sanity decides whether a fix can be closed, and regression decides whether a release can ship.

Common mistakes

• Treating a green smoke pass as release readiness. A smoke pass proves the build is testable, not that the release is safe. Skipping the regression work because smoke was green is how a broken edge case reaches customers.
• Skipping the check for hotfixes. Time pressure is the reason to run it, not the reason to skip it.
• Letting shared accounts leak between runs. Parallel runs that reuse one test user will fight over the same data and produce failures that have nothing to do with the build.
• Ignoring environment drift. A staging environment five migrations behind production will fail checks that production would pass, and the team learns to distrust the gate.
• Measuring coverage instead of decisions. The number of checks says little; the number of release decisions the suite actually informed says a lot.

Automating the smoke gate without losing ownership

Most teams start with a checklist in a document and move to automation once the list stops changing. Automate what has been run by hand for months, not what nobody has ever performed. Three properties matter more than the tool: the run can be triggered on demand, the result arrives with evidence such as per-step outcomes, logs, and screenshots, and a person owns the list.

BuniOD, for example, describes generated test scenarios that stay in review until someone confirms them, and only confirmed scenarios are included in runs. A reviewer can read each step, change an input value, or rewrite the prompt and regenerate the scenario before approving it. That review step is the property teams lose first. Once a suite runs unattended for a quarter, nobody remembers why a check exists, so a red result gets muted instead of investigated.

Common questions about smoke testing

Is smoke testing manual or automated?

Both work, and most teams use both at different moments. Manual smoke is faster to change and better for a release you rarely cut; automated smoke is the only version that survives three deploys a day. The choice should follow the frequency of the gate, not the size of the team.

How many smoke tests should a project have?

Enough to cover every flow that would block a release, and few enough to finish inside the time budget. A single web application often lands between ten and twenty checks. A product with several entry points should split the list by area rather than grow one long run, because a gate that takes an hour gets skipped.

What is the difference between smoke testing and sanity testing?

Smoke testing accepts or rejects a whole build; sanity testing examines one change or fix in more detail. Smoke is breadth-first and shallow, sanity is narrow and deeper, and both are deliberately short. Mixing them up usually shows up as a "smoke" suite that takes half a day.

Can smoke testing happen in production?

Yes, after a deployment and kept narrow: a dedicated test account, no real payments, one reversible write, and read paths for the main screens. It complements pre-release smoke on staging rather than replacing it, because the artifact that ships still has to be checked in the environment where customers live.