Know which contract is changing.
A documentation edit does not need the same acceptance work as a change to authentication, persistent data or network routing. Begin by listing the public behaviour that should change and the behaviour that must remain stable.
Use risk to choose the test depth. This prevents routine changes from accumulating ritual checks while leaving dangerous changes under-tested.
Before the change, establish a baseline.
Record the version, relevant service health and the data that must be preserved. If a rollback is part of the operational contract, verify that the rollback material exists and can be used. A backup that cannot be located is not a recovery plan.
Make sure the operator knows what will be modified. Unexpected scope is a frequent source of operational failure.
After the change, prove the important outcome.
Do not stop at a green process indicator. Test one or more representative user operations. Check expected failure behaviour as well as the happy path: correct authorization boundaries, not-found responses and availability of dependent services.
Prefer a few strong end-to-end observations to a large set of checks that all inspect the same superficial state.
Decide in advance when to stop.
Define a clear point for aborting or reversing the change. Repeated restarts and unbounded retries often make diagnosis harder. If the failure lies outside the supported contract, a safe refusal and a precise error may be the right outcome.
Write the final state honestly: passed, failed, still in progress or not run. The purpose of a checklist is trustworthy information, not a comforting number of boxes checked.