Deleting a Test Case Shouldn't Delete the Evidence

Somebody clears out forty obsolete test cases on a Friday afternoon. Old onboarding flows, a payment provider you stopped using, a feature that shipped and got removed. Good housekeeping.

The interesting question isn’t whether those forty are gone. It’s what just happened to every run that ever exercised them — the execution history, the release sign-offs, the audit answer for last quarter.

In a tool where a run points at its test cases, the answer is: quite a lot, silently. Forty rows in old runs now reference something that isn’t there.

Delete is the most dangerous button in a QA tool

It’s dangerous in a specific and unusual way. Most destructive actions announce themselves — you notice a deleted file, a dropped table, a missing page. A deleted test case is the opposite. It removes the thing, and everything that referred to the thing keeps rendering, keeps counting, keeps appearing in reports. The damage is entirely in the past tense and entirely invisible from the present.

The worst deletes aren’t the ones you notice. They’re the ones that quietly change what history says.

So the first decision is that deleting a test case in Hawzu doesn’t erase it. It marks the case as deleted, notes who did it and when, and everything in Hawzu leaves marked cases out. The case disappears from the repository, from search, from pickers. Its data and its results stay where they are.

That’s not clever. It’s the standard move. What’s worth writing down is everything else the delete has to do at the same time — and the thing it deliberately doesn’t do.

A delete owes four things

Hiding the row is only the first, and it’s the one everybody remembers.

The second one is the interesting one, because it’s the easiest to omit and the most invisible when omitted. Nothing breaks. No error appears. Six months later a chart is quietly wrong and nobody can say when it started.

Both ways of deleting — deleting a case directly, and deleting a folder full of them — share one implementation for exactly this reason. Two separate versions each doing three of the four things correctly is the realistic failure, not one doing all four.

Your future — what the delete owes

1. Hide it everywhere gone from repository, search and pickers
2. Close off its history a final entry, value unchanged
3. One activity entry per case not one per request
4. Remove it from the coverage check or the generator skips an untested behaviour

delete

Your past — out of its reach

• Regression · March own copy · verdict kept
• Release 4.2 sign-off own copy · verdict kept
• Smoke · last Friday own copy · verdict kept

No restore · no trash · no undo

It does not owe you an undo

There is no restore. No trash, no recycle bin, no 30-day window.

This is worth being blunt about, because “hidden, not erased” sounds like it implies undo, and it doesn’t. Hawzu once had the beginnings of a recycle bin. It was never finished, and we removed it rather than leave half an undo lying around.

Hiding instead of erasing buys one thing: history stays honest. Deleting a case doesn’t touch a single execution record. Every run that exercised it still holds its own frozen copy — the title, the steps, the dataset, the verdict, the evidence — and reads exactly as it did before, because a run copies the case rather than pointing at it. The delete removes the case from your future. It has no reach into your past.

That’s the whole promise, and it’s smaller than “safe deletion” usually implies. Better to say what it is.

Deletion isn’t marked the same way everywhere

Here’s an unglamorous admission that turns out to matter.

Test cases, requirements and runs record a deletion one way. Defects and releases record it another way, and releases only half-formally: the marker is added by whatever deletes one, rather than being part of what a release is defined to hold.

Three conventions for one idea, arrived at the way these things always are: each was locally reasonable when it was written. It’s fine right up until something has to search across all of them. At that point every reader needs to know which convention each kind of record uses, and a reader that assumes wrong returns deleted records while looking completely correct.

We resolved it by making the discrepancy explicit in the one place that reads across everything, rather than by reworking every kind of record, which nobody had budget for. Not elegant. Honest, and cheaper than being wrong.

The one place things really get deleted

For completeness: hard deletion does exist, at exactly one scale — purging a whole project after it’s been deleted and served out a grace period.

That purge works from a written list that sorts every kind of project data into purge-this or keep-this, and a new kind of data that appears on neither side is caught before it ships. The failure it prevents is a new feature adding a new kind of data that quietly survives project deletion for years, holding customer data nobody remembers exists.

Which is the same principle as the final history entry, one level up: the dangerous part of deleting isn’t what you remove, it’s what you forget to.

The practical payoff is that a suite can be pruned on a schedule. Once deleting a case can’t damage the runs that used it, retiring tests becomes routine maintenance rather than a risk.

Deleting a test case should change your future. It should have no reach into your past.