Regression, Smoke & Sanity Testing
The difference between smoke, sanity and regression testing, building a regression suite and testing a release.
Three tests teams confuse
Smoke, sanity and regression testing all re-check existing behaviour, so they're easy to mix up. The difference is scope and purpose.
| Smoke testing | Sanity testing | Regression testing | |
|---|---|---|---|
| Question | "Is this build stable enough to test?" | "Does this specific fix/change work?" | "Did this change break anything else?" |
| Scope | Wide but shallow — critical paths only | Narrow and focused | Wide and deep |
| When | Every new build | After a small fix or change | Before release, after significant changes |
| Duration | Minutes | Minutes | Hours (or minutes if automated) |
| Usually | Automated | Manual | Mostly automated |
Smoke testing
A smoke test is a quick check of the most critical functions. If it fails, the build is rejected and nobody wastes hours testing a broken environment.
Example smoke suite for an online store:
SMOKE-01 Home page loads with products
SMOKE-02 User can log in
SMOKE-03 Product search returns results
SMOKE-04 Item can be added to cart
SMOKE-05 Checkout page loads and test payment succeeds
SMOKE-06 Order confirmation email is sent
Six checks, ten minutes, and the team knows whether testing can start. Smoke tests are the first thing worth automating and running on every deployment.
Sanity testing
A sanity test is a narrow, quick check after a small change — usually a bug fix — to confirm the change works and nothing obviously related is broken.
BUG-201 fixed: discount codes are now trimmed. Sanity check: apply " SAVE10 " with spaces → accepted; apply "SAVE10" → still accepted; apply an invalid code → still rejected.
If the sanity check passes, the build goes on to deeper testing.
Regression testing
Regression means a feature that used to work is now broken. Regression testing re-runs existing tests after a change to catch those side effects. It's the most important — and most time-consuming — type of re-testing.
Choosing what to regress
Re-running everything for every change isn't practical with manual testing, so teams select tests:
- Retest all — the full suite, before major releases (only realistic when automated).
- Risk-based selection — tests for the changed area, areas that depend on it, and critical business flows.
- Priority-based — always run P1 tests, add P2/P3 as time allows.
Ask developers what code changed and what depends on it. A change to the tax calculation affects cart, checkout, invoices, refunds and reports — not just the tax screen.
Building a regression suite
- Start from your critical user journeys (login, search, checkout, payments).
- Add a test for every serious bug you've fixed — bugs that returned once often return again.
- Tag tests by area and priority so you can run subsets.
- Remove or update obsolete tests every release — avoid the pesticide paradox.
- Automate the stable, repetitive parts so manual time goes to exploratory testing.
Testing a release: putting it together
A typical release-day sequence:
1. Build deployed to staging
2. Smoke tests (automated, 10 min) → fail? reject build, stop
3. Sanity checks on the fixes in this build (manual, 20 min)
4. New-feature testing + exploratory sessions
5. Regression suite: automated (all) + manual (high-risk areas)
6. Bug fixes → sanity check each fix → targeted regression
7. Exit criteria met → test summary report → release decision
8. Post-release smoke test on production
Retesting is not regression testing
Retesting runs the failed test again to confirm a specific fix. Regression testing checks that the fix (or any change) didn't break other things. You need both — and in interviews, explaining the difference clearly is a favourite question.
Next, check yourself with the manual testing interview questions.