A shared step block referenced by dozens of cases that already carry execution history needs correcting. When do you edit it in place, and when do you create a new block and repoint the cases at it?
answer
- cosmetic versus behaviour-changing
- did the tester actually do something different
- history renders against today's text
- repointing writes a dated seam per case
- retire the old block only when unreferenced
basics
~20 sEdit in place when the change is cosmetic: same action, same expected result, clearer words. Fork a new block and repoint when the action or expected result changes, because an in-place edit leaves history describing steps nobody performed.
solid answer
~50 sThe test is whether the edit changes **what was done**, not how it reads. Fixing a typo, splitting one long instruction into two, or naming the button the product has always shown is cosmetic: edit in place and every case is current with no fallout. Changing the action, changing the expected result or adding a step is a behaviour change. Do that in place and, under live resolution, every already-recorded result rendered afterwards sits beside instructions nobody following it ever saw — evidence describing an action that was never performed. Instead create a new block and repoint deliberately. Repointing writes a dated edit into each case's own history, so a reader can see when the case changed and which results predate it; an in-place edit leaves a single event on the block, far from the case, which nobody reading the case will find.
go deeper
Know that editing a shared block affects every case using it, and that a change to what the step actually does deserves more care than fixing a typo.
Explain why a behaviour-changing in-place edit leaves recorded results sitting beside instructions the tester never followed, given that the case stores a pointer rather than the text.
Show the decision procedure end to end: classify the edit, fork and repoint for behaviour changes, batch by owner, and retire the old block only once nothing references it.
Own where the line sits for the organisation and what evidence obligations push it. Be ready to defend both directions — that always forking recreates pasted copies, and that always editing in place erodes the record.
## The distinction that decides it Every edit to a shared block falls into one of two buckets, and the bucket — not the size of the diff — decides the strategy. **Cosmetic.** The step describes the same action, expects the same outcome, and only reads better: a typo, a clarified pronoun, a split of one crowded instruction into two rows, a correction to a control name the product has shown all along. Nothing anybody did was different from what the new words say. Edit in place. The impact list will be long, and that is fine. **Behaviour-changing.** The action itself is different, or the expected result is different, or a step is added or removed, or the data the step uses changes. Somebody following the block yesterday genuinely did something other than what it now says. This is where an in-place edit does damage. ## What an in-place behaviour change does to recorded history Under execution-time resolution the case does not own the step text — the repository assembles it from the block whenever anybody looks. So a result recorded last month, opened next quarter, renders beside **today's** instructions. Three concrete consequences: - **Evidence stops matching the act.** The recorded outcome says the step was performed and observed; the text beside it describes a step that did not exist when the outcome was recorded. Anybody reconstructing what was verified reads a false pairing. - **The change leaves no trace where the reader is looking.** The edit is one event in the block's own history. A reader looking at a case, or at one execution of that case, sees no edit and has no reason to suspect the wording moved. - **Comparing two runs stops being meaningful.** Last quarter's run and this quarter's run appear to have followed the same steps, so a difference in outcome looks like a product change when it is a case change. Repositories that snapshot rather than resolve live push the problem the other way: the history is faithful, but the estate splits into cases showing old text and cases showing new, and a reader has to work out which is which. ## Why repointing is worth its cost Creating a second block and moving callers onto it costs more work and briefly leaves two similar blocks in the repository. It buys three things: 1. **A dated seam in each case.** Repointing edits the case, so the case's own history records that on this date it changed which action it performs. Results before the seam and after it are distinguishable by anyone reading the case. 2. **Per-caller consent.** Not every referencing case necessarily wants the new behaviour. Repointing is done one caller at a time, so a case that deliberately exercises the old path can stay on the old block. 3. **A survivable rollback.** If the new action turns out to be wrong, repointing back is a case-level edit, not an archaeology exercise over one block's edit log. ## A working procedure 1. **Classify the edit** — cosmetic or behaviour-changing. If you cannot decide, ask whether a tester who followed the old text did something different. If yes, it is behaviour-changing. 2. **For cosmetic edits**, read the impact list for cross-team callers, save, and spot-check two rendered cases. 3. **For behaviour changes**, create the new block with a name that says what it does differently, not "v2" — names like *sign in with consent prompt* survive; version suffixes accumulate and stop meaning anything. 4. **Repoint in batches by owner**, so each team's cases move together and each team can see the change land in their own case histories. 5. **Leave the old block in place until its impact list is empty**, then retire it. Deleting a block with live callers turns a wording problem into a broken case. 6. **Time the moves away from active cycles**, so a tester is not handed different instructions between one execution and the next. ## The common wrong answers The weak answer is "edit in place, that is the point of shared steps" — true for cosmetic edits and quietly corrosive for behaviour changes. The other weak answer is "never edit in place, always fork", which throws away the reuse entirely: after three forks nobody knows which block is current, the impact lists are all short, and you have arrived back at pasted copies by a longer road. The judgment is knowing which edit you are making, and being honest that the same keystrokes carry very different consequences depending on whether the world changed or only the sentence did.
- You forked the block and repointed most callers, but four cases still reference the old one months later. What do you do?Find out whether those four deliberately depend on the old action or were simply missed. Deliberate ones get a note in the case saying so, and the old block gets a name reflecting that it is the legacy path. Missed ones get repointed. What you do not do is leave an unnamed orphan that a future author repoints out of tidiness.
- How would you name the two blocks so a future author does not pick the wrong one?Name them by the behaviour that differs, not by sequence — sign in with consent prompt against sign in without consent prompt. A version suffix tells a reader only which came first, which is never the question they have. If the difference cannot be put in a name, the fork probably was not warranted.
saying these in an interview costs you the question
- Edits a shared block's expected result in place without hesitation
- Thinks recorded results freeze the step text automatically
- Forks the block for every wording fix, destroying the reuse
- Deletes the old block while cases still reference it
- Names blocks with version suffixes instead of the behaviour