Software Testing Regression Testing

Regression testing is the process of re-running previously passed test cases after a code change to confirm that the change has not broken anything that already worked. Every new feature, bug fix, or configuration change is a potential source of unintended side effects. Regression testing finds those side effects.

The Regression Problem

  Version 1.0 — All features working:
  ✔ Login works
  ✔ Search works
  ✔ Cart works
  ✔ Payment works

  Developer fixes a bug in the Payment module for Version 1.1
         ↓
  Version 1.1 — Without regression testing:
  ✔ Payment bug fixed  ← intended
  ✘ Search broken      ← unintended side effect!
  ✘ Cart total wrong   ← unintended side effect!

  Regression testing catches these before users do.

When to Run Regression Tests

  • After any bug fix — to ensure the fix did not break related features.
  • After adding a new feature — to ensure existing features still work.
  • After a code refactor — when the internal structure changes but behaviour should stay the same.
  • After a configuration or environment change — such as a database upgrade or server migration.
  • Before every release — as a final safety check.

Types of Regression Testing

Full Regression

The entire test suite is re-run from beginning to end. This gives maximum confidence but takes the most time. Full regression is typically run before a major release.

Partial Regression

Only the test cases related to the changed code are re-run. This is faster but carries a small risk of missing side effects in seemingly unrelated areas.

Selective Regression

A test analyst uses code change impact analysis to identify which test cases are most likely to catch regressions from the specific change made. Only those are run.

Prioritised Regression

Test cases are ranked by risk and importance. High-priority cases run first. If time is limited, the team stops after the highest-priority cases are done.

  PRIORITY   TEST CASES                  WHEN TO RUN
  ────────   ──────────                  ───────────
  P1 (High)  Core workflows (login,      Always — every build
             payment, checkout)
  P2 (Med)   Secondary features          Every sprint release
             (search, filters)
  P3 (Low)   Rarely-used features        Major releases only
             (admin reports)

Regression Testing and Automation

Regression testing is the single most important use case for test automation. Running 500 regression test cases manually after every code change is slow, expensive, and error-prone. Automated regression suites run those same 500 cases in minutes.

  Manual Regression: 500 test cases × 3 minutes each = 25 hours
  Automated Regression: 500 test cases in 15 minutes

  Saved per release: ~24 hours and 45 minutes

Teams using CI/CD pipelines run automated regression tests automatically every time code is pushed to the repository — sometimes dozens of times per day.

Building a Regression Test Suite

  Step 1: Identify the most critical test cases
          (core user journeys, high-risk modules)

  Step 2: Add all test cases that have previously
          caught bugs in this application

  Step 3: Add boundary and edge case tests for
          complex business rules

  Step 4: Automate the stable, repetitive test cases

  Step 5: Review and update the suite after each release
          — retire outdated tests, add new ones

Regression vs Retesting

  RETESTING                         REGRESSION TESTING
  ─────────                         ──────────────────
  Tests the specific bug that       Tests the whole application
  was fixed                         after a change

  "Did this particular fix work?"   "Did this fix break anything else?"

  Narrow scope                      Broad scope
  Done by the tester who            Done by the full team or
  reported the bug                  automation tools

Regression Testing Challenges

  • Test suite bloat: Over time, the regression suite grows very large. Old, irrelevant tests slow it down without adding value. Regular pruning is needed.
  • Flaky tests: Some automated tests pass sometimes and fail other times without any real bug. Flaky tests destroy confidence in the regression suite and must be fixed or removed.
  • Maintenance overhead: When the application's UI or API changes, automated regression tests break and must be updated — this takes significant ongoing effort.
  • Time pressure: Under deadline pressure, regression testing is often cut short. This is a leading cause of post-release bugs.
Previous lessons
Back to courses
Next lessons

Leave a Comment