Release decision memo and scenario result sheet

The release decision memo is one page. The top field names the target: the build and product area verified, the review window, and the environment combinations exercised. The second field carries the agreed scope — the number of core flows, the number of scenarios and the retest count fixed in writing before kickoff — with the excluded items listed beside them. The third field holds the scenario results, the fourth what was not checked, the fifth the residual risk, and the last the verdict and signature block. The order never changes: read the verdict without knowing how far the work reached and there is no way to tell how far that verdict holds. Environment combinations name only the axes that change the outcome — browser and operating system, device and app version. Anything observed outside those combinations is not a result of this review; it is a candidate for the next scope.

The scenario result sheet runs eight columns: scenario number, parent core flow, preconditions, steps, expected result, status, linked defect number, and who ran it and when. The status column takes four values and no others. PASS matches the expected result, FAIL diverges from it, BLOCKED means an earlier step made execution impossible, and NOT RUN means the scenario sat inside scope but was never executed. Fold the last two into FAIL and the product defect count inflates; fold them into PASS and the coverage reads wider than it was. Kept apart, the sheet doubles as the run list for the next round. Preconditions and steps go only as deep as another person needs to reproduce the same outcome: accounts, data and entry screen in the precondition column, steps broken into short numbered sentences. The defect number column maps one to one onto the defect log. Follow a number out of a FAIL row and severity, reproduction conditions, owner and fix status come back; walk in from the defect log and the flow where it surfaced comes back.

The fourth field separates what fell outside scope from what sat inside scope and was still missed, with a one-line reason against each miss. The residual risk in the fifth field is not a defect list but decision material: defects shipped unfixed, symptoms whose reproduction was never narrowed, and points to watch in operation, each with a severity. Leave these two fields empty and only a pass rate remains — and a pass rate says nothing about where the failures sit. Keep the reasons short: environment not available, blocked by an upstream defect, outside the agreed scope. Split three ways, the document itself settles what has to clear first next round.

The verdict field carries one of three values: release, release with conditions, or hold. Release with conditions states in the same field what has to be satisfied; hold states what has to be in place before the question is asked again. The release meeting reads the document and either fixes the date or moves it, and when it moves, the fourth field becomes the scope of the next round. Pulled out later for an audit or an incident review, requirements, scenarios, defects, fixes and approvals still run in one line. In the blank template the verdict field and the signature block stay empty. The signature goes in after the actual review, from the person who has read the results, the exclusions, the assumptions and the residual risk. Recording who signed is what turns an approval from a contest of opinions into a check against evidence.