Some case repositories copy a case's steps into a cycle but resolve its title, folder and links live. What surprises does that mixed model produce?

## Why products mix the models at all Copying is not free. The steps of a case are the bulk of it, and duplicating them per cycle is a real storage and search cost; metadata is small but is exactly what people want to be current - a renamed case should look renamed, a reorganised folder should group reports the new way, a link to a requirement should follow the requirement. So products split the difference, and most of them do it without announcing it. The result is the **hybrid**: part copy, part pointer, in one item. A typical division looks like this, though every repository draws the line somewhere slightly different: | Part of the case | Commonly copied | Commonly live | |---|---|---| | Ordered steps and expected results | yes | - | | Preconditions and inline test data | usually | sometimes | | Title and description | sometimes | often | | Folder placement, owner, priority, tags | rarely | usually | | Links to requirements and defects | rarely | usually | | Attachments | the pointer, not the bytes | effectively yes | ## The surprises, and where each one shows up - **An item that contradicts itself.** The steps are the originals; the title above them is the rewrite. A tester reading a cycle report sees a name that never appeared during execution, which makes the result look like it belongs to a different case. - **Reports that regroup after the fact.** If folder placement is live, reorganising the tree changes how a months-old cycle is grouped and totalled. The numbers do not change, but which bucket they fall in does, and a comparison against last release's report stops lining up. - **Attachments that change under frozen steps.** A step reading "use the attached data file" is stable text pointing at unstable bytes. Replace the file and the frozen instruction now means something else - the worst version of this failure, because nothing on the item looks edited. - **Links that answer differently than they did.** If the case's links to requirements are resolved live, the coverage the cycle appears to demonstrate can grow or shrink long after the cycle closed, without a single result changing. - **A correction that half-arrives.** Fix a case and rename it in the same edit: open cycles get the new name and keep the old steps. Testers see evidence the fix landed and execute the unfixed instructions. ## Establishing the line in a given repository The division is rarely documented in a form you can rely on, so test it - it takes minutes and the answer holds for every cycle afterwards: 1. Put one case into a cycle and record a result on it. 2. In the master, change **one word of a step**, the **title**, the **folder**, and **replace an attachment** - four edits, one per candidate field. 3. Reopen the cycle item and see which of the four followed. 4. Repeat step 3 on the **cycle's report or export**, not just the item view. Reports frequently resolve fields the item view copied, so the two surfaces can disagree. Step 4 is the one people skip and the one that produces the surprises. An item can render the copied title while the export lists the live one, because the export builds its rows from the case rather than from the cycle's record. ## Living with a hybrid Once you know the line, the practical rules are short: - **Never say "the cycle is snapshotted" without naming the fields.** It is a claim about specific data, and the unqualified version is the one that misleads a reader six months later. - **Treat referenced files as unstable.** If evidence matters, attach the file to the execution rather than relying on the case's pointer, so the bytes live with the result. - **Prefer additive edits during an open cycle.** Renaming and re-foldering are the edits most likely to be live, and they are also the ones with no urgency - they can wait until the cycle closes. - **Read a historical report twice.** Once for its numbers, which are stable, and once for its labels and grouping, which may not be. The underlying point generalises past this leaf: a snapshot is only as frozen as its least frozen field, and the fields most likely to have been left live are precisely the ones a reader uses to identify what they are looking at.