Regression Testing
Sanity testing checks that one specific fix works. Regression testing asks the scarier, broader question: did fixing that one thing — or adding that one new feature — quietly break something else that used to work fine? Software isn't a pile of independent parts; features share code, share data, share screens. A change in one corner of RecipeBox can ripple out and break a completely unrelated corner, and regression testing exists to catch exactly that kind of ripple before real users do.
What Is Regression Testing?
Regression testing is the practice of re-running previously passed tests against a new build to confirm that existing, working functionality still works after a code change — a new feature, a bug fix, a refactor, even a configuration or database change. The word "regression" literally means "going backwards": you're checking that quality hasn't regressed.
It is not about testing the new change itself (that's what dedicated test cases for the new feature, or a sanity test for the fix, are for). It's about testing everything around the change that shouldn't have been touched at all.
Why It's Needed: A RecipeBox Example
Suppose a developer improves RecipeBox's Search feature so it can now match partial ingredient names, not just recipe titles. To do that, they refactor the shared data-access layer that both Search and the Recipe List query. The change ships, and Search now works beautifully.
But that shared data-access layer is also used by Add Recipe to save a new recipe's fields (title, ingredients, steps, photoUri, category, prepMinutes) to storage. If the refactor subtly changed how the ingredients list is serialized, Add Recipe could now silently save a corrupted or empty ingredients list — a completely different feature, broken by a change that was never meant to touch it. Nobody would think to manually re-test Add Recipe when the changelog says "improved search." That's exactly the gap regression testing closes.
Building a Regression Suite Over Time
No team designs a "complete" regression suite on day one — it grows organically, and a good tester treats every past bug and every core flow as a candidate to add:
| Source | Why it becomes a regression test |
|---|---|
| Every closed bug | Once "Prep Time accepts negative numbers" is fixed, a test for it is added permanently — so if a future change reintroduces that bug, it's caught immediately instead of shipping again. |
| Core happy-path flows | Login → view Recipe List → Add Recipe → Search for it → Edit it → Delete it. These almost never change in intent, so they're cheap, high-value regression checks. |
| High-risk shared code | Anything used by multiple features (like RecipeBox's data-access layer) earns extra regression coverage, because a break there fans out widely. |
| Past production incidents | If a bug escaped to real users once, it goes into the suite so it can never escape silently a second time. |
Over a year of RecipeBox releases, this turns into a suite of maybe 150-300 checks covering login, CRUD operations on recipes, search, category filtering, and every previously-fixed bug. Running all of that manually before every release quickly becomes too slow — which is exactly why regression suites are the first thing most QA teams automate.
Full Regression vs Partial Regression
| Type | When it's used | RecipeBox example |
|---|---|---|
| Full regression | Before a major release, or when a change touches deep shared/core code | Re-run the entire suite (login, all CRUD, search, filters, all past bug checks) before the v3.0 release |
| Partial (targeted) regression | After a small, well-understood change with a limited blast radius | A UI-only tweak to the Recipe List's sort order — re-run just the Recipe List and Search related checks, not the entire suite |
Regression Testing and Automation
Regression tests are, by definition, run over and over again on every new build — the exact situation where automation earns its cost. A manual tester has to re-learn nothing about a regression check each time (the steps never change), which makes it an ideal candidate to script once and run automatically on every build going forward, freeing human testers to spend their time on new features and exploratory testing instead.
If you want to see how these same RecipeBox-style checks get turned into automated scripts, the Selenium with Java track picks up from here and builds automated regression suites step by step.