A mobile application runs in an environment the team only partly controls. Users change networks, lock the screen, deny camera access, enlarge text, and return through notifications. The OS may restrict background work or terminate the process. These are ordinary operating conditions for mobile QA.
Mobile testing must evaluate the business journey together with the device, OS, and state transitions. A screen that works after a clean launch may lose data after a brief switch to another application.
The layers involved in a journey
A useful model includes the interface, local data, network exchange, backend, and system integrations. Tapping Send may update a local record, queue an operation, and only later obtain server confirmation.
Visible success does not always mean completion. QA should identify the source of truth: what is saved, what awaits synchronization, and what another device should see. Without this model, legitimate delays can be reported as data loss, or local success can be mistaken for a completed operation.
Lifecycle and recovery
Distinguish active use, backgrounding, returning, fresh launch, and recovery after process termination. They can look similar while using different data-preservation mechanisms.
Check forms, navigation, uploads, and sessions. Android may recreate screens after configuration changes, so verify state preservation explicitly. User force-close, system termination, and ordinary backgrounding are separate scenarios; avoid describing all three simply as “restart the app.”
Networks as changing conditions
Test good, slow, and unavailable networks, Wi-Fi-to-cellular transitions, and disconnection during transfers. Check timeouts, loading-indicator completion, and the outcome of repeated actions.
Offline does not mean an empty screen or necessarily full independence from the server. Specify what is cached, what can be edited, and when changes are sent. Resynchronization must not create duplicates or silently overwrite newer data without an agreed rule.
Permissions and system integrations
Camera, location, notifications, and access to selected data have their own permissions and restrictions. Test first access, permission grant, denial, and revocation through settings. Available options depend on OS and version.
Request permission in an understandable context. If camera access is denied, provide the intended alternative or explain unavailability. Denying an optional permission must not block unrelated actions. Also test returning from system dialogs, file pickers, payments, and external login.
Devices, interface, and accessibility
Small screens, enlarged system text, cutouts, keyboards, and navigation methods change interactions. Consider orientation, theme, locale, and long data. Foldables and tablets may also need resizing and multiwindow checks.
- →Can users see and activate confirmation with the keyboard open?
- →Do labels retain their meaning with enlarged text?
- →Are element names and ordering understandable in VoiceOver or TalkBack?
- →Do application gestures conflict with system navigation?
Select checks according to supported devices and features, rather than maximizing the number of screens in a report.
Installation and upgrades
Installed clients may remain in use for months while the backend changes. Test upgrades from supported earlier versions as well as clean installations, including preservation of local data, sessions, and settings.
Local storage migration is a particular risk. Prepare an older version with realistic data, upgrade, and compare state. Uninstalling before every run removes accumulated context and hides defects experienced by long-term users.
Selecting devices
Base the matrix on the audience, minimum supported OS, memory and screen characteristics, manufacturers, and feature risks. One new flagship cannot represent the entire fleet.
Emulators and simulators support reproducibility, configuration variety, and automation. Real devices confirm specific hardware, energy consumption, performance, and system integrations. Combine them: localize problems quickly, then confirm them in the relevant user environment.
Practical example: submitting a photo report
An employee takes a photo, adds a comment, and submits a report. Without connectivity, the product promises to retain a draft and clearly indicate pending submission.
- 1.Create a report with camera permission granted. Expect an available photo and saved comment.
- 2.Start transfer and switch networks. Expect a defined status instead of endless loading or false confirmation.
- 3.Background the app, lock the screen, and return. Expect the draft to persist and processing to resume according to requirements.
- 4.Restore connectivity and repeat the action. Expect one server record with the complete attachment, available on a fresh read.
- 5.Repeat creation after revoking camera permission. Expect an explanation and intended alternative without a crash.
Diagnosis and useful defect reports
Record the device model, OS version and build, app version, installation method, network state, permissions, and preceding actions. “Does not send on Android” is insufficient: the issue may depend on an upgrade, background transition, and particular data.
Attach the event time, video, available system logs, and test operation ID. Compare UI, local state, and server response. Remove tokens, personal photographs, and other sensitive information.
Common mistakes and lessons
Common mistakes include always reinstalling, treating backgrounding as equivalent to process termination, and relying exclusively on emulators. Testing networking as an isolated checklist item without a real business operation is another.
Strong mobile QA tests transitions: online → offline, active → background, old version → new version, granted → denied. These boundaries most often expose disagreement between the screen, local data, and server state.