"What's the difference between smoke and sanity?" and "is retest the same as regression?" seem like rote-memorization questions, but they have a practical purpose: each of these types answers a different question about the build, and running the wrong one at the wrong time costs time. Knowing how to tell them apart is what organizes the routine of anyone who tests every day.

The quick map

New build arrived
       │
       ├── Is it worth testing?               → SMOKE   (broad and shallow)
       │
       ├── Is that specific area OK?          → SANITY  (narrow and deep)
       │
   A bug was fixed?
       │
       ├── Is the bug really gone?            → RETEST  (same case, same steps)
       │
       └── Did the fix break something else?  → REGRESSION (the surroundings and the rest)

Smoke test — "does the build come up?"

The name comes from electronics: you powered up the board and, if smoke came out, there was no point continuing. The smoke test is a broad and shallow set of checks on the most critical flows: does the application start? Does login work? Does the home page load? If the smoke test fails, the build is rejected before spending effort on deeper tests.

It's the pipeline's first gate — it runs automated on every deploy, in minutes. A red smoke test means "no point continuing".

Sanity test — "does this specific part make sense?"

Sanity is the opposite in shape: narrow and deep. After a targeted change (a fix, a rule tweak), you verify only that functionality in detail, without sweeping the whole system. It's a quick rationality check: "they touched the shipping calculation — is shipping still coherent?".

Smoke is wide and shallow (many areas, superficially). Sanity is narrow and deep (one area, thoroughly). Both are quick "is it worth going on?" checks, but in opposite directions.

Retest (confirmation testing) — "is the bug gone?"

When a defect is fixed, the retest runs exactly the same case that failed, with the same steps and data, to confirm it now passes. It's targeted and deterministic: either that specific bug is gone, or it isn't. Without a retest, you close a bug on trust.

Regression — "did the fix break the rest?"

Every change has potential side effects. Regression testing reruns a set of already existing cases around the change (and ideally across the system) to make sure what used to work still works. It's the type that grows the most over time and the main candidate for automation — a manual regression suite quickly becomes a bottleneck.

The classic confusion: retest confirms the fix of bug X; regression checks that fixing X didn't break Y and Z. They go together, but answer different questions.

Side by side

How this shows up in the pipeline

In practice they fit into an order: smoke runs first and blocks broken builds cheaply; if it passes, automated regression covers the surroundings; sanity and retest come in when there's a specific fix to validate. Mapping each one to the right moment avoids both the waste of running the whole suite for a trivial change and the risk of releasing without checking side effects.

Conclusion

They are neither synonyms nor an academic detail: smoke decides whether testing is worthwhile, sanity focuses on the spot that was touched, retest confirms the fix and regression protects the rest. Using the right term makes it clear to the team what was verified — and that's half of quality communication.