RELEASE PRACTICE
Review a release from entry to recovery
Follow one important task through access checks, direct links, meaningful completion, and failure recovery before releasing a small web product.
Start a release review with a task someone should be able to complete. “Create a project and find it again” gives the review a specific action and a result to check. Write the expected outcome, the account allowed to perform it, and the evidence that would prove it worked. Then follow that task from a fresh entry point through completion and recovery.
Check access where it is enforced
Review the task while signed out, as an authorized account, and as an account that should not have access. Use test records designed for this purpose. Try the destination URL directly as well as the normal navigation. Where the product has an API, verify the relevant requests too.
A hidden button does not establish access control. OWASP recommends checking permissions on every request, including access to the particular object being requested. Record the expected decision for each account and verify that unauthorized reads and changes are rejected by the enforcing service. OWASP: Authorization
Give important destinations useful URLs
Copy the address of the created item, open it in another tab, refresh it, and use Back. An authorized person should be able to return to the intended destination without reproducing a sequence of interface gestures. Check that an unavailable item produces an understandable result and a useful route onward.
For public content intended to be found in search, use ordinary links with real destinations. Google's documentation explains that it generally extracts crawlable links from anchor elements with href attributes; script-driven controls are not a reliable substitute. A direct URL and a crawlable link serve different checks, so verify both. Google: Link best practices
Verify the promised outcome
Read the primary action and its confirmation literally. If the interface promises to save a project, reopen that project after completion and confirm the intended values. If it promises to start background work, identify where the person can check progress and the eventual result.
Review empty and partial outcomes too. A successful request returning no matches should explain the search result. A partially completed operation should identify what remains. Make sure the confirmation stays useful after the animation ends and that it points to the correct item.
Rehearse recovery
In a controlled test environment, interrupt the task at meaningful points: before submission, while waiting, and after the service may have acted but before confirmation arrives. Observe whether input survives and whether the interface can establish what happened.
Decide which operations can safely repeat. HTTP defines idempotent methods around the intended effect of repeated requests, and discourages automatic retries of non-idempotent requests unless their semantics are known to be safe or the original was not applied. Do not treat every connection failure as permission to submit again. RFC 9110: Idempotent Methods
For the release itself, identify the change, the signal that would justify stopping it, and the available recovery action. Reverting an interface does not necessarily reverse data already written. Record any separate data-recovery decision before it becomes urgent.
Keep the review evidence compact: task, account type, expected result, observed result, and unresolved issue. A clean review should explain what was checked and what remains uncertain. That makes the release decision reviewable by someone who did not perform the walkthrough.