Recovery testing

What it covers

Recovery testing shows how scope, inputs, expected behavior, and failure interpretation fit together. Start by naming the risk or behavior, then choose observations that can distinguish an acceptable result from a failure. Good test design records enough context for another engineer to understand why the check exists, what it proves, and what it deliberately leaves to another layer. This makes test results useful during development, review, release decisions, and later investigation.

How teams apply it

Imagine a release that changes authentication. The team can use recovery testing to exercise a normal sign-in, an invalid credential, and a recovery path, then compare results with the agreed acceptance criteria. The example is useful because it tests behavior users depend on. The surrounding workflow should keep the test close enough to the change to provide timely feedback, while still preserving the independence and realism needed for the claim. Teams can document setup, inputs, expected results, cleanup, and ownership so maintenance does not depend on tribal knowledge.

Limitations

Automation can make this practice repeatable, but it cannot decide whether the tested behavior matters. Revisit coverage when the product, dependencies, risks, or operating conditions change. Use the result with test coverage, code review, production signals, and incident learning as appropriate. A quality practice is strongest when its evidence is connected to the risk it is meant to reduce.

How Weave relates

Weave can provide delivery and engineering-intelligence context around recovery testing, including change activity, review signals, rework, and quality outcomes. That context can help teams see whether a testing practice is improving feedback or correlates with recurring failure patterns. Weave does not execute tests, certify assertions, or replace the test system as the source of truth.