Testing a Runbook Like You'd Test a Backup

Chapter 7 explained why documentation decays silently. This chapter delivers the actual practice that closes the gap — the exact discipline `backup1`'s own Chapter 5 built for backups, applied here to documentation: only someone genuinely attempting to follow a document proves it actually works.

Why the Author Testing Their Own Document Isn't Enough

The author already knows what they meant — which means they'll unconsciously fill in every gap and resolve every ambiguity a genuine stranger would trip over. This is the same underlying problem Chapter 5's own "watch, don't just ask" material identified: an expert's own automatic knowledge quietly contaminates their ability to notice what's actually missing from what they wrote down.

What Counts as a Genuine Test

• Ideal: someone unfamiliar with the specific procedure actually executes it, in a safe test environment when the real action would be risky or destructive
• A reasonable substitute: when live execution genuinely isn't safe or practical, a careful, skeptical walkthrough — checking that every referenced hostname, value, and tool actually still exists and is current — mirroring `backup1`'s own "sampling beats nothing" reasoning for backup sets too large to fully restore-test
• What to confirm: that preconditions are genuinely checkable as written, steps produce the stated expected results, verification actually confirms the real goal, and rollback is itself followable — Chapter 4's own four sections, each independently confirmed to hold up

Test Cadence, Tied to Chapter 7's Own Review Material

A test is a stronger, more rigorous form of the review Chapter 7 already established, not a separate unrelated task. Critical runbooks — the ones reached for during high-severity incidents — deserve more frequent, more rigorous testing than a rarely-used KB article ever needs.

Documenting Test Results

Each test should record the date, who tested it, what was found, and whether anything needed fixing — creating a real trail of evidence, echoing `log1`'s own foundational discipline, rather than an untracked, fading sense that a document "still seems fine."

Hands-On Exercises