Android QA
Android Beta Testing Checklist for Indian Users and Devices
A practical Android QA checklist covering device diversity, weak networks, OTP, dual SIM, UPI handoffs, language, permissions, accessibility, and evidence.
An Android beta can pass on the developer's phone and still fail for real users. The risk comes from combinations: a budget device on a weak network, an OTP arriving late after the app is backgrounded, or a UPI payment returning to a process Android has reclaimed.
Build a small, deliberate device matrix
Do not try to cover every Android model. Select devices that represent meaningful risk: your minimum supported Android version, the newest supported version, at least one memory-constrained device, small and large screens, and manufacturers that are common in your audience. Record model, Android version, available memory, screen size, language, and network for every result.
Google's Android quality guidance groups quality around core value, user experience, technical quality, and privacy and security. Use those pillars to keep the matrix focused on user outcomes rather than a list of hardware names. See the official Android app-quality guidance.
1. Installation, update, and first launch
- Install from the authorised Google Play closed-test link.
- Verify the correct app name, icon, screenshots, and version.
- Test first launch with fresh storage and with a restored backup where relevant.
- Upgrade from the previous build without losing user state.
- Interrupt download or update, then verify recovery and messaging.
- Check the result when storage is nearly full.
2. OTP, phone number, and dual-SIM journeys
- Enter valid, invalid, incomplete, and already-registered phone numbers.
- Delay the OTP, request a resend, and enter an expired or previously used code.
- Switch away from the app before the message arrives, then return.
- Test autofill and manual entry without assuming SMS permission is available.
- Use a dual-SIM device and verify that instructions do not assume one active number.
- Check rate-limit messages and recovery after too many attempts.
Record whether the failure belongs to the app, backend, SMS provider, network, or user instruction. “OTP failed” is not enough information to reproduce or fix the issue.
3. UPI and external-app handoffs
Payment and identity journeys often leave your process. Test with more than one compatible app when possible, then cover success, cancellation, pending, timeout, no compatible app, and returning after the operating system has reclaimed your activity.
- Verify the amount, merchant, order, and user-facing status before handoff.
- Cancel inside the external app and confirm the original app recovers clearly.
- Simulate a pending response and prevent duplicate payment attempts.
- Return through the back button, recents screen, and deep link.
- Reconcile the final server status instead of trusting only the client callback.
- Mask sensitive identifiers in screenshots, logs, and tester evidence.
4. Weak, changing, and absent networks
| Condition | What to inspect |
|---|---|
| Slow connection | Progress feedback, timeouts, duplicate taps, partial data |
| Connection lost | Saved state, retry safety, offline explanation |
| Wi-Fi to mobile | Session continuity, uploads, live connections |
| App backgrounded | Request cancellation, resume behaviour, stale screens |
| Service unavailable | Actionable message, retry timing, support path |
Watch for silent failure, infinite spinners, duplicate submissions, and screens that show success before the server has confirmed it. Recovery quality often matters more to users than peak speed.
5. Language, layout, and accessibility
- Use the longest supported labels and verify they wrap without hiding actions.
- Mix Latin and Devanagari text where the product supports it.
- Increase system font size and display size.
- Navigate the core journey with TalkBack and logical focus order.
- Check touch target size, contrast, error identification, and keyboard behaviour.
- Verify dates, times, currency, phone numbers, and address assumptions.
6. Permissions, privacy, and account controls
Deny each optional permission, choose “ask every time” where available, and revoke access after onboarding. The core journey should either continue or explain why a capability is necessary. Confirm that the privacy policy matches actual data collection and that account deletion, sign-out, and session expiry behave as described.
Turn the checklist into assignments
Give every tester one primary journey and one environment variable. For example: “Create an account and complete a UPI payment on a dual-SIM device while switching from Wi-Fi to mobile data.” This produces comparable results without making every person repeat the same happy path.
Use the findings to update your test and release decision, then retain a concise summary for the production-access application. Our Google Play closed-test checklist shows how to schedule that work across the 14-day window.