A regression is a bug that was not present in a previous version of the software and was introduced by a subsequent change. The term comes from the Latin regressus (going back): something that previously worked has gone back to being broken.

Regressions are particularly frustrating because the feature worked before. The cause is usually a change that fixed one thing while silently breaking another — either because the change was incorrect, or because a hidden assumption in another part of the code was violated.

A regression test is a test added specifically to prevent a known bug from reappearing. The workflow is:

1. A bug is found in production.
2. Before fixing it, write a test that reproduces the bug. It fails.
3. Fix the bug. The test now passes.
4. Keep the test permanently. If the same bug is ever reintroduced, the test will fail and catch it before it reaches production.

This is the minimal form of Test-driven development applied to bug fixes. Without the regression test, the same bug can be re-introduced months later by someone who was not aware of the original fix.

Automated test suites run in CI/CD pipelines are the primary mechanism for catching regressions. If a change breaks an existing test, the pipeline fails and the change cannot land until the test is fixed. The key is keeping the test suite green and treating any failing test as urgent — a test suite that is “mostly passing” gives no useful signal because you cannot tell new failures from pre-existing ones.