Freeze scope, not learning
A release candidate needs a defined scope so the team can test a stable target. New observations should still be recorded, but only issues that threaten the product promise, safety, compliance or recovery should enter the release at this stage.
Keep one decision log for accepted risk. “Known issue” is not a plan unless it has impact, owner, mitigation and a date for review.
| Level | Example impact | Gate action | Evidence required to close |
|---|---|---|---|
| Stop-ship | Core journey fails, data is exposed or required control is unavailable | Pause the candidate and assign an owner | Fix verified on affected paths plus a regression check |
| High | Important journey is unreliable with no clear recovery | Resolve before release or document an explicit risk decision | Reproduction result, mitigation and accountable approval |
| Follow-up | Limited issue with a clear workaround and no material policy impact | Record for the next planned update | Owner, scope, workaround and review date |
Test complete journeys from a clean state
Start with a fresh installation and a device that has no developer shortcuts. Complete onboarding, the main value journey, purchase or account flows, support access and sign-out or deletion. Then test an upgrade from the previous public version.
Repeat critical flows with denied permissions, interrupted network access, low storage, large text and a changed device clock. The goal is not to simulate every possible failure, but to verify that the product remains understandable when normal assumptions break.
Review accessibility as interaction quality
Check focus order, accessible names, contrast, text scaling, motion preferences and touch targets. Listen to the critical flow with a screen reader rather than relying only on automated findings.
Accessibility testing often reveals broader product problems: ambiguous labels, hidden state, actions that rely only on colour and layouts that collapse when content grows.
Reconcile privacy and account controls
Compare actual network traffic and SDK configuration with the privacy policy and store declarations. Verify that consent choices change behaviour, permission explanations match use, and account deletion can be reached both in the app and through the required web resource when applicable.
Make sure support can identify a deletion request without asking for unnecessary information. Record how long completion normally takes and which records must be retained for a legitimate reason.
Treat the store listing as part of the release
Screenshots must represent the submitted product. Descriptions, age rating, data disclosures, subscription terms, support links and review notes should be checked against the exact build. Provide a working reviewer account when functionality is restricted.
Open every public URL from a logged-out browser. A privacy or support link that works only for the development team is still broken for review.
Prepare observation and rollback
Before release, confirm crash reporting, service health, support ownership and a staged rollout plan. Define which signal pauses the rollout and who has authority to decide. For backend changes, ensure old application versions continue to work during adoption.
Write the first-day checklist before pressing release. Operational calm is designed in advance; it does not appear because the binary passed review.
Primary references
Store requirements change. These official sources should be checked again before a release decision.