Release sign-off

Sign-off is a decision, not a signature. When Dan signs a release, he is saying: "I have seen enough evidence that record-to-report still works, and I accept the known risks." For that statement to mean something, the evidence and the criteria must be the same every time. If the bar moves with the deadline, sign-off becomes a formality and nobody trusts it, including the auditors.

This lesson sets out a standard that works for any release: an SAP feature pack, a Public Edition upgrade, a quarterly enhancement release or a bundle of all three.

Entry criteria: ready to test

• The test system is on the target release or transport level, and production-like configuration is in place.
• The impact list is complete, with every relevant change mapped to scenarios and owners.
• The regression pack has been updated for this release's changes and approved.
• Test data is ready in the test client (for Contoso, client 100 in QAS) and testers are named and available.
• The defect process is agreed: where defects are logged, severity definitions and who triages.

Exit criteria: ready to sign

• All critical scenarios executed and passed; high scenarios executed with any failures dispositioned.
• No open severity 1 or 2 defects, or each one has an approved workaround and a fix date.
• Behavior changes from the impact list verified and communicated to users.
• Evidence stored where an auditor can find it, linked to the release.
• Rollback or contingency understood for the riskiest change.

The evidence standard

Define once what counts as proof, and use it every release. For a posting scenario, that is the source document number, the journal entry number and a comparison of expected and actual accounts and amounts. For an output scenario, it is the generated form or message and its recipient. For a negative test, it is the error or block message the user received. "Tester says it worked" is not evidence. The standard should let someone who did not run the test, such as an internal auditor six months later, re-check the result without asking anyone.

Go, conditional go, no-go

A conditional go is legitimate when the conditions are specific, owned and dated. "Go, provided the AP team uses the documented workaround for defect 4127 until the fix in the next correction, owner Dan, by month end" is a condition. "Go, but keep an eye on AP" is not. In Public Edition, production upgrades proceed on SAP's schedule, so the "no-go" option applies to your own changes and to activating optional scope; for the upgrade itself, sign-off records whether you are ready and what workarounds are in place.

Track quality across releases

One release's results tell you whether to go live. A year of results tells you whether quality is improving. Keep a simple trend: defects found per release by severity, where they were found (regression, user acceptance, production), and root cause (SAP change, Contoso change, test data, configuration). Review it once a year at the calendar planning session.

The trend points to action. The June escape came from a behavior change nobody rated, so Dan's team added a second reviewer to the impact rating. The September test data issues led Priya to script a test data refresh before every regression cycle.