Regression bug
A regression bug is behaviour that worked in an earlier build and stopped working after a later change, without anyone intending to change it. The defining fact is the working version behind it: somewhere there is a build where the same steps produced the right result, which is what separates a regression from a feature that was never right.
The longer version
The pair of builds is most of the report. A defect that has always been there is described by what it does; a regression is described by what changed, so a useful report names a version where the behaviour was correct and a version where it is not. That pair turns the investigation into a search over a known range of changes. Without it, the same investigation is a search over the whole history.
Regressions come from the shared parts of a system rather than from the part somebody edited. A helper two features call, changed for one of them. A dependency upgrade that tightened a validation. A fix that removed a side effect another screen quietly relied on. A merge that restored an older version of a file. The recurring shape is that the change and the damage sit in different places, which is why the person who wrote the change is rarely the person who notices.
A returning defect is the other kind of regression and behaves differently in a tracker. Something was reported, fixed and closed, then came back a few releases later because nothing held the fixed behaviour in place. The record for it already exists, with its steps and its original evidence, so the cheaper first move is to reopen that ticket rather than file a new one and lose the history of the first fix.
Triage usually weighs a regression above a defect of similar damage that has always been there, because a regression removes something people had already built a habit around and it arrived in a release the team can name. What decides the cost of finding it is how long it went unnoticed. Caught in the build that caused it, the suspect list is one change set. Caught six releases later, the suspect list is everything shipped since, and the pair of builds in the report is the only thing narrowing it down.
Common questions
What is the difference between a regression bug and an ordinary bug?
A regression describes behaviour that used to work; an ordinary defect describes behaviour that never did. The difference is practical rather than academic. A regression has a last known good build behind it, so the search starts from a range of changes, while a defect that was always there has to be traced from the code.
What causes regression bugs?
Shared code and shared assumptions, mostly. A helper called from two places and changed for one of them, a dependency upgrade that tightened a rule, a fix that removed a side effect something else depended on, or a merge that restored an older version of a file. The change and the damage usually sit in different parts of the system.
How do you stop a fixed bug from regressing again?
By leaving a test behind that reproduces it, so the behaviour is checked on every later change instead of being remembered by whoever fixed it. Reopening the original ticket when it does come back helps for a separate reason: the history of the first fix is the fastest available description of what has been undone.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.