Android app testing checklist

1. Define the build and test goal

Record the app version, build source and environment before testing. Decide whether the goal is a first-release review, beta testing, regression testing after changes, or investigation of a known issue. List the features that are in scope and the areas that are not ready.

2. Installation, updates and permissions

• Install the app on each agreed device without a previous version present.
• Update from the supported earlier version when an upgrade path matters.
• Accept and deny permissions to check both outcomes.
• Restart the app and device to confirm important state is retained correctly.
• Check what happens when storage or connectivity is limited.

3. Account and onboarding flows

• Create an account with valid details.
• Try missing, malformed and already-used values.
• Test sign-in, sign-out, password recovery and session expiry.
• Check verification links or codes when they are part of the app.
• Confirm error messages tell the user what to do next.

4. Core functional testing

Start with the main reason someone installs the app. Walk through each important task from beginning to end, including cancellation, back navigation, empty states and errors. Compare the actual result with the agreed product behaviour.

For an ecommerce app, that may include browsing, cart changes, checkout and order status. For a community app, it may include profiles, posting, replies and reporting. For a game, it may include onboarding, controls, progression, rewards, save state, interruptions and recovery.

5. Usability and mobile user testing

• Can a new user identify the primary action without explanation?
• Are labels, validation and confirmations clear?
• Can users recover from mistakes without losing unnecessary work?
• Does content remain readable with larger system text?
• Are tap targets usable and important controls visible on agreed screen sizes?
• Do loading, offline and empty states explain what is happening?

6. Device, layout and interruption checks

Android behaviour varies by device, OS version, display, memory and manufacturer customisation. Agree a realistic device scope rather than claiming every Android combination. Within that scope, check orientation changes, keyboard behaviour, notifications, calls, backgrounding, network changes and low-power conditions where relevant.

7. Data, payments and sensitive actions

Use dedicated test accounts and safe test data. Check duplicate submissions, interrupted actions, retry behaviour and confirmation screens. For paid features, agree the billing-test setup before testing and never use a customer’s live payment credentials merely to complete a QA check.

8. Write reproducible bug reports

A good report gives the development team enough context to reproduce and prioritise the issue. A screenshot without the steps and build context is usually insufficient.

9. Retest fixes and watch for regressions

After a fix, repeat the original steps and nearby journeys that may have been affected. Record whether the issue is fixed, still present or changed. Keep the build number in every retest result so findings from different versions are not mixed together.

10. Prepare the release summary

Summarise what was tested, the devices and builds used, open issues, fixed issues and known limitations. This creates a clearer release decision than a simple pass/fail statement.

Need hands-on testing? Explore Gigsdo mobile app testing and Android QA, or compare it with managed Google Play closed testing.

Useful next steps

• Write a reproducible bug report