Smoke vs Sanity Testing

A new build lands in the QA environment. Before you spend a day on detailed testing, you want to know two things: is this build even worth testing, and does the thing that was just changed basically work? Those two questions correspond to smoke testing and sanity testing. They are both quick, shallow checks, which is why they are so often confused, and why “smoke vs sanity” is a staple interview question.

Be aware up front: the industry does not use these terms consistently. The ISTQB glossary defines smoke testing and has listed “sanity test” as a synonym of it, not as a separate type. Many teams, however, use the two words for different things, and that common distinction is what interviewers usually expect. This lesson explains the common distinction and points out where the formal and informal usage differ.

Smoke testing

A smoke test is a small set of tests covering the main functions of a system, run to decide whether a build is stable enough for further testing. The name is commonly traced to hardware: power on a new board and see whether smoke comes out before doing anything else.

Characteristics:

• Broad and shallow. It touches the most important features, but only checks that they basically work.
• Run on every new build or deployment, before any other testing.
• Gatekeeping. If the smoke test fails, the build is rejected or the deployment rolled back; nobody wastes time testing a broken build.
• Fast. Minutes, not hours.
• Usually automated and scripted, because it runs so often.

A smoke suite for an online shop might be:

Check	Why
Home page loads and returns HTTP 200	Deployment and routing work
Health endpoint reports database and cache as up	Core dependencies are reachable
A known user can log in	Authentication works
Search returns results for a known term	Search service and index are up
Product can be added to the cart	Core state handling works
Checkout page loads with a test payment form	Payment integration is configured

Notice what is not there: validation rules, edge cases, every payment method, every browser. That is what later testing is for.

Sanity testing

In common usage, a sanity test is a quick, narrow check that a specific change, fix or small feature works as expected and has not obviously broken its immediate surroundings, done to decide whether deeper testing of that area is worthwhile.

Characteristics:

• Narrow and focused. It concentrates on the changed area.
• Run after a fix or a small change, typically on a build that has already passed smoke testing.
• Often unscripted, performed by a tester who knows the area, though it can be automated.
• Fast, because its purpose is to decide whether to continue.

Example: a developer fixes a bug where discount codes were case-sensitive. A sanity check is to apply the code in upper, lower and mixed case, check the total updates, and check that removing the code restores the original total. If that works, the tester proceeds with confirmation testing and the planned regression around discounts. If it does not, the build goes back immediately.

Side by side

	Smoke testing	Sanity testing (common usage)
Question	Is the build stable enough to test?	Does this change basically work?
Scope	Broad: the most important features	Narrow: the changed area and its neighbours
Depth	Shallow	Shallow to moderate in the focused area
When	Every new build or deployment	After a fix or small change, on a stable build
Scripted?	Usually scripted and automated	Often unscripted; can be automated
Outcome if it fails	Reject the build or roll back	Send the change back before deeper testing
Relationship to regression	A tiny subset of the regression suite	A focused precursor to confirmation and regression testing

A useful analogy: smoke testing checks that the car starts, the lights work and the brakes respond. Sanity testing checks that the new radio a mechanic just installed turns on and does not drain the battery.

Where they fit in a pipeline

In a continuous delivery pipeline, the order typically looks like this:

Commit -> Build -> Unit tests -> Deploy to test env -> SMOKE -> Regression tiers -> Deploy to staging -> SMOKE -> Release -> SMOKE (production)

Smoke tests appear more than once: after every deployment, in every environment, including production. A post-deployment smoke test in production uses read-only checks or dedicated test accounts so it does not create real orders or emails.

Sanity checks appear around specific changes: after a hotfix is deployed to staging, a tester or a targeted automated test verifies the fixed behaviour before the wider regression suite starts. See Regression Testing for how the tiers after smoke are organised, and STLC for where the smoke test sits in environment setup.

Automating a smoke suite

Smoke tests are ideal automation candidates: stable, high value, run often. A Playwright smoke test tagged for selection:

import { test, expect } from '@playwright/test';

test.describe('smoke', { tag: '@smoke' }, () => {
  test('health endpoint reports dependencies up', async ({ request }) => {
    const res = await request.get('/api/health');
    expect(res.status()).toBe(200);
    const body = await res.json();
    expect(body.database).toBe('up');
  });

  test('known user can sign in', async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(process.env.SMOKE_USER!);
    await page.getByLabel('Password').fill(process.env.SMOKE_PASSWORD!);
    await page.getByRole('button', { name: 'Sign in' }).click();
    await expect(page.getByRole('heading', { name: 'Your account' })).toBeVisible();
  });
});

npx playwright test --grep @smoke

The health endpoint path and response shape above are examples; use whatever your application exposes. Credentials come from environment variables, never from the source code.

Design rules for smoke suites:

• Keep it small. If it grows past a handful of minutes, it is becoming a regression suite. Move tests out.
• Make it extremely reliable. A flaky smoke test blocks every deployment and is ignored within a week.
• Fail fast and loudly. Stop on the first failure if that saves time, and report which check failed in plain language.
• Do not depend on test data created by other tests. Seed what you need or use stable fixtures.
• Run against every environment with configuration, not separate code.

Related terms you may hear

• Build verification test (BVT) or build acceptance test: essentially smoke testing, named for its gatekeeping role.
• Intake test: a term (found in the ISTQB glossary) for a check that decides whether a component or system is ready for detailed testing; effectively a kind of smoke test.
• Health check: an automated endpoint or monitor confirming a service is alive. It is narrower than a smoke test, which exercises user-facing behaviour.
• Synthetic monitoring: smoke-style journeys run on a schedule against production by monitoring tools.

Practice exercise

You test a food delivery web app with these features: browse restaurants, search, view menu, add to basket, checkout with card or wallet, order tracking, user profile, restaurant ratings, and an admin dashboard.

1. Design a smoke suite of at most eight checks. Justify each in a few words.
2. A developer deploys a fix for “basket total does not update when an item quantity is changed”. Describe your sanity check.
3. Which of your smoke checks are safe to run in production, and what would you change for the others?

Show a model answer

1. Smoke suite

#	Check	Why
1	Home page loads with restaurant list	Deployment, routing, restaurant service
2	Search for a known restaurant returns it	Search service and index
3	Restaurant menu page loads	Menu service
4	Item added to basket updates the basket count	Basket state
5	Known test user can sign in	Authentication
6	Checkout page loads with card form in test mode	Payment integration configured
7	Order tracking page loads for a seeded order	Tracking service
8	Admin dashboard login page loads	Admin app deployed

Ratings and profile editing are left to regression; they matter less for “can we test this build?”.

2. Sanity check for the basket fix

Add one item, increase the quantity from 1 to 3, and check the line total and basket total update. Decrease to 2 and check again. Set quantity to 0 or remove the item and check the total. Refresh the page and check the totals persist. If all pass, proceed to confirmation testing with more variations and regression around basket, discounts and checkout totals.

3. Production

Checks 1, 2, 3, 7 (with a dedicated test order) and 8 are read-only and safe. Check 4 is safe if baskets for anonymous users are not persisted or are cleaned up. Check 5 needs a synthetic account. Check 6 must stop at loading the form; never submit a real payment.

Key takeaways

• Smoke testing is broad and shallow: is the build stable enough to test? It runs on every build or deployment and gates further testing.
• Sanity testing (common usage) is narrow: does this specific change basically work before we test it deeply?
• The terms are used inconsistently; the ISTQB glossary has treated them as synonyms. Know the common distinction and say that it varies.
• Smoke suites must be small, fast, reliable and automated, and run in every environment.
• Both are precursors to, not replacements for, confirmation and regression testing.