Quick answer: A regression is a defect in functionality that previously worked correctly, almost always caused by a recent change. It can mean a fixed bug coming back or a working feature breaking after an update. The defining trait is that it is new breakage in old, working behavior, the game went backward in quality.
"Regression" is one of the most important words in software quality, and it captures a specific, frustrating kind of bug: not a new feature that is broken, but old, working functionality that a change has broken. Regressions are why every update is a risk, and why testing focuses so heavily on making sure new changes do not break what already worked. Understanding regressions explains a lot about how careful release processes are designed.
What Makes a Bug a Regression
The key distinguishing feature of a regression is that the functionality used to work. A brand-new feature that has bugs is not a regression, it never worked. A regression is specifically backward movement: behavior that was correct in a previous version is now broken. This includes two common cases: a previously-fixed bug that has returned, and a feature that worked fine but stopped working after an unrelated change.
Regressions are almost always caused by change. You modify code to add a feature or fix a bug, and that modification has an unintended side effect on something else that was working. Because software is interconnected, a change in one place can break behavior in a seemingly unrelated place, and that broken-by-change-elsewhere quality is the essence of a regression.
Why Regressions Are So Damaging
Regressions are particularly costly because they violate trust. Players who saw a bug fixed and then watch it return, or who relied on a feature that suddenly breaks, lose confidence that your updates are safe. A regression makes an update feel like a step backward, which is worse than the update simply not improving things. For live games shipping continuous updates, uncontrolled regressions can make every patch a gamble players come to dread.
They are also insidious because you often do not notice them, you tested the new feature, not the old one you accidentally broke. A regression can ship silently and only surface days later when players hit the now-broken old functionality, by which point it is already affecting your reviews and your reputation for reliability.
Catching and Preventing Regressions
The standard defense is regression testing: re-verifying that existing functionality still works after a change, especially for the features and past bugs that matter most. Automated regression tests run on every build to catch reintroduced bugs cheaply. For things you cannot automate, a documented checklist of critical behaviors to re-verify before release serves a similar purpose.
In the wild, version-aware crash and bug reporting catches regressions fast. A bug that appears only on the new version, and was absent before, is a regression you just introduced. Bugnet tags every report and crash with its build version, so an issue that suddenly starts occurring on the latest release, especially one you thought was fixed, stands out immediately as a regression, letting you catch and re-fix it before it spreads instead of discovering it weeks later through reviews.
A regression is the game going backward, old, working behavior broken by a new change. It's why every update is a risk worth testing against.