Software projects
Prepare review questions for a software change
Start from what the change alters in behavior, then trace which paths and stored data touch it. For each affected path, name how it could fail, how to check it and what recovery looks like. That gives a reviewer concrete things to examine.
Change summary: [ ] System or area: [ ] Changed behavior: [ ] Affected path: [ ] Failure mode: [ ] Check to run: [ ] Evidence so far: [ ] Suspected only or observed: [ ] Stored data that could be altered: [ ] Can it be restored after rollback (yes, no, unknown): [ ] Dependent systems or users affected: [ ] Rollback question for the reviewer: [ ] Person who can confirm rollback steps: [ ] Checks run before review and results: [ ]
Evidence versus hypothesis
A risk list can fill up with plausible worries that nobody has tested. Separate risks you have observed, such as a failing test or a log entry, from ones you only suspect. Check that each failure mode points to a specific path or record type instead of the whole system. Look for stored data the change could alter in a way that cannot be undone, and confirm the rollback question covers that data, since reverting code does not always restore it. Note any dependent system the change affects that the reviewer might not know about.
For each risk in this review sheet, ask whether it has evidence or is only a hypothesis, and label it. List risks that lack evidence, and flag any data change that rollback might not reverse. If you add a risk, label it as your own guess.
Hand the reviewer a short list
Cut the questions to the ones that matter most for this change and attach the evidence you have for each. Run the cheap checks yourself before review and record the results. Tell the reviewer which risks remain unproven so they spend time there. Ask who can confirm the rollback steps work and write down the answer.