Skip to main content

Regression Bugs

A regression bug is a bug that causes a completed feature that worked correctly to stop working after updates (e.g., system upgrade, system patching, or bug fixes). This definition applies both before and after releasing the feature to customers.

Note: A change in a feature behavior or the removal of one feature through a requirement or a business input is not a regression bug. It is a normal development activity.

This guide describes the relevance and policies of regression bugs. Together with other bug-related guides, it provides information to help ensure correct handling of all types of bugs. It relates to PCP R&D’s overall bug management process, described in How-to Manage Bugs, as visualized below.

MB-G

Why regression bugs?​

Some reasons to identify and manage regression bugs are:

  • From a customer point of view, they could damage the perceived quality of our products, because something that was working before is broken.
  • From an R&D point of view:
    • Understanding their root cause can lead to improvements and prevent more bugs (e.g. more effective impact analysis, code review, or regression tests).
    • Regression bugs can be prioritized in a release before they impact customers.

What to do with regression bugs?​

Once a regression bug has been identified:

  • If the release is still in progress, it must be fixed in the same release (unless the CCB approves an exception).
  • If the regression bug is open on a release already delivered, it must be properly planned and prioritized in the product backlog by the product owner.

Relevant fields​

Regression: "False" by default, "True" if the bug is a regression bug.

This field can be set:

  • When the bug is created, for example, if the bug was found during a regression test.
  • Later when someone realizes that it is a regression bug.

Query example​

RBG

Owner: Configuration Management Team