Modules
Intermediate⏱ 6 min read

Regression Testing

sign in to track

Regression testing is the process of retesting existing functionality after changes are made to the software to make sure that previously working features have not been broken.

A change in one part of an application can sometimes affect other parts of the system. Regression testing helps identify these unintended side effects.

Regression testing is especially important when the application is updated frequently because every new change can potentially introduce a regression.

Example

Suppose an e-commerce application already allows users to:

  • Log in.

  • Search for products.

  • Add products to the cart.

  • Apply discount codes.

  • Complete payments.

The development team then changes the discount calculation logic.

The tester should not only test whether the discount now works correctly. They should also check related existing functionality, such as:

  1. User login still works.

  2. Product search still works.

  3. Products can still be added to the cart.

  4. Cart totals are calculated correctly.

  5. Payment still works correctly.

  6. Orders can still be completed.

The change was made to the discount functionality, but it could unintentionally affect other parts of the checkout process.

When Is Regression Testing Performed?

Regression testing may be performed after:

  • New features are added.

  • Existing features are modified.

  • Bugs are fixed.

  • Code is refactored.

  • Database changes are introduced.

  • Configuration changes are made.

  • Third-party integrations are updated.

  • A new software build or release is prepared.

The exact regression scope depends on the size and impact of the change.

Regression Testing Process

A typical regression testing process can include:

1. Identify the Changes

Understand what functionality has been added, modified, or fixed.

2. Identify Affected Areas

Determine which existing features could be affected by the changes.

3. Select Regression Tests

Choose relevant existing test cases that cover the affected functionality and related areas.

4. Execute the Tests

Run the selected regression tests and compare the actual results with the expected results.

5. Report Defects

If previously working functionality no longer works as expected, report the issue as a defect.

6. Update the Regression Suite

When necessary, add new test cases or update existing ones so future regression testing covers the changed functionality.

Manual vs Automated Regression Testing

Regression testing can be performed manually or through automation.

Manual Regression Testing

  • Testers execute regression test cases manually.

  • Useful when the regression scope is small or the functionality requires human judgment.

  • Can become time-consuming when the same tests need to be repeated frequently.

Automated Regression Testing

  • Automated scripts execute predefined regression tests.

  • Useful for repetitive and frequently executed tests.

  • Can run as part of CI/CD pipelines.

  • Provides faster feedback when software changes are introduced.

  • Requires ongoing maintenance when the application changes.

For large and frequently changing applications, teams often use automated regression tests together with targeted manual testing.

Regression Testing vs Retesting

These two terms are often confused.

Retesting

  • Checks whether a specific defect has been fixed.

  • Focuses on the functionality where the defect was originally found.

  • Example: A login bug was fixed, so the tester checks whether the login issue is now resolved.

Regression Testing

  • Checks whether a change or fix has negatively affected existing functionality.

  • Can cover the changed area and related areas.

  • Example: After fixing the login issue, the tester also checks related functionality such as logout, password reset, and session handling.

In simple terms:

Retesting → "Is the specific bug fixed?"

Regression Testing → "Did the change break anything that was already working?"

◈Key Points

  • Regression suites grow over time and must be actively pruned of obsolete or duplicate tests.
  • Prioritise regression tests by risk: features used frequently, features recently changed, and historically buggy areas.
  • Full regression on every commit is impractical — use risk-based, tiered regression strategies.
  • Automated regression testing in CI pipelines is the industry standard.
  • Track regression defect rate over releases — an increasing rate signals deteriorating code quality.
⚡ Expert Pro Tip

Tag tests by component/feature so you can run targeted regression on only the areas affected by a code change. This cuts CI time dramatically without sacrificing coverage.