In a test management tool that offers a soft delete for test cases, what actually happens when you delete a case, and what does the restore window let you do?
answer
- a flag, not an erasure
- hidden now, removed later
- a clock is running
- the identifier is what comes back
- retyping it makes a different case
basics
~20 sA soft delete marks the case removed and hides it, but keeps the stored record for a limited window. Restoring inside that window returns the case with its identifier and history; after it, a cleanup removes the record permanently.
solid answer
~40 sA soft delete is a flag, not an erasure. The case disappears from the tree, from search and from cycle selection and behaves to everyone as if it were gone, but the row is still stored with its identifier, its history and its links intact. Inside the restore window someone can undo it, and the case comes back where it was rather than as a fresh copy with a new identifier — which matters, because a re-created case is a *different* case to every execution and every inbound reference. When the window closes a background cleanup removes the record for real, with all the consequences of a hard delete. So a soft delete is a delayed hard delete with an undo attached, not an archive: it is a decision to lose the case, deferred.
go deeper
Say plainly that the case is flagged and hidden rather than erased, and that restoring it inside the window brings back the original rather than making a copy.
Explain the cleanup that runs at the end of the window and why it has the same effect as a hard delete, and why identifier continuity is what makes a restore different from retyping the case.
Demonstrate that you establish the window's real behaviour and its reach before relying on it, and that you check the estate after cleanup runs rather than on the day of the delete.
Be ready to argue where the window belongs in a wider removal policy: what it protects against, what it cannot protect against, and why it is not a substitute for an archive tier.
## What a soft delete actually is In a managed case repository — a TestRail-class tool, or a Jira-resident one such as Xray or Zephyr — a **soft delete** sets a state on the record instead of removing it. The tool then hides the case everywhere a person would meet it: the folder tree, search results, cycle selection, and any picker that offers cases to add. To ordinary use it is gone. Underneath, the row is completely intact: identifier, steps, expected result, revision trail, links, and every execution recorded against it. That gap between *appears gone* and *is gone* is the whole feature. Deleting a case is one of the few destructive operations an ordinary author can perform, and it is usually performed quickly, from a list, on the wrong row. ## The restore window The **restore window** is the interval between the flag being set and the cleanup that acts on it. Two things vary by product, and you should establish both rather than assume them: - **What a restore actually restores.** The record always comes back; whether it lands in its original folder, with its original links reattached, is not universal. - **Who controls the window.** In some tools it is a fixed platform behaviour; in others an administrator configures it, and in a few there is no window at all — delete means delete. When the window closes, a cleanup job removes the record. From that moment the situation is identical to a hard delete: the identifier stops resolving, and anything still holding it holds a dead reference. ## Why restoring is not the same as retyping the case This is the part candidates miss. A restored case is the **same** case; a re-created one merely looks like it. | | Restore inside the window | Re-create by hand | |---|---|---| | Identifier | the original, resolving again | new; old references stay broken | | Execution history | still attached, because it never detached | absent; old runs still name the old identifier | | Revision trail | intact | starts empty | | Inbound references | resolve again automatically | each must be repointed by hand | Every consumer of a case — a past execution, an automated run reporting a result, a link from a defect — refers to the identifier, not the wording. Reproducing the wording reproduces nothing that mattered. ## Three states, three different promises - **Archived** — a permanent-by-default visibility change. Reversible, history preserved, nothing is scheduled to happen to it. - **Soft deleted** — a delete you have not finished. Reversible for now, and a clock is running. - **Hard deleted, or cleaned up after the window** — terminal. The common mistake is treating soft delete as a gentler archive because both make the case vanish from the tree. They express opposite intentions: archive means *not for new work*, soft delete means *this should not exist*, and only one of them still holds the record next quarter. ## Operating around the window 1. **Find out whether your tool has one.** Not every repository does, and discovering it during an incident is expensive. 2. **Know who can restore**, and make sure that capability is genuinely reachable — a window nobody can act inside is decoration. 3. **Treat the window as a review period, not as storage.** It is there so a mistake gets caught, not so you can defer the decision. 4. **Prefer archive whenever the intent is not any more**, and use delete only when the intent is this should never have existed. 5. **Check the estate after cleanup, not after the delete.** Nothing breaks on the day you press the button; things break when the record actually goes. ## Where teams get burned - Assuming the window is long, and only discovering its real length when it has already passed. - Assuming a restore reattaches everything, then finding a case back in the tree with links that must be rebuilt by hand. - Bulk-deleting a folder subtree, restoring it, and getting the cases back without the placement that made them findable. - Treating the window as an archive of last resort, so retired-but-valuable cases quietly time out and disappear. A soft delete buys you time to notice a mistake. It does not decide anything for you, and it is not a place to keep things.
- The restore window has closed on a case you needed back. What are your options?Two, and both are poor. Recover the estate from a backup taken before the cleanup and extract the record, which means rehearsing a restore nobody has rehearsed; or re-create the case, accepting that it is a new case to every execution and reference. The real lesson is that the window is the control, so anything anyone might dispute should have been archived instead.
- How do you tell a soft-deleted case from an archived one, when both are simply missing from the tree?By what the tool still lets you do with it. An archived case opens by direct link, keeps naming itself in old executions, and can be brought back by anyone with authoring rights. A soft-deleted case is generally unreachable, is listed only among records awaiting cleanup rather than in the tree, and has an expiry attached.
A soft delete is the drawer between the desk and the shredder: the paper is out of sight, still whole, and on a timer.
saying these in an interview costs you the question
- Calls soft delete a gentler form of archiving
- Assumes a re-created case inherits the old case's history
- Thinks deleted cases stay recoverable indefinitely
- Believes hiding the case is the whole of the deletion
- Uses the restore window as long-term storage