In a TestRail-class test case repository, how does archiving a case differ from deleting it, and what happens to the executions already recorded against it?
answer
- one hides, one destroys
- history needs the row to survive
- reversible versus terminal
- watch a closed cycle's totals
- cascade behaviour is the tool's choice
basics
~20 sArchiving hides a case from authoring and selection while keeping its record and execution history intact. A hard delete removes the record itself, so past results and inbound references lose the row they resolved against.
solid answer
~40 sArchiving is a state change: the record stays, keeps its identifier and stays resolvable, but the tool filters it out of the authoring tree, search and cycle selection so nobody plans it into new work. Every execution already recorded against it still resolves to a real case, so an old run still reads as a run of named cases and its totals do not move. A hard delete removes the row. Depending on the product, executions are cascaded away — old runs lose rows and their totals change retroactively — or they survive as records whose case reference no longer resolves, rendering as a bare identifier or a stored title snapshot. Archiving is reversible; a hard delete is not, beyond a restore window or a full database restore.
go deeper
Be ready to say which one is reversible: archiving is a state you can undo, deleting removes the record for good. Name the execution history as the thing at risk.
Explain that executions are separate records naming a case, and that a delete either cascades to them or leaves them pointing at nothing — and that which behaviour you get is the tool's decision, not yours.
Show that you verify cascade behaviour in a scratch project before deleting anything in a real estate, and that you would notice a signed-off cycle whose totals moved after the fact.
Own the policy: which records may ever be hard-deleted, who is permitted to do it, and how the estate can later prove that a shipped release's evidence was never altered.
## Two operations, not two words for one thing A **managed case repository** — a TestRail-class tool that owns the case tree, or a Jira-resident tool such as Xray or Zephyr where each case lives as an issue inside the tracker — stores a case as a durable record with a stable identifier. Almost everything else in the estate points at that identifier: the executions recorded in past cycles, the mapping from an automated script to the case it stands for, requirement and defect references, the folder that holds it, and the totals on every report built from those rows. **Archiving** changes state and nothing else. The record survives with its identifier, its history and its links; the tool simply stops offering it. It drops out of the default folder view and out of search, and it can no longer be selected into a new cycle. Authoring is usually frozen too, so the archived text stays the text that was last true. **Hard deleting** removes the record. The identifier stops resolving. Anything still holding it is now holding a reference to something that is not there. ## What becomes of the executions An execution is a **separate record** — outcome, actor, timestamp, evidence — that names a case. Removing the case does one of two things, and which one you get is a product decision you should establish before you delete anything real: | Removal | Executions | How a past run reads afterwards | |---|---|---| | Archive | untouched, still resolve | unchanged: same rows, same totals, same names | | Hard delete, cascading | removed with the case | rows vanish; a closed run total shrinks retroactively | | Hard delete, non-cascading | rows survive, orphaned | rows render as a bare identifier or a stored title | The cascading variant is the dangerous one, because it rewrites **closed** history. A cycle signed off with a hundred passes now reports ninety-four, and the report is not lying — the evidence it summed is gone. The non-cascading variant preserves the count but degrades the reading: you can still see that something passed, but not what it asserted. ## Why the default should be archive - **Evidence is the point.** Test records exist to say what was verified before a release shipped. Retiring a case is a statement about the future; the past still needs a name to hang on. - **Reversibility.** A wrong archive is one state change away from being fixed. A wrong delete is a restore-from-backup away, if that. - **Reference integrity.** Automation mappings and inbound references keep resolving, so nothing elsewhere quietly turns into a dead pointer. - **The tree stays workable.** The case is out of the way of people planning work, which is the actual complaint that prompted the removal. ## What archiving does not fix Archiving has its own failure modes, and a good answer names them: 1. **Filtered, not gone.** A saved filter or an ad-hoc query written against raw attributes can still pick up archived cases, so a retired case reappears in an export or a listing that bypasses the default filter. 2. **Reachable by link.** A direct link still opens the case. That is the feature — old evidence must stay readable — but people mistake reachability for currency and re-run retired work. 3. **The heap moves, it does not shrink.** Archiving addresses selection noise, not navigability of the archive itself; without a retention rule the archived layer becomes its own unbrowsable pile. 4. **Frozen text drifts.** An archived case describes behaviour that may since have changed, and a reader of old evidence needs to know they are reading a historical statement rather than a current one. ## Deciding, in practice 1. Establish what a hard delete does to executions **in this tool**, by trying it in a scratch project rather than in the live estate. 2. Default to archive for anything that was ever executed, linked, or referenced by an automated run. 3. Reserve hard delete for records with no history worth keeping: a duplicate created and never run, an import that landed in the wrong folder. 4. When a delete is genuinely right, do it while the restore window still protects you, and check afterwards that the totals you care about did not move. 5. Record the removal somewhere durable, so the next reader of a shrunken total knows why it shrank. **The short form:** archive is a visibility decision, delete is a data decision. Interviewers pair them because candidates who have only ever used one assume the other is the same thing with a firmer name, and that assumption is exactly what destroys history.
- Your tool has no archive state at all, only delete. What do you do with a retired case that has years of executions behind it?Simulate one. Move it into a folder the selection views exclude, mark it retired through whatever attribute your filters read, and freeze editing by convention. It is weaker than a real archive state, because a hand-written filter can miss it, but it preserves the record and its history, which a delete cannot.
- Why is we can always restore from a database backup a weak answer to losing a deleted case?A backup restores the whole database at a point in time, not one case. Putting it back means either rolling back everyone else's work since that point, or extracting rows by hand and re-inserting them with their original identifiers — a manual, error-prone job that nobody has rehearsed and that usually gets abandoned.
Archiving is moving a book into the closed stack: the catalogue entry still resolves and every citation still lands. Deleting is pulping it, and every citation that named it now points nowhere.
saying these in an interview costs you the question
- Says archive and delete are the same with different names
- Assumes deleting a case never touches its recorded executions
- Thinks a closed cycle's totals can never change retroactively
- Deletes cases purely to tidy the folder tree
- Believes a database backup makes any deletion reversible