Smoke, Sanity, and Regression Testing

Smoke, sanity, and regression are three of the most-confused terms in the QA vocabulary. Even experienced engineers use them interchangeably, which leads to muddled test plans and arguments in retrospectives. Once you know the differences, you can pick the right test for the right moment — and explain it cleanly to the rest of the team.

The three at a glance

Smoke testing is the first sniff at a new build. Does the application even start? Can a user log in? Does the home page render? Smoke tests are wide and shallow — they touch the major features without going deep. A typical smoke suite has 10 to 50 tests and runs in a few minutes. The name comes from electrical engineering: plug it in, see if smoke comes out.

Sanity testing is a focused recheck after a bug fix or a small targeted change. If a developer fixes the password reset flow, a sanity test exercises that flow plus the closely related login and account flows. Sanity tests are narrow and deep — they touch a small area thoroughly. The goal is to confirm the fix actually works and did not obviously break anything nearby.

Regression testing is the wide, deep recheck of the entire application after any change of consequence. A regression suite tries to verify that everything that worked before still works now. A mature regression suite has hundreds or thousands of tests, runs for tens of minutes to hours, and lives almost entirely in automation. The cost of running it manually would be prohibitive.

When each one runs

A typical pre-release flow:

1. Build arrives. Run smoke tests first. If smoke fails, stop — there is no point testing anything else.
2. Smoke passes. Run sanity tests on whatever was changed. If sanity finds problems, send the build back.
3. Sanity passes. Run regression tests against the whole application. If regression fails, decide whether the failure is critical or acceptable.
4. Regression passes. Run any non-functional tests (performance, security scans), then promote.

In a CI/CD pipeline this is compressed: smoke runs on every commit, sanity equivalents run as part of the unit and integration test suites, and regression runs nightly or on every merge to main. The decision points are the same; the ceremony is faster.

Common confusions

"Smoke and sanity are the same thing." They are not. Smoke is shallow and broad; sanity is narrow and deep. A smoke test touches every major area lightly. A sanity test exercises one area thoroughly. Both are quick, but for different reasons.

"Regression means rerunning the same tests." Regression includes rerunning existing tests, but it also includes adding new tests that cover the bug just fixed — so the same defect cannot regress in the future. Every fixed bug should produce at least one regression test.

"You only need automation for regression." Smoke and sanity benefit enormously from automation too. Manual smoke testing on every build is one of the surest ways to slow a team down.

"Sanity testing is a downgrade from regression." Sanity is not a lighter regression. They have different purposes: sanity verifies a specific fix, regression verifies overall health. You run both.

Building a healthy regression strategy

The biggest danger with regression suites is that they grow forever. Tests get added, never deleted, and the suite eventually takes hours to run and is full of flaky tests. A few habits keep regression suites healthy:

• Delete tests for removed features. Obvious, often skipped.
• Treat flake as a bug. A test that fails 5% of the time is a defect in your test suite, not in your application.
• Tag tests by risk. A "critical" tag for must-pass tests, "extended" for the full suite. Run critical on every PR, full on nightly.
• Measure suite duration. If regression takes longer than 30 minutes, parallelise or trim. Long suites discourage running them.
• Pair regression with monitoring. Some regressions only show up under load or with real data — synthetic monitoring on production catches what your suite cannot.

What you should walk away with

Smoke, sanity, regression: shallow-broad, narrow-deep, deep-broad. Each has a job; each runs at a different moment. The next lesson moves up the test pyramid into integration and system testing — the layers that connect units into a working whole.