In a managed test case repository, what is the difference between a test cycle that stores a snapshot copy of each case and one that holds a live reference to it?
answer
- two ways to hold a case in a cycle
- copy taken on add, or a pointer
- edit the master, reopen the item
- reproducibility versus propagation
- snapshots insulate; references follow
basics
~20 sA snapshot cycle copies each case's text when the case joins it, so later edits never change what the cycle shows. A live-reference cycle stores only a pointer, so every edit to the master case appears immediately inside the open cycle.
solid answer
~40 sA cycle has to record something about each case it contains, and there are two models. Under **snapshot** (copy-on-add) the repository copies the case's title, preconditions and ordered steps into a record the cycle owns; editing the master afterwards writes a new master revision and leaves the open cycle untouched. Under a **live reference** the cycle stores only the case identifier and renders the master's current text every time an item is opened, so an edit reaches the next tester immediately. The trade runs one way in each direction: snapshots buy reproducibility and pay in propagation, because a genuine correction never reaches cycles that already copied the mistake; live references buy propagation and pay in reproducibility, because a result recorded yesterday now sits under wording nobody executed.
go deeper
Be able to state both models in one sentence each: the cycle keeps its own copy of the case text, or the cycle keeps only a pointer and shows the master's current text.
Explain when the copy is taken, which fields it covers, and why the same edit is invisible under one model and immediate under the other. Name the propagation cost snapshots create.
Show you check the model before trusting a cycle's numbers, and describe the concrete failure each side produces: stale steps executed for weeks, or verdicts left under rewritten wording.
Own the choice for a repository: which model your release evidence and reporting can live with, what refresh or freeze process fills the gap, and what you accept losing either way.
## What a cycle stores about each case A **test cycle** - a run, an execution set, a sprint's test round; products name it differently - is the object that says *these cases, executed by these people, against this build*. Whatever it is called, it has to record something about each case it contains, and there are only two honest answers. **Snapshot, or copy-on-add.** When a case enters the cycle, the repository copies the case's executable text into a record the cycle owns: title, preconditions, the ordered steps with their expected results, the data written into those steps, sometimes the attachments. From then on the cycle renders its own copy. Editing the master case writes a new master revision and touches nothing inside the open cycle. **Live reference, or pointer.** The cycle stores the case identifier and nothing else. Each time an item is opened, the repository renders whatever the master case says *now*. An edit made while the cycle is open reaches the next person who opens that item - including a tester halfway down the list whose colleague already recorded a pass against the old wording. ## The trade the two models make | | Snapshot copy | Live reference | |---|---|---| | What the cycle holds | its own copy of the text | an identifier | | Master edited mid-cycle | open cycle unchanged | visible on the next open | | A real correction | pushed or re-added per cycle | reaches everyone at once | | Reproducing what a tester read | read the cycle's copy | needs a recorded revision | | Storage | grows with cycles times cases | one definition, many pointers | | Risk it creates | stale instructions executed for weeks | verdicts detached from wording | Read the table as one trade made twice: **a snapshot buys reproducibility and pays in propagation; a live reference buys propagation and pays in reproducibility.** Neither is a defect, and a product is not better for choosing one. ## Where each model actually hurts - Under **snapshot**, a genuinely wrong step - an expected result that contradicts the requirement - is now wrong in every open cycle that copied it, and fixing the master fixes none of them. Teams usually discover this when the same bad step is reported by three testers on three cycles after the master was already corrected. - Under **snapshot**, "the copy" is often only text. Attachments and files the steps point at may still be references, so frozen instructions can quietly start describing different bytes. - Under **live reference**, a pass recorded before a rewrite ends up sitting under text nobody executed, and nothing on screen distinguishes it from a pass recorded after. - Under **live reference**, two testers in the same cycle can be executing different instructions while the cycle's totals add them together. - Under **live reference**, structural edits hurt more than wording edits: deleting or reordering a step can leave per-step outcomes attached to positions that no longer mean what they meant. ## Working out which model a product uses The two models look identical until something is edited, so establish it deliberately rather than assuming: 1. **When is the copy taken** - at cycle creation, or when each case is added? A cycle whose membership grows over a week may hold copies taken on several different days. 2. **Is a refresh offered**, per item or per cycle, and what does it do to results already recorded against the older copy? 3. **Which fields are copied and which stay live?** Many repositories copy the steps but resolve the title, folder, priority and links at render time. That hybrid is common and surprising. 4. **Does the execution record the revision it ran against?** In a live-reference repository that single piece of provenance is the difference between "what did the tester read?" being unanswerable and being answerable. The quickest empirical test takes two minutes: put one case into an open cycle, change one word of its first step in the master, and reopen the cycle's item. If the word changed, the cycle holds a reference; if it did not, it holds a copy - then change the title as well, to find out whether the product is really a hybrid. ## Why this reaches past one cycle Every downstream artefact inherits the choice. A coverage view, a release summary, an exported result set and a defect's reproduction steps all quote case text, and each is quoting either the cycle's copy or the live master. Under a live model those quotations keep changing after the fact, which is why the model belongs on the short list of things you establish about a repository before trusting a number it produced.
- If a repository lets you refresh a cycle item to the latest case text, what should happen to a result already recorded on it?The safe behaviour is to keep the result but mark it as recorded against superseded text, so the cycle's totals stop implying the new wording passed. Silently keeping the verdict is the dangerous option; silently clearing it destroys real evidence. If the product does neither, refresh only items that are still untested and add the new text as a fresh item instead.
- Does snapshotting a case into a cycle mean the cycle is immune to everything that happens to the master afterwards?No. The copy usually covers text only. Attachments, linked requirements, folder placement and reusable content may still resolve live, so a snapshot cycle can still shift under you. It also does not protect against the master being reorganised out from under a report that groups by folder. Treat a snapshot as covering exactly the fields the product says it copies, not the whole case.
A snapshot cycle is like photocopying the exam paper before handing it out: rewriting the master mid-exam changes nothing for the candidates sitting it. A live-reference cycle hands out a link to the master, so a rewrite changes what later candidates read while earlier answers were written against something else.
saying these in an interview costs you the question
- Assuming every tool freezes case text into a cycle
- Believing a snapshot copies the attachments too
- Treating live references as simply the modern, better model
- Thinking an open cycle locks the master case from edits
- Confusing cycle membership with what the cycle stores