Skip to content

Retesting & Regression Testing

The goal is to ensure new changes didn't break existing functionality. All test cases should be logged in ClickUp under Trove > Test Cases.

Definitions

Retesting — confirms that a specific bug reported earlier has been successfully fixed by the developer.

Regression Testing — ensures that new code changes or bug fixes have not broken existing functionality that was previously working.

Benefits

Retesting:

  • Direct confirmation of fixes
  • Improved build confidence
  • Efficiency in targeted validation
  • Reproduction verification

Regression Testing:

  • Safeguards against side effects
  • Preserves system integrity
  • Identifies defects early
  • Reproduction verification

Practice flow

Bug Found → Logged during test execution phase
Developer Fixes → New build is released for testing
Retest → Confirm the bug has been fixed
Regression Testing → Run a small test on related features to check for side effects

Automated regression

API endpoints and key customer flows that have automated e2e coverage are regression-tested automatically on every pull request — no manual re-run needed for those areas. When scoping a regression pass, check Automated Testing first to see what is already covered so you can focus manual effort on areas that aren't.

If a bug is found in a module that has no automated coverage, consider whether a test should be added as part of the fix so the same regression can't slip through undetected in future.

Regression testing process

1. Identify impacted areas

Determine which modules are related to the recent code change and map how different modules interact.

Example: A change to the Payment Gateway might unexpectedly affect Order Confirmation.

2. Select a "stability check" subset

Don't redo all system testing — pick a subset of core, high-priority test cases:

  • Core functionalities — critical paths like login, checkout, and search
  • High-priority cases — features with high usage or that have historically been prone to defects
  • Risk-based selection — prioritise test cases covering areas most likely to be affected by the change

3. Execute the selected test cases

Re-run the existing test cases against the new build.

4. Check for side effects

Look for unintended changes caused by the fix.

Example: A developer adds a "Search by Colour" filter. Side effect: the "Sort by Price" filter can no longer be seen on screen.

When to start retesting

Begin retesting when:

  • Bug status changes to Fixed, Resolved, or Ready for QA
  • A new build is available

Retesting checklist:

  • Retest the exact scenario from the original bug report
  • Test the happy path scenario
  • Reuse the test case where the bug was originally reported
  • Close the bug if fixed — or change the status to Re-Open if the bug still occurs

ClickUp setup tips

  • Create a dedicated list for regression test cases (e.g. tasks like "User Login" or "Checkout")
  • During every sprint or release, create a list template with reusable test cases
  • Use Custom Fields to label tests by type (e.g. Regression) and priority (High, Medium, Low)
  • Log all regression test cases under Trove > Test Cases > Regression Testing