Digital products ·
Test the app before the store reviews the build
Store review does not replace product testing. Before publication, the team needs to know that a person can complete the primary journey on a real device, survive a network failure and return to work safely.
Begin with the app’s promise
A screen list does not describe readiness well. Use complete journeys: install the app, sign in, perform the primary action, receive confirmation, close the app and continue later. Each journey needs an expected outcome and a clear failure point.
Test the product’s central promise first. If the app exists to order a service, a completed order matters more than perfect motion in a secondary settings screen. Test priority follows frequency and the cost of failure.
Real devices reveal context
A simulator accelerates development but cannot reproduce every physical condition: memory pressure, rotation, system dialogs, biometrics, camera, notifications and behaviour after a long pause. Core journeys should run on several real devices and system versions relevant to the audience.
An endless device laboratory is unnecessary. Build the matrix from risk: the oldest supported version, a common screen size, a weaker device and the current operating system. NFC, Bluetooth, location or background processing add focused cases when the product uses them.
Make the network bad on purpose
A mobile connection can disappear between request and response, switch from Wi-Fi to cellular and return a minute later. Test slow transfer, no connection, timeouts and reopening the app. The user must understand what happened to their action.
Duplicate operations are especially dangerous. After an uncertain response, a person presses the button again and may create a second order or charge. Interface, server and local state need to prevent duplicates together and support safe continuation.
Ask for permissions in context
Camera, photo, location and notification access should be requested when its value is clear. Refusal cannot become a dead end: explain the alternative and provide a route to system settings when the capability is essential.
Test the first request, repeated refusal, limited access and a permission change outside the app. Observe what happens after returning from settings and whether the interface keeps an outdated belief about access.
Data and accounts need failure journeys
Test sign-in with an invalid code, expired link, changed contact and account recovery. If the app stores documents or drafts, define what survives sign-out, reinstall and sign-in on another device.
For purchases and subscriptions, cover success, cancellation, pending confirmation, restoration and repeated store events. Access should follow a verified transaction rather than a local success screen alone.
Test accessibility and localisation by hand
Large text, a screen reader, contrast and focus order can reshape a familiar journey. Automated checks find some problems but cannot tell whether a screen makes sense without imagery or whether an action works without precise touch.
Another language changes line length, date, currency and number formats. Walk through the interface with long translations and realistic data, checking clipped text and failure messages. Placeholders rarely expose these weaknesses.
Analytics also needs acceptance testing
An event should be sent once, at the right moment and without unnecessary personal data. Verify its connection to the app version, screen and operation outcome, not just its appearance in a debugger. Otherwise the team launches with numbers it cannot trust.
Crash and error reports need enough context for diagnosis without leaking secrets. Define release-stopping thresholds in advance, such as a broken primary journey or a rise in critical failures within the test group.
A beta release completes the check
Before broad publication, distribute the build to a limited group through an available testing channel. Give participants specific tasks and a clear reporting route. They should exercise real devices, accounts and conditions rather than simply open the app.
Within the Method, I connect acceptance criteria to app architecture before development. Complete journeys, telemetry and recovery plans are tested together before release. Publication then becomes a controlled product stage rather than a final hope that store review will find the problems.
From a use case to an app
If you need an app, we can define its core journey, roles, first release and constraints before development begins.