Define the release and its evidence
Start with a named release, a fixed scope, and a list of critical journeys. For each journey, write the initial conditions, user action, expected records, and visible result. Assign a person who can accept the evidence rather than relying on an informal group impression. Identify external accounts, provider credentials, network configuration, and commercial dependencies required to operate the release. Mark unavailable dependencies explicitly. A feature that works only with a developer’s private configuration has not yet demonstrated that the receiving team can operate it.
Check identity and permissions as complete journeys
Test account creation, ownership verification, sign-in, recovery, session expiry, and the removal of access. Cover customer, support, finance, and administrator roles with deliberate attempts to perform actions outside each role. If an optional identity provider is not configured, its entry point should explain availability accurately. OWASP ASVS provides a reference for explicit application security verification requirements. Use an appropriate review scope alongside functional acceptance. A successful sign-in demonstration alone says little about permissions on exports, support attachments, internal actions, or requests made directly to the server.
Prove transaction behavior under repetition
For a payment or asset operation, trace the request through durable records, external evidence, state changes, and customer access. Submit the same event twice, refresh during processing, restart a worker, and delay an external response. Confirm that retries do not duplicate credit or fulfillment. Check mismatched amounts and unsupported assets through the intended exception route. Reconcile the final ledger with the accepted events. Record both expected and observed outcomes. The acceptance goal is an explainable result for interrupted work as well as for the straightforward successful path.
Rehearse recovery before depending on it
Restore a backup into an isolated environment and confirm that the application can use it. A successful backup job does not by itself demonstrate restoration. Test monitoring, alert routing, provider failure, and a documented rollback to the previous working release. Decide which changes cannot be reversed automatically, especially when external transactions have already occurred. Keep logs useful for investigation while excluding secrets and unnecessary personal data. Name the person responsible for responding to each critical alert and provide the information needed to begin without guessing.
Validate the public experience
Walk through the published site on a phone and a desktop, in every supported language. Check navigation, forms, keyboard use, empty states, errors, page titles, canonical links, and indexable public pages. Measure the actual release with representative content instead of an empty development database. Verify that private account pages and administrative tools have appropriate access boundaries and search behavior. Make sure prices, delivery conditions, support routes, and product availability agree across the catalog and checkout. A technically successful payment is still a poor release if the customer cannot understand the delivery promise.
Make the handover an operating agreement
Deliver deployment instructions, environment requirements, migration steps, scheduled tasks, provider ownership, and a list of known limitations. Ask a receiving operator to perform a routine task using only that material. Record open defects by impact and decide which prevent launch. Agree on how to stop new requests, handle work already in progress, and communicate a service incident. Approval should refer to a specific version and its evidence package. This process does not promise a risk-free launch; it makes the decision reviewable and gives the team a workable foundation for operating the product.