Explain smoke, sanity and regression testing. How do they differ?

All three are about confidence after a change, but they differ in breadth, depth and purpose. Smoke testing is broad and shallow: is this build stable enough to bother testing? Sanity testing is narrow and focused: does this particular fix or change work, and is the area around it sane? Regression testing is broad and deeper: did the changes break anything that used to work?

Smoke testing

• Also called build verification testing.
• Runs first on every new build or deployment.
• Covers the critical paths at a shallow level: the app starts, users can log in, the home page loads, the main transaction can be completed, key APIs respond.
• If it fails, the build is rejected and further testing stops, saving everyone’s time.
• Should be fast (minutes) and is almost always automated, often as a post-deployment check in the pipeline.

Sanity testing

• Done when a build contains a small change, typically a bug fix, often late in a cycle.
• Checks that the fix works and that obviously related behaviour still makes sense.
• Narrow and often unscripted. It is a quick judgement, not a full test pass.
• Example: a fix for incorrect discount rounding. Sanity testing applies a few discounts, including the one in the bug report, and checks the cart total and invoice.

Regression testing

• Re-runs tests of existing functionality after any change: new features, fixes, refactors, dependency or configuration upgrades.
• Can be full (everything) or selective (areas affected by the change, chosen by risk or impact analysis).
• Grows over time as each fixed bug gets a test, which makes it the prime candidate for automation and parallel execution in CI.

Side by side

	Smoke	Sanity	Regression
Question	Is the build testable?	Does this change work?	Did anything else break?
Scope	Broad, shallow	Narrow, focused	Broad, deeper
When	Every new build	After a small fix or change	After any change, before release
Usually	Automated	Manual, quick	Automated, plus targeted manual

A note on terminology

Definitions vary between teams and sources. Some treat sanity as a subset of regression; some use “smoke” and “sanity” interchangeably. In an interview it is worth giving the common definitions and then saying you would align with your team’s vocabulary. The underlying ideas (gate the build, check the fix, protect existing behaviour) are what matter.

What interviewers look for

• Clear contrast in scope: broad/shallow vs narrow/focused vs broad/deep.
• When each runs in the delivery pipeline.
• Recognition that regression is the main automation investment.
• Practical maturity about inconsistent terminology.