Regression
A regression is a new defect where behavior that previously worked stops working after a change.
It commonly appears after a code change, configuration update, plugin change, or deployment.
What it does
A regression introduces breakage into an area that used to behave correctly.
It is commonly used to describe:
- Functionality that worked before and is now broken
- New issues caused by an update or release
- Unexpected side effects from a fix or feature
- Behavior changes that reduce quality or trust
Core concepts
Previously working behavior
The key idea in a regression is that the problem was introduced by change.
If something never worked in the first place, that is a bug, but not necessarily a regression.
Change-related failure
Regressions often appear after:
- Feature work
- Refactoring
- Version updates
- Environment changes
- Emergency hotfix work
QA and release quality
Regression testing is part of QA because teams want to ensure old working behavior still works after new changes.
Common use cases
- Broken functionality after a deployment
- Design or layout breakage after an update
- Plugin or theme conflicts in WordPress
- Unexpected failures after a hotfix
- Workflow changes that damage existing user journeys
Practical notes
- Regressions are often especially frustrating because they reduce trust in change processes.
- Good QA and staging help catch regressions before production.
- Regression risk usually increases when releases are large, rushed, or poorly tested.
- When regressions hit production, teams may need a rollback or a fast hotfix.
Frequently Asked Questions
Is every bug a regression?
No. A regression specifically means something that used to work has broken after a change.
How do teams prevent regressions?
Through QA, regression testing, staged releases, and careful review before deployment.
What happens if a regression reaches production?
Teams may fix it with a hotfix or revert it through a rollback, depending on severity and timing.