[Question of the Week] What do you do when there are too many test cases to actually maintain?

Web Testing
1

Dear Community,

Most suites get here eventually. Someone adds a case for a bug that shipped two years ago. Someone copies a whole suite to cover one browser. Eighteen months later, nobody wants to be the person who deletes anything, so the suite keeps growing and the run time grows with it.

The part I find interesting is that people usually know which tests are dead weight. They just don’t have a defensible way to justify removing them.

So: how do you handle it?

2

I don’t delete on first pass — I quarantine into a separate suite (still versioned, not run in the main pipeline) for a sprint or two. If nobody notices it’s gone and nothing slips through, then I have a separate session with team on Quarantine test and then finally delete for real.

Once the number keeps on mounting then my logic to weed out test by focusing on risk-based coverage and business-critical workflows first.

3

A few practices that have helped me:

  • Regularly review and retire obsolete or duplicate test cases.
  • Merge similar scenarios into data-driven tests instead of creating separate test cases.
  • Prioritize automation for high-risk, high-frequency, and regression-prone areas.
  • Break large end-to-end tests into reusable components to reduce maintenance effort.
  • Track test value: if a test rarely finds defects and costs a lot to maintain, reconsider whether it still deserves a place in the suite.
4

I treat the suite like code: measure, prune, and enforce rules so it doesn’t grow back out of control.

1. Measure first (so it’s not “opinion”)

Run an audit and collect:

  • Tests not executed in the last 90 days

  • Tests that never fail (0 failures in 6–12 months)

  • Top 10 slowest tests

  • Top 10 flakiest tests (fail >5% of runs)

  • Tests covering deprecated features or old flows

This gives you data-backed candidates for removal or refactoring, not just gut feeling.

2. Prune with clear criteria

I remove or quarantine tests that:

  • Haven’t run in 90+ days

  • Have never caught a real bug (no failures in a year)

  • Are duplicates of other tests (same flow, same assertions)

  • Cover functionality that no longer exists or is sunset

I document this as: “Retired: no executions in 90 days, no failures in 12 months, feature deprecated in Q2.” That makes it defensible in reviews.

3. Shift from “more tests” to “better tests”

I enforce rules like:

  • Every new test must explain what risk it covers that existing tests don’t

  • Prefer API-level tests for business logic; keep UI tests for critical user flows only

  • Use data-driven tests instead of copying suites per browser/environment

This stops the suite from re-growing to the same problem.

4. Make maintenance part of the process

  • Quarterly suite audit: remove tests not run / not failed in 90 days

  • Flake budget: any test failing >5% gets quarantined or fixed within a sprint

  • Owner per test, shown in CI failure messages