Regression, Smoke, Sanity, Re-testing

Software never sits still — every sprint changes it, and every change can break something that worked yesterday. So the profession grew a whole vocabulary for testing around change: checking the fix, checking the fix's neighborhood, and checking the product still stands at all. Four words — re-testing, regression, smoke, and sanity — that will appear in your standups from week one, and that beginners reliably tangle.

Home renovation keeps them straight. The plumber replaced a pipe: checking the new pipe doesn't leak is re-testing. Checking the electrician's socket two rooms away still works — because walls were opened and who knows what got knocked — is regression. And flipping the main breaker to confirm the house has water and power at all, before inspecting anything in detail, is smoke.

Re-testing: Did the Fix Fix It?

Re-testing — textbooks say confirmation testing — answers the narrowest question: the bug you reported has a fix; does the exact failing scenario now pass? Omar ships a fix for FW-312, the date-picker time-zone bug. You reproduce the original scenario — same time zone, same dates, same steps — on the new build (Chapter 2's lesson: verify the build actually contains the fix). It passes. FW-312 is confirmed fixed. Nothing more is claimed — and that's the point: re-testing is deliberately narrow, one scenario, pass or fail.

Regression: Did the Fix Break Anything Else?

Regression testing asks the bigger, scarier question: did this change damage anything that used to work? A fix is a change like any other, and changes have blast radii — code is interconnected, and touching the date logic can disturb everything that reads dates. So after re-testing the fix itself, you re-run existing checks on unchanged behavior nearby: search by dates, the cancellation cutoff, confirmation emails. You're not looking for new features misbehaving — you're looking for old, previously-working behavior that quietly broke. Such a break is called a regression, and hunting them is regression testing.

Two facts make regression testing enormous in practice. First, it grows forever: every shipped feature adds behavior that future changes might break, so the pile of "things to re-check" only accumulates. Second, it's the same checks repeated on every change — which makes it boring for humans and perfect for machines. Hold that thought; it's the entire economic case for test automation, and Chapter 9 picks it up by name.

Smoke: Is the Build Alive at All?

Smoke testing is the short "is it alive?" pass you run on a brand-new build before investing real testing time in it. Can you open Fernway, search, view a property, reach checkout? Ten minutes, the vital signs only. The name comes from electronics: plug the new circuit in and see if smoke comes out before bothering with precise measurements. A build that fails smoke goes straight back — and the ten minutes just saved you an afternoon of testing a corpse, plus the embarrassment of thirty bug reports that all boil down to "the build was broken."

Sanity: the Informal Cousin

Sanity testing is the quick, narrow check that a specific area still behaves sensibly after a change — before deciding deeper testing is worth it. Promo logic changed? Apply SUMMER15 once, see a sane result, then commit to the full workup. Honesty requires a warning here: of these four terms, sanity is the one real teams use loosest — some treat it as a synonym of smoke, some as "quick regression," some as this book's definition. Textbook distinction: smoke asks "does the whole build show vital signs?", sanity asks "does this area still make sense after the change?" Learn the distinction, then translate to local dialect on each team you join.

Smoke the buildalive at all?

→

Re-test the fixthe exact scenario, again

→

Regression around itdid it break the neighbors?

→

FW-329 foundthe fix broke the cutoff

The Story of FW-329

Watch the whole routine run on a real change. Omar's fix for FW-312 lands in a fresh build. Smoke first: Fernway opens, search works, checkout reachable — alive. Re-test next: the time-zone scenario that defined FW-312 now passes — fixed. Then regression, because the fix touched date arithmetic: search by dates fine, confirmation emails fine... and the 48-hour cancellation cutoff is now wrong by one hour. The fix normalized time zones in one place but not the other. New bug: FW-329 — found not by luck but by the routine, because regression testing exists precisely for the damage that fixes do to their neighbors. (Omar took it well. Developers who've been around know: fixes breaking adjacent things isn't sloppiness, it's Tuesday — which is why the routine is a routine.)

Why This Vocabulary Earns Its Keep

These four words schedule real work unambiguously. "Smoke the new build, re-test FW-312, run regression on everything date-adjacent" is a complete plan a colleague can execute without a single follow-up question — try saying that in plain English at the same length. That's the practical test of professional vocabulary: it compresses coordination. You'll use these four more than almost any others in this book.