QA · English usage comparison
Regression vs Bug: English Usage Guide for IT Professionals
A bug is any defect in software. A regression is a specific kind of bug — functionality that worked before and broke after a change. Every regression is a bug, but not every bug is a regression. This distinction matters in release notes and post-mortems.
Side-by-side comparison
| Aspect | Regression | Bug |
|---|---|---|
| Was it ever working? | Yes — it worked before a change | Not necessarily |
| Cause | A specific code change broke it | Any cause |
| How found | Regression tests, CI, users reporting it | Any testing method |
| Severity signal | Higher — was verified working before | Varies |
Example sentences
Regression
- "The v2.4 release introduced a regression — user login worked fine in v2.3 but now fails on Safari."
- "Our CI regression suite caught the issue before it reached production."
Bug
- "There's a bug where the date picker accepts invalid dates — it has never worked correctly."
- "We found three bugs in the new feature during QA."
Exercises: choose the correct English usage
Select the best answer for each question, then check your reasoning.
1. Login worked in v1.0 but broke in v1.1. This is a ___.
Explanation: "Regression" specifically means something that used to work and was broken by a change.
2. A feature has never worked correctly since it was written. This is a ___.
Explanation: It's a bug, not a regression — it never worked, so no previous functionality was broken.
3. "We run ___ tests on every PR to catch things that used to work." Which word?
Explanation: "Regression tests" specifically check that previously working functionality still works.
4. Which sentence uses "regression" correctly?
Explanation: A regression broke something that previously worked — exactly as described.
5. In a post-mortem, a team says "root cause was a regression introduced in commit abc123." What does this mean?
Explanation: The commit broke something that worked before — that's a regression.
Frequently asked questions
What is a "regression test"?
A test that verifies previously working functionality still works after a change. Running the full automated test suite is the most common form of regression testing.
How do you find which commit introduced a regression?
"git bisect" binary-searches the commit history — it checks out commits and asks you to mark them good/bad until the culprit is identified.
What is "regression testing" in QA?
Systematically re-running tests after every change to ensure no existing functionality was broken. Automated regression suites make this continuous.
What does "introduced a regression" mean?
A specific change (commit, PR, deployment) caused something that previously worked to stop working.
Is a regression always someone's fault?
Not necessarily. Dependency updates, infrastructure changes, or time-sensitive bugs (e.g. year-2000-style issues) can introduce regressions without obvious blame.
What is a "flaky test" in the context of regressions?
A test that intermittently fails can mask real regressions (false positives) or cry wolf (false negatives). Teams often quarantine flaky tests to maintain trust in the regression suite.
What is "regression debt"?
The risk accumulated when regression tests are not written or maintained. The more untested code, the higher the chance a change introduces an undetected regression.
Can a regression be introduced by a dependency update?
Yes — upgrading a library can change behaviour your code depended on. This is why locking dependency versions and running regression tests after updates is important.
What does "bisect" mean in git bisect context?
"git bisect" uses binary search to find the commit that introduced a bug. You mark commits as good or bad; Git narrows down to the culprit in O(log n) steps.
What is "zero regressions"?
A team policy or release criterion that no previously passing tests may fail in a release. Ambitious but common in high-quality engineering teams.