Duplicate Test Cases: A Safe Way to Prune Without Losing Coverage

A tester opens the case repository looking for an existing login check before writing a new one. The search returns nothing useful, so they write it anyway. Three months later, someone else does the exact same thing. Nobody was careless. The repository just wasn't findable enough for either of them to know the other's case already existed. This is how duplicate test cases pile up on nearly every large suite, and it happens for structural reasons, not sloppy ones.

The instinct once someone finally notices the pile up is to bulk delete anything that looks similar by title. That instinct is how teams quietly lose coverage, because two cases with almost identical wording can assert completely different things underneath. This post lays out a safer order. Find candidates, compare what each case actually checks rather than its title, merge or archive instead of deleting outright, and fix the intake process that produced the duplicates to begin with.

Why duplicates appear in the first place

Duplicates are rarely a discipline problem. They're a findability problem wearing a discipline costume.

• No searchable, well organized repository, so a tester can't quickly confirm whether a check already exists before writing a new one
• No shared naming convention, so "login with valid credentials" and "user can log in successfully" describe the same case but never turn up in the same search
• A case written straight from a user story without checking existing coverage first, because checking felt slower than just writing it

A 900 case suite that grew over three years, through four different testers who never overlapped, is the textbook setup for this. Nobody did anything wrong individually. The system just never gave any of them a fast way to check first, so each person wrote the case they needed and moved on.

A five person QA team on a fortnightly release feels this differently but just as sharply. With no time between releases to review the suite, small overlaps accumulate release after release until the suite is a third longer than it needs to be and nobody remembers why.

The three kinds of duplicate

Not every near identical pair is the same problem, and treating them the same way is how coverage gets lost.

• Exact duplicates: two cases with the same steps and the same expected result, safe to merge without a second thought
• Near duplicates that assert different things: similar steps but a different expected result, like one case checking the error message text and another checking the field turns red
• Parameter variants: the same steps repeated for different input values, like testing a discount code field with five different code formats, which should collapse into one case with a data table instead of five separate cases

Only the first kind is safe to delete outright. The other two need a closer look before anyone touches them.

Why text similarity is the wrong test

Two case titles can look nearly identical and still test different things. "Checkout fails with invalid card" and "Checkout rejects invalid card" sound like the same case. One of them might check that an error message appears on screen. The other might check that the order is never created in the database at all.

Deleting one because the title matched the other is exactly how a real gap opens up in the suite. The expected result is what actually decides whether two cases are the same case, not the title and not even the steps. If the expected outcome differs, the case is not a duplicate, no matter how similar the wording looks on a first pass.

A safe pruning order you can run this week

1. Pull a list of suspected duplicates using title or tag similarity as a starting filter, not a final answer.
2. For each pair, read the expected result of both cases side by side before reading anything else.
3. If the expected results match exactly, mark it an exact duplicate and move to the merge step.
4. If the expected results differ, keep both cases and rename them so the difference is obvious in the title itself.
5. If several cases only differ by input value, convert them into one parameterized case with a data table.
6. Archive the case being removed rather than deleting it outright, keeping a record of what used to exist.
7. Note in the surviving case which older case it replaced, so anyone auditing later can trace the decision.

A person needs to approve every merge in this process. Even with a tool flagging likely duplicates by similarity, a person still has to confirm the expected results actually match before anything gets combined. Skipping that check is how a five minute cleanup turns into a missing regression check nobody notices until it matters.

Archive rather than delete

Deleting a case doesn't just remove some text. It usually takes the run history attached to that case with it. Every past pass, every past fail, every note a tester left explaining why something failed on a specific release, all of it goes with the case.

That history is often the thing you actually needed six months later, when someone asks whether a particular bug was ever caught before. Think of the Safari only checkout bug that reached a customer last year. If the case that once caught a related issue got deleted instead of archived, there's no record left to check against when the same symptom shows up again.

Archiving keeps the case out of active use without severing that trail. It costs almost nothing extra and it removes the risk of realizing too late that something valuable is gone for good.

Test case bloat, the sibling problem

Duplication isn't the only way a suite gets bloated. The other common failure is too many cases at too fine a granularity, where five nearly identical cases exist only because nobody thought to parameterize them.

A suite testing a discount code field with five separate cases, one per code format, is a candidate for this. The parameterize instead rule is simple. If the only thing changing between cases is an input value, it should be one case with a data table, not five cases a tester has to open individually. This cuts the suite down without losing a single check, and it's usually a faster fix than deduplication because there's no ambiguity to resolve first.

Fixing the intake, not just the symptom

Pruning a suite once feels good and then quietly stops mattering, because the same intake process that produced the duplicates the first time is still running unchanged. A quick review at the point a new case gets written, even just a search before saving, is far cheaper than a deduplication project a year later on a suite that's doubled in size again.

The fix doesn't need to be heavy. It can be as simple as requiring a search of the repository before a new case gets approved, or a naming convention that makes near duplicate titles collide in search results instead of hiding from each other. A team that adds this one step at intake usually finds the next cleanup project is much smaller than the last one.