Smoke testing checks whether the build works at all. Sanity testing checks whether a specific change works correctly. That's the core distinction, and everything else follows from it.
These two terms get used interchangeably in a lot of teams, which leads to confusion in planning and reporting. "Did you sanity test the build?" might mean "did you check if anything works?" or "did you verify that one fix?" The answer to those two questions requires very different effort.
Let's make the difference concrete.
Smoke testing: does this build even work?#
A smoke test is the first thing you run on a new build. It answers one question: is this build stable enough to spend more time testing?
The name comes from hardware testing. Plug in the device, turn it on, see if smoke comes out. If it does, stop. Don't bother testing individual components when the whole thing is on fire.
In software, a smoke test covers the critical paths:
- Does the application start?
- Can a user log in?
- Does the main page/dashboard load?
- Can a user perform the core action (place an order, send a message, create a record)?
- Do database connections work?
- Are APIs responding?
That's roughly 15-30 test cases depending on your application's complexity. The goal is breadth, not depth. You're not testing edge cases or boundary conditions. You're checking that the building has walls and a roof before you inspect the plumbing.
When to run smoke tests#
After every build. This is the most common trigger. A new build lands in staging, QA runs the smoke suite before committing to a full regression pass. If smoke fails, the build goes back to development. No point running 300 regression tests on a build where login is broken.
After a deployment. Quick smoke test in production after deploying to catch deployment-specific issues (wrong environment variables, missing database migrations, broken asset paths).
In CI/CD pipelines. Automated smoke tests that run on every commit or merge. This catches catastrophic breaks before a human even looks at the build.
57% of testing is still executed manually, even in teams with automation -- PractiTest State of Testing, 2025. Smoke tests are one of the first candidates for automation because they're stable and high-value.
Smoke test examples#
For an e-commerce application:
| # | Test | Expected result | |---|------|----------------| | 1 | Open homepage | Page loads, product grid visible | | 2 | Search for a product | Results appear within 2 seconds | | 3 | Add item to cart | Cart count updates, item visible in cart | | 4 | Start checkout | Checkout page loads with cart items | | 5 | Log in with valid credentials | User lands on account dashboard | | 6 | Log out | User returned to homepage, session cleared | | 7 | Open admin panel | Admin dashboard loads (for admin user) |
Seven cases. Under 10 minutes to execute. If any of these fail, you've saved yourself the time of running the full suite.
In TestRush, you'd tag these items as smoke within your main test scripts. When you start a run, filter by the smoke tag. Only the tagged items appear, and you burn through them with keyboard shortcuts: press 1 for pass, 2 for fail, arrow down to the next item. The full regression suite waits until smoke passes.
Sanity testing: does this specific change work?#
Sanity testing is narrower and more targeted. It runs after a specific change (a bug fix, a new feature, a configuration update) and verifies that the change does what it's supposed to without breaking its immediate surroundings.
Where smoke testing is wide and shallow, sanity testing is narrow and moderately deep.
Say a developer fixes a bug where discount codes weren't applying to subscription products. Sanity testing for that fix would cover:
- Apply a discount code to a subscription product (the original bug)
- Apply a discount code to a one-time product (should still work)
- Apply an expired discount code (should still be rejected)
- Apply a discount code to a cart with both subscription and one-time products (combination scenario)
- Complete checkout with a discounted subscription (end-to-end for the affected flow)
That's five focused tests around the changed area. You're not testing login, search, or the admin panel. Those aren't related to the discount code fix. If you want full coverage, that's what regression testing is for. Sanity testing is a quick confidence check on the specific change.
When to run sanity tests#
After a bug fix lands. The developer says "fixed in build 2.4.3." You verify the fix and check nearby scenarios.
After a small feature addition. A new filter option was added to the search page. Sanity test the new filter, verify existing filters still work, check that the results page handles the new filter correctly.
Before accepting a build for full testing. Sometimes a specific fix was the reason QA rejected the previous build. Sanity-check that fix first. If it's still broken, send it back without running the full suite.
When you write test cases with good tagging, sanity testing becomes fast. Tag cases related to each feature area, and when a fix comes in, filter the run to just that tag. No scrolling through 400 unrelated cases.
Side-by-side comparison#
| Aspect | Smoke testing | Sanity testing | |--------|--------------|----------------| | Purpose | Is the build stable? | Does this change work? | | Scope | Broad, entire application | Narrow, specific feature/fix | | Depth | Shallow, surface-level | Moderate, focused area | | When | After every build/deploy | After specific changes | | Size | 15-30 test cases | 5-15 test cases | | Time | 10-30 minutes | 5-20 minutes | | Failure means | Reject the build outright | Send the fix back to dev | | Scripted? | Yes, stable suite | Often ad-hoc or semi-scripted | | Automation fit | High (great CI/CD candidate) | Low to medium (changes per fix) |
How they fit into the testing workflow#
In practice, smoke and sanity tests aren't alternatives. They happen at different points in the same workflow.
Here's a typical sequence for a sprint release:
- Build arrives in staging
- Smoke test -- Can the build function at all? If no, reject immediately
- Sanity test specific fixes -- The bug that was blocking last build, did it get fixed? Verify those targeted scenarios
- Full regression run -- Now that the build passes smoke and the targeted fixes are confirmed, run the full test suite
- Report results -- Pass rates by feature area, blockers, recommendation
Skipping the smoke test and jumping to regression is a common mistake. You'll find out 45 minutes into a 200-case run that login is broken and everything after case #3 is invalid. Those 45 minutes are gone. A 10-minute smoke test would have caught it upfront.
Skipping sanity testing is less costly but still wasteful. If the build was specifically meant to fix three bugs and you jump straight to regression, you might run 200 tests before discovering that the original bugs are still there. Verify the targeted fixes first.
Building your smoke test suite#
A good smoke suite has these properties:
Covers all major feature areas. At least one test per major area of your application. Authentication, core workflow, data display, admin functions. If any area is completely untested in smoke, a total break in that area won't get caught early.
Runs in under 30 minutes. If your smoke suite takes an hour, it's too big. Trim it. A smoke test that takes as long as the regression run defeats its purpose. With keyboard-driven execution, 20-30 items should take 10-15 minutes.
Changes rarely. The smoke suite should be stable. It tests fundamental flows that exist in every release. If you're updating your smoke suite every sprint, you're probably including too much feature-specific detail.
Has a clear pass/fail gate. Any smoke failure means the build is rejected. Don't have "acceptable" smoke failures. If a test is in the smoke suite, it tests something that must work. If failure is sometimes acceptable, the test doesn't belong in smoke.
Maintaining the boundary#
The biggest risk with smoke suites is scope creep. After a production incident, the instinct is to add that scenario to the smoke suite. After a few incidents, your 20-case smoke suite is 60 cases and takes 45 minutes. It's become a mini regression suite.
Resist the urge. Add the new cases to the regression suite instead and tag them appropriately. Smoke stays lean. If you need a middle ground, consider a "critical" tag that's broader than smoke but narrower than full regression.
A smoke suite that grows past 40 test cases is doing double duty. Split it: keep smoke at 20-30 core cases and create a "critical regression" tag for the important-but-not-smoke cases that should run before a full pass.
Sanity testing tips#
Keep it focused#
The temptation after a bug fix is to "test a few extra things while you're in the area." That's how a 5-test sanity check becomes a 30-test mini-regression. Define the scope before you start: test the fix, test the nearby scenarios, stop.
Document what you checked#
Even if sanity tests are ad-hoc, record what you verified. "Tested discount code fix: original bug fixed, existing codes still work, expired codes rejected, combination cart works." This takes 30 seconds and prevents the "did anyone actually verify that fix?" conversation later.
Know when to escalate to regression#
If the sanity test reveals something unexpected (the fix works but a related feature broke), that's a signal to run a broader regression on the affected area. Don't keep poking at individual cases. Escalate to a proper regression run and get the full picture.
Common mistakes#
-
Treating smoke and sanity as the same thing. They answer different questions and run at different times. Calling everything a "sanity check" creates confusion about what was actually tested. Be specific in your communication: "smoke passed" means the build is stable. "Sanity passed" means the specific fix/feature is working.
-
Running regression instead of smoke. Full regression on every build burns time and delays feedback. Run smoke first, fail fast, and save the full regression for builds that pass the basic bar. The regression testing checklist covers how to build an efficient regression suite.
-
Not having a defined smoke suite. "I'll just click around and see if things work" is not a smoke test. It's ad-hoc exploration with no consistency between runs. Write down the 20 things that must work and formalize them. Future you will appreciate it.
-
Sanity testing only the exact bug. If a developer fixed a discount code bug, don't just test that one discount code. Test a few adjacent scenarios -- different code types, combined carts, expired codes. Fixes sometimes introduce regressions in nearby logic.
FAQ#
What is smoke testing?#
Smoke testing is a broad, shallow verification that a build's core functions work. Can it start? Can users log in? Do the main pages load? Does the primary workflow complete? It's the gatekeeper before deeper testing begins. If smoke tests fail, the build goes back to development without wasting time on detailed testing.
What is sanity testing?#
Sanity testing is a narrow, focused check on a specific fix or feature change. After a developer fixes a bug or adds a feature, sanity testing verifies that particular change works and hasn't broken its immediate neighbors. It's deeper than smoke testing within its scope but doesn't test unrelated areas.
Can one test be both a smoke test and a sanity test?#
Conceptually, no -- they serve different purposes. But a single test case can appear in both contexts. "User can log in" might be part of your smoke suite and also be a sanity test after a login bug fix. The test is the same; the context and trigger are different. In TestRush, you'd tag it as smoke and also run it during targeted sanity checks by filtering the feature area.
Do I need both if I have regression testing?#
Yes. Regression testing is too slow for early build verification (that's smoke's job) and too broad for verifying individual fixes (that's sanity's job). Smoke verifies the build is worth testing at all, and sanity confirms specific fixes before you commit to a full regression pass. Each operates at a different speed and scope. The test prioritization strategy covers how to balance these run types.
Ready to set up tagged test suites for smoke, sanity, and regression? Start your free trial or explore the live demo to see how tag-filtered runs work.