Choose the update and its test conditions
Imagine a Budapest laundry service updating the saved-address screen in its pickup app. Existing customers need to choose their usual collection address and find previous orders. Agree which app version is being approved, which earlier versions customers may upgrade from, and which phones and operating systems the business supports.
Android's testing fundamentals distinguish checks of individual parts from checks of complete journeys. Ask the team to explain which evidence covers each concern. Use a compact test matrix with the app version, device, language and starting account state. More combinations take more time; prioritize those used by your customers and record what remains untested.
Rehearse an upgrade with existing data
On a test account in the previous app version, save two fictional collection addresses and create sample order history. Install the update through the team's test distribution process without first deleting the app. Then compare the addresses, default selection and order details with the agreed expected result.
A clean installation is quicker to prepare, but it leaves this starting condition unexplored. Keep both checks in the plan. Signing in again may be intentional; losing a saved address needs investigation. Use invented test details so recordings and issue reports do not expose real customers' addresses.
Interrupt a task at a meaningful moment
Android's quality guidance includes interruptions and changing network conditions. For the laundry example, begin editing a collection note, switch to another app, then return. Compare the result with the team's promise about saving drafts. Repeat with the screen locked, and record the exact point where an unexpected loss occurs.
Next, open order history on a deliberately slowed connection and then disconnect. Can the customer distinguish previously loaded information from a failed refresh? Restore connectivity and check that the displayed order belongs to the same account. Agree the expected messages before testing so a reviewer can identify a failure consistently.
Include customers with different settings
Repeat address selection with location permission denied, if the app offers a location shortcut. Try larger text and a screen reader, including after returning from another app. Ask a reviewer familiar with that assistive technology to find and change the saved address without coaching.
React Native warns that JavaScript component tests do not exercise the underlying native platform code. Request a demonstration on each supported mobile platform. Shared code can reduce duplicated development, but a successful check on one platform should not stand in for the other.
Approve evidence tied to a specific release
Keep a short release record that the owner, developer and support contact can read together. If a fix produces a new build, repeat the affected checks and the essential customer journey before signing it off.
- Record the tested build and the earlier versions used for upgrade checks.
- Keep expected and actual results for saved addresses and order history.
- List tested interruptions, connection conditions and accessibility settings.
- Give unresolved issues an owner and an explicit release decision.
- Identify who handles customer reports and checks the first reported failures.