Why do long test plan documents go stale faster than the code they describe?

## The mechanism, not the morality The weak answer to this question blames the team for not updating the document. The strong answer treats rot as a predictable property of inert prose and designs around it. **Code has an oracle; a document does not.** When code contradicts reality, something fails - a build, a check, a request in production. When a sentence contradicts reality, nothing happens. The error stays, is read, is believed, and is propagated by the next person who copies the section into their own plan. Everything below follows from this asymmetry. **Duplication multiplies the exposure.** A long plan tends to restate facts that are already recorded and already changing somewhere else: which environments exist, which defects are open, which steps the pipeline runs, which cases the team holds. Every one of those copies has its own decay clock and no link back to its source. A one-page plan that links out has almost nothing to go stale; a thirty-page plan that copies everything has thirty pages of exposure. **Volume hides the decisions.** In a long inherited plan, the handful of sentences that actually decide something are buried among headings inherited from a template. Readers stop reading, so mistakes are not spotted, so nobody corrects them, so the document gets less trustworthy, so even fewer people read it. That loop is the rot. **Incentives finish the job.** If the document exists to pass a gate, its useful life ends at approval. Nobody is measured on whether it is still true in week six, and the release it describes has by then changed scope twice. ## What it costs A 4-person team inheriting an airline seat-map service found a 31-page plan whose risk section described a mitigation for a dependency that had been retired eleven months earlier, and whose environment section named two hosts that no longer existed. A new joiner spent most of a day chasing the retired dependency before someone senior said 'ignore that document'. That sentence is the real cost: once a team says it out loud, the organisation is paying to produce a document it has agreed not to believe - and the residual danger is that outsiders, auditors and joiners still believe it. A related trap: the plan named an intermittent timeout on roughly 2.7% of seat-map reads as an open risk, which had in fact been fixed two releases earlier. Stale risks are worse than missing ones, because attention is finite and gets spent on the phantom. ## How to fight it **Keep only decisions.** A plan should hold what was decided, by whom, and what was deliberately not done. Decisions age slowly and are worth writing. Facts age fast and should be referenced. **Link, do not copy.** Point at the live source for anything counted or generated. If a reader needs the current defect list, the plan should send them to where it lives, not attempt to hold a copy. **Date and own every section.** A section with a date and a name can be judged; an anonymous undated section cannot. When the owner leaves, the section is up for deletion by default. **Delete aggressively.** Track which sections anyone has actually cited during the delivery. Sections nobody consulted are the ones to cut at the next review - appending forever is what produced the 31 pages. **Review on change, not on calendar.** A yearly review of a document nobody reads produces a yearly rubber stamp. A review triggered when the way of working changes catches the thing that actually invalidated the text. **Watch for the tells.** The plan was not edited once during the release it governs. Two documents disagree and nobody noticed. Questions it supposedly answers are answered in chat instead. A section describes a system nobody currently operates. Any one of those means the document has stopped being maintained, whatever its approval status says. ## The audit objection Someone will point out that an external obligation requires a written plan, so it cannot simply be cut. That changes the form, not the principle. Auditors want evidence that decisions were made, by whom, and that they were followed; they are not helped by a copied environment table that is wrong. Keep the decisions and their owners in the document, keep the volatile facts behind links or generated appendices, and the document both satisfies the obligation and stays true. A signed document is evidence of a signature, never evidence that testing happened - a candidate who conflates those two has not been near a real audit.