A case's change trail is the only record of what a test case said when an old result was recorded. How do you decide how much of that trail your team needs, and how do you keep it readable?

This is a judgement question, not a settings question, and the strongest answers separate two things that sound like one: **how far back the trail reaches**, and **whether anything in it can be found**. Teams spend their energy on the first and lose to the second. ## Start from the question the trail must answer Do not begin with storage. Begin with the sentence someone will one day need you to complete: *on the day this result was recorded, the case said this.* Then ask how long that sentence has to remain answerable. The horizon comes from the product, not from the tool: - How long is a shipped release supported and patched? - How long might a result be re-examined after an incident or a customer report? - How long does your organisation say it keeps records of this kind? Whichever of those is longest sets the horizon you actually need. Anything beyond it is comfort; anything short of it is a promise you cannot keep. ## The length is often not yours; the noise always is In a hosted repository the trail's depth tends to be a property of the product. There may be no setting, and the vendor's behaviour can change. Two consequences follow. First, **verify the horizon rather than assuming it is unlimited**. Find an old, heavily-edited case and read the far end of its trail. If the oldest entries are gone, you have just learned something important before it mattered. Second, **shape your promises to what you observed**, not to what feels reasonable. It is far better to say *we can attribute changes for roughly this long, and beyond that we can show only the current text* than to discover the limit during a review. ## What floods a trail A trail's usefulness dies from volume long before it dies from age. The usual sources, in rough order of damage: - **Volatile values in versioned fields.** An owner that rotates, a sprint pointer, a last-touched marker, a status your process moves weekly. Each change is a revision, and these change far more often than the behaviour the case describes. - **Migrations and mass relabelling.** One pass touching every case can produce more entries than a year of real authoring, all with the same actor and second. - **Automation that writes on save.** A rule that stamps a field on every edit doubles the trail and adds nothing a reader wants. - **Reformatting.** Bulk normalisation of wording, tidying whitespace, converting formatting — real edits with zero behavioural meaning, sitting between the edits that matter. The test for any candidate field is simple: *does a change to this field change what a tester would do?* If not, it does not belong among the versioned fields whose history someone will read. ## Decisions worth making up front 1. **Name the fields the history is for.** Usually the title, the preconditions, the steps and the expected result — the text that defines behaviour. Everything else is bookkeeping, and where the product lets you keep bookkeeping outside the versioned fields, do it. 2. **Make bulk edits legible.** Run a migration as one deliberate pass, under one identity, at a known time, with a note recorded where your team will find it. A wall of identical entries is fine when it is explainable at a glance and a disaster when it is not. 3. **Record reasons where the product allows it.** Entries record what moved, never why. The cheapest habit with the highest late payoff is a one-line reason on non-obvious edits. 4. **Re-check the horizon periodically.** It is an observed property of somebody else's product, not a fact you own. ## What to promise, and what to refuse to promise The principal-level contribution is refusing the over-promise. If the trail prunes, you cannot guarantee reconstruction of any case at any past date, and no amount of process discipline changes that — so say it before somebody designs a review around the assumption. Equally, resist the opposite error of treating completeness as sufficiency: a trail that records everything and is drowned in mechanical churn will not answer a real question any faster than one that recorded nothing. The healthy end state is narrow and honest. A small set of fields whose history genuinely describes behaviour, a horizon you have measured rather than assumed, bulk operations that are recognisable as single acts, and a team that knows exactly which questions the trail can settle and which ones need evidence kept somewhere else.