Regression Suite Pruning Review (Retention)

Regression Suite Pruning Review (Retention)

1. 01

   Pull the last 90 days of test run history and rank every suite by flake rate and mean runtime

   Flag any suite that fails intermittently more than 5 percent of runs or takes longer than 12 minutes; those two signals drive most maintenance drag on a retainer.

2. 02

   Tag each test case with the client-facing surface it protects (checkout, signup, dashboard, admin)

   A case that guards a revenue path stays; a case that guards a settings toggle nobody touches in six months is a candidate for deletion.

3. 03

   Delete or quarantine every case with no failure in 12 months and no mapped surface

   Move quarantined cases to a parked folder rather than deleting outright, so the client can see the decision and reverse it if a release goes sideways.

4. 04

   Consolidate duplicate coverage where two suites assert the same behavior at different layers

   Keep the faster layer (API or component) and drop the slower end-to-end duplicate; a recorded workflow tool like CueCast replays in a real browser, so its cases are the expensive ones to keep in duplicate.

5. 05

   Re-baseline visual snapshots after any intentional design change ships

   Stale baselines generate false failures that erode trust in the suite; a screenshot API such as Scrinly or shot-scraper can regenerate region-level diffs without a full-page re-capture.

6. 06

   Set a hard ceiling on total suite runtime and enforce it at the next sprint boundary

   A common agency target is under 15 minutes for the pre-merge gate; anything longer gets split into a nightly tier so developers stop skipping the run.

7. 07

   Log the pruning decision in the client's QA changelog with the coverage delta

   State how many cases were removed, how many surfaces remain covered, and what the runtime dropped to; this is the artifact that justifies the QA line item at renewal.