Smoke, Sanity and Regression Testing

A new Basketly build lands with the SAVE10 fix inside. You could start a full day of testing straight away. But what if the app does not even load? What if the fix does not work? And what if the fix broke something else, like the delivery fee? Three quick questions, three kinds of testing.

The rule

Smoke: does it run? Sanity: does the fix work? Regression: did anything else break?

• Smoke testing is a short, broad, shallow check that a new build is stable enough to test further. It touches the main journeys: open the app, log in, search, add to cart, reach checkout. If smoke fails, the build goes straight back. The name comes from hardware: switch it on and see if smoke comes out.
• Sanity testing is a short, narrow check that a specific change or fix does what it should, plus its immediate surroundings. It is a quick "does this make sense?" before investing more time.
• Regression testing re-checks features that already worked, to catch anything the change broke by accident. Code is connected in surprising ways, so a coupon fix can break a delivery fee. Regression suites grow over time, which is why they are the first thing teams automate.

Some teams use "smoke" and "sanity" loosely or even swap them. What matters is the idea behind each: broad-and-shallow, narrow-and-focused, and wide re-checking.

The shortcut

Run them in cost order: smoke, sanity, regression. Each is a gate that protects the time spent on the next.

The trap is skipping regression because "it was only a small fix". Small changes in shared code, like the function that calculates totals, cause some of the most surprising breakages.

Drills

Answer fast — trust the rule.

Remember

• Smoke: does it run? Sanity: does the fix work? Regression: did anything else break?
• Run them in cost order; each gate protects the next.
• No change is too small for regression in shared code.