Regression testing
Regression testing is re-running tests over existing functionality to confirm that a recent change has not broken something that previously worked. It targets the behaviour nobody meant to touch, which is where unintended breakage hides. The suite grows over time, typically gaining a test for every bug that has already been fixed once.
The longer version
Every change carries the risk of breaking something unrelated to it, through shared code, shared state, or an assumption that held until it did not. Regression testing is the systematic answer to that risk: rather than reasoning about what a change might have affected, re-verify what used to work.
The suite grows by accretion. A common and effective discipline is that every fixed bug gains a test reproducing it, so the suite becomes a record of every mistake the team has already made once. That is what stops the same defect returning two releases later, and it is why a regression suite is usually the largest body of tests a mature project has.
Because it grows, it eventually gets slow, and the response to slowness is where teams diverge. Some run the full suite nightly and a selected subset per change, choosing tests by which code the change touched. Others invest in parallelisation and keep running everything. Both are defensible; deleting tests to make the suite fast is not, because the tests being deleted are precisely the record of past failures.
Regression testing is not a phase so much as a standing obligation. It is the reason continuous integration exists in the shape it does: a suite that only runs before a release tells you what broke sometime in the last month, while one that runs per change tells you which change broke it.
Common questions
When should regression tests run?
As close to each change as the suite's runtime allows. Running per change identifies the commit responsible; running only before a release tells you something broke in the last few weeks without saying what. Teams with slow suites usually run a targeted subset per change and the full suite nightly.
What is a regression?
Behaviour that used to work and no longer does. The term covers both a feature that broke and a bug that was fixed and has come back, which is why a returning defect is described as having regressed.
How do you keep a regression suite from getting too slow?
By parallelising it and by selecting tests based on what a change touched, not by deleting tests. The suite is the accumulated record of past failures, so removing cases to save minutes trades a known safeguard for time.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.