Continuity Testing
Continuity testing exercises the recovery path — failover, restore, runbook — under controlled conditions, so that the recovery works when called on at 3 a.m. because it has been called on.
Definition
Continuity testing is the practice of regularly exercising the disaster recovery procedures — failing over a region, restoring from backup, executing the runbook — in a controlled environment, so that the recovery is a rehearsed operation whose timing and steps are known rather than a first-time attempt during an outage.
Context and scope
Applied in disaster recovery programs, game days, and regulated industries where the ability to recover is audited, not merely documented.
Common misconceptions
- A tested backup is a restorable backup — a backup is restorable only after a restore has been practiced; untested backups are write-only hope
- Failover testing is too risky for production — the risk of never failing over is higher; controlled failover tests are how that risk is managed
Anti-patterns
- Documenting the recovery procedure without ever executing it, so the first execution discovers the missing step during the outage
- Testing failover only in staging, missing the production-specific dependencies that make the real failover fail
Related concepts
Authoritative source
https://aws.amazon.com/builders-library/a-fault-injection-story/
What it is
Continuity testing is the practice of regularly exercising the disaster recovery procedures — failing over a region, restoring from backup, executing the runbook — in a controlled environment, so that the recovery is a rehearsed operation whose timing and steps are known rather than a first-time attempt during an outage. Applied in disaster recovery programs, game days, and regulated industries where the ability to recover is audited, not merely documented. The distinguishing question is what counts as evidence: a test that passes by accident is worse than no test, because it manufactures false confidence that propagates into release decisions.
How it works
Sound tests exercise a specific behavior contract, isolate the unit under test from environmental noise, and fail with a diagnostic that points at the cause rather than the symptom. Determinism is engineered, not assumed: clocks are fixed, randomness is seeded, and external state is replaced with doubles whose interactions are asserted, not merely stubbed. Coverage measures which behaviors were exercised, not which lines were visited.
When to apply and pitfalls
Apply where the cost of an undetected regression exceeds the cost of writing and maintaining the test. The recurring pitfall is testing the implementation rather than the behavior — such tests break on every refactor and teach nothing. Equally damaging are tests that assert only the happy path, leaving the error branches — where most production bugs live — unexercised.