Your case repository holds a cloned copy of the same suite for each of three supported releases, and after a year they have drifted apart. How do you stop them becoming three unrelated suites?
answer
- drift is fine; unclassified drift is not
- one copy is the source of truth
- make siblings findable by a stamped value
- propagate corrections, not release behaviour
- audit by export and diff, then classify
basics
~20 sName one copy the source of truth, stamp a shared lineage value so siblings are findable, and make applying a correction to every supported release part of the fix routine. Then audit differences on a schedule and classify each.
solid answer
~50 sDrift itself is fine - the releases really do differ, and their copies should say so. What kills the tree is *unclassified* drift, where nobody can tell an intentional difference from a fix that never got carried across. Four disciplines keep it navigable. First, designate one copy - usually the newest supported release - as the source of truth for wording, so there is a definitive version to reconcile toward. Second, stamp a shared lineage value on every copy at clone time so the sibling set is one filter away. Third, make *apply to every supported release* an explicit step in the fix routine, not something remembered. Fourth, audit periodically: export the subtrees, diff them by lineage value, and have someone with product knowledge mark each difference intentional or missed, recording the verdict so the next audit does not re-raise it.
go deeper
Know that per-release copies drift apart on their own, and that keeping them related is manual work rather than something the repository handles.
Explain the mechanics that make an audit possible: a stable value shared by all copies of a case, an export of each subtree, and a field-level comparison outside the tool.
Show the operating regime - a designated source of truth, propagation inside the fix routine, a scheduled audit, and a recorded verdict on every difference so it is not re-litigated.
Own the exit criteria. Say what evidence would tell you the copies have genuinely forked into separate suites and the reconciliation budget should stop.
## Drift is expected; unmanaged drift is the failure When you clone a case subtree per release, the copies begin identical and immediately start moving apart. Some of that movement is correct: the older release genuinely behaves differently, so its copy genuinely should read differently. Some of it is accidental: a correction landed on one copy because that was the release someone happened to be working on. After a year, both kinds of difference look exactly the same in the tree. That is the real failure mode - not that the copies differ, but that nobody can tell **which differences were decided and which just happened**. A reader who cannot tell has to treat every difference as suspect, which is the same as trusting none of them. ## Four disciplines that keep the copies related 1. **Designate a source of truth.** Usually the newest supported release. Wording changes land there first and are carried outward; without a definitive copy, every reconciliation turns into an argument about which version is the good one. 2. **Make siblings findable.** Stamp a stable lineage value onto every copy at clone time, identical across all copies of one logical case and derived from nothing that can change. If it was not stamped, reconstruct it once, in bulk, and stamp it retroactively - it only gets harder as titles drift. 3. **Put propagation in the routine.** When a fix changes a case, the routine step is *apply to every supported release*, with the supported list written down. A step that is remembered is a step that is skipped under pressure. 4. **Audit on a schedule.** Export each subtree, join on the lineage value, and diff the definitions. The output is a list of cases that differ - the raw material for the classification step, which is the part only a person can do. ## Which differences should travel, and which should not | Kind of change | Propagate? | |---|---| | A wrong expected result, a mis-stated step, a typo | Yes - the case was wrong about every release | | Clarified wording, better preconditions, tidier steps | Usually - it costs little and keeps the copies comparable | | A step describing behaviour introduced in the newest release | No - the older releases do not behave that way | | A case for a feature that does not exist in an older release | No - and consider whether that copy should exist at all | | A structural reorganisation of folders | Only deliberately - reorganising one copy breaks position-based sibling matching for everyone | ## Auditing without a diff feature Most case repositories offer no way to compare two subtrees, so the audit is done outside: export both, key each case by its lineage value, and compare the fields that matter - title, steps, expected results. Run it on a cadence tied to the release rhythm rather than the calendar, and give the output an owner. The person who classifies each difference has to know the product; the person who runs the export does not. Recording the verdict beside the case is what stops the next audit re-raising the same difference forever. ## Knowing when to stop The upkeep is proportional to the number of supported copies, and it never gets cheaper. Two signals say the model has outgrown its value: - **The copies stop being comparable at all.** If the audit output is mostly intentional differences, the releases have genuinely forked and the copies are separate suites now. Say so, and stop paying to reconcile them. - **Propagation is consistently skipped.** If corrections land only on the newest release for a couple of cycles running, the routine is not being followed, and every unsupported copy is quietly accumulating wrong expected results that someone will eventually execute. Both are decisions to surface deliberately, not conditions to let the tree drift into. The copies of a release that has left support are the easy case - they are no longer part of the audit set - but that only helps if leaving support actually triggers a change to the supported list the routine reads from.
- How would you audit drift between two release copies when the repository offers no comparison feature?Export both subtrees, key each case by its lineage value, and diff title, steps and expected results outside the repository. The mechanical half runs on a schedule; the output is a list of differing cases that someone with product knowledge then classifies as intentional or as a missed propagation.
- Who should decide that a difference between two release copies is intentional?Whoever owns that release's scope - typically the person accountable for what it ships. The export produces the candidate list, but marking a difference intentional requires knowing whether the release really behaves that way. Record the verdict next to the case so the next audit does not raise it again.
saying these in an interview costs you the question
- Promises to keep every copy identical forever
- Treats every difference between copies as an error
- Has no way to list all copies of one case
- Still reconciles copies of unsupported releases
- Relies on people remembering to update the other releases