Begin with the build and environment contract
Identify who may provide the build, whether it is an APK or IPA, how it is signed, which backend it uses, and which test accounts are permitted. A build URL or binary is sensitive operational material; do not upload it to an unapproved service.
Choose journeys before devices
Start with onboarding, sign-in, recovery, permissions, core transactions, and upgrade paths. Device matrices should refine those risks—not replace them. A hundred device checks on an unimportant screen do not outweigh one missing account-recovery path.
Model mobile-only states
Permissions, deep links, background and foreground transitions, gestures, keyboards, orientation, push notifications, biometrics, app upgrades, and interrupted connectivity create states that browser tests do not. Name which of these belong to each journey.
Build a representative target matrix
Use product telemetry and supported-version policy to select operating systems, screen classes, and device capabilities. Separate a fast release gate from broader scheduled coverage. Do not imply that one generic iOS or Android run represents the installed base.
Treat screenshots as evidence, not truth
A screenshot helps a reviewer inspect visible state, while logs, accessibility hierarchy, network traces, and application signals may explain why that state occurred. Sensitive values can appear in any of these artifacts, so collection and retention must be designed before execution.
Keep a person at consequential edges
Do not let a test agent make real purchases, send messages, alter live accounts, approve permissions with external consequences, or perform destructive actions without an explicitly approved sandbox and human controls.
Define the release statement precisely
A useful report says which build, environments, journeys, devices, OS versions, data, and time window were exercised—and what was skipped or blocked. It should never translate a limited sample into a guarantee that the release has no defects.