Regression testing

Regression testing checks that a change has not broken something that used to work. A “regression” is a feature that worked in a previous build and no longer does. You catch it by re-running tests for existing behavior after every bug fix, feature, refactor, dependency upgrade or configuration change.

Example

A team adds a “pay with gift card” option to checkout. The new feature gets its own tests. Regression testing asks a different question: do card payments, discount codes, tax calculation and order emails still behave exactly as before? A shared change to the price-calculation module could easily break any of them without touching the new code path.

Choosing what to run

Running every test on every commit is the simplest strategy, and with a fast automated suite it is often the right one. When the full suite is too slow or partly manual, teams select:

• By risk. Business-critical flows (sign-up, payment, data export) always run.
• By impact. Areas that share code, data or services with the change.
• By history. Modules that have regressed before tend to regress again.

A common split is a fast regression subset on every pull request and the full suite nightly or before a release.

Why it is the first thing teams automate

Regression tests run the same steps against the same expected results again and again, which is exactly what automation is good at. Manual regression grows with every release while the time available does not, so it gets cut first. An automated regression suite in CI turns “did we break anything?” from a week of manual checking into a pipeline result.

Common mistakes

• Treating the suite as append-only. Obsolete and duplicate tests slow every run. Review and prune.
• Tolerating flaky tests. If failures are routinely re-run until green, real regressions get re-run away too.
• Only testing through the UI. Most regression coverage is cheaper and more stable at the unit and API level.