How to Test Mobile Apps for Critical Bugs

Manual mobile testing uses human observation and controlled interactions to investigate whether an app behaves as intended. It is especially useful for unfamiliar workflows, interruptions, accessibility, and confusing recovery states. It works alongside automated checks; neither approach can prove that an app has no bugs.

This guide provides a risk-based plan for an illustrative appointment-booking app. Replace the sample cases with your product’s requirements and supported devices before execution.

Define the risks before selecting devices

List the journeys that must work: sign in, select an available appointment, confirm it once, view it after restarting, and cancel it with a clear result. Name the harm if each fails. Double bookings, leaked account data, and a lost cancellation deserve more attention than a cosmetic alignment issue.

Record the build identifier, backend environment, feature flags, supported OS versions, test accounts, and known limitations. Use synthetic data and a sandbox for payments or notifications. Confirm that test actions cannot affect real customers.

Build a manageable device and condition matrix

Use audience analytics, support incidents, minimum OS support, and hardware requirements to choose actual device models. Before launch, use the intended audience and documented support policy. The rows below are selection rules, not a universal list of sufficient devices.

Coverage row	Select	Priority checks
Common iPhone	A physical device on the most-used supported iOS version	Core journey, keyboard, permissions, notifications
Older supported iPhone	Device and OS near the support floor	Installation, launch, layout, responsiveness
Common Android device	Physical device representative of the audience	Core journey, back navigation, lifecycle, network changes
Constrained Android device	Supported low-memory or smaller-screen model	Process recreation, long lists, slow loading, storage failure
Accessibility	Supported device with screen reader and enlarged text	Labels, focus order, error announcement, reachable controls
Tablet or landscape	Only when supported	Rotation, split views, keyboard, preserved draft state

Test network loss, slow connectivity, Wi-Fi-to-cellular changes, denied permissions, backgrounding, restart, timezone changes, and low storage where they matter to the journey. Use exact device/OS/build identifiers in the results; “tested on mobile” cannot be reproduced.

Local devices, cloud devices, and simulators

Local physical devices support direct observation of touch, cameras, sensors, audio, and real-world interruptions. A real-device cloud can broaden access to hardware, but check whether the session supports the exact sensor, network, notification, or battery condition being investigated. Remote access does not automatically reproduce every real-world condition.

Simulators and emulators are useful for fast checks across layouts and OS configurations. They complement physical hardware, especially when hardware-specific behavior matters. Follow Apple’s simulator/device workflow and Android’s testing fundamentals when setting up platform coverage.

Executable example test cases

The expected results below are proposed requirements for the illustrative app. Agree on the intended behavior with product and engineering before using them as release criteria.

Case and precondition	Steps	Expected result and evidence
Interrupted confirmation; signed in, slot selected	Submit a booking; cut connectivity before the response; restore it; retry	App resolves the pending outcome without creating a duplicate. Record the visible result and server-side booking IDs
Slot taken; two test accounts see the same slot	Confirm it with account A, then submit from account B	B receives an unavailable message and can choose another slot; only one booking owns the slot
Permission denied; notifications not yet requested	Deny notifications, book a slot, reopen the app	Booking remains usable in-app; app explains the notification limitation without trapping the user in a prompt loop
Background/relaunch; partially entered draft	Background the app, then test process termination and relaunch separately	Saved or discarded fields follow the agreed rule; no silent confirmed booking or misleading success screen
Session expiration; expired test session	Try to open a private booking and change it	Reauthentication is required; private data is not exposed to another signed-in account
Timezone change; booking exists	Change the device timezone and reopen the booking	Display follows the documented timezone rule; underlying appointment time is unchanged
Accessibility; screen reader active	Complete sign-in and booking without relying on visual position	Controls have meaningful names, focus follows the workflow, and validation errors are announced
Upgrade; prior released build has saved data	Install the new build through the supported upgrade path	Account and booking state remain correct; migration failure has a recoverable outcome

Also test clean install, logout, account switching, repeated taps, cancellation retries, deep links, and loss of backend access where applicable. Specify what happens to unfinished work rather than assuming every interruption should restore it.

Record useful bug evidence

A report should include:

• Concise title and user impact.
• App build, device model, OS version, environment, and relevant flags.
• Preconditions and exact numbered reproduction steps.
• Expected result and actual result, with reproduction frequency.
• Redacted recording or screenshot, timestamps, and relevant log/request IDs.
• Severity, affected journey, workaround, and proposed owner.

Example: “Retry after network loss creates a second booking.” On test build B17, disconnect after tapping Confirm, reconnect, and tap Retry. Expected: one booking. Actual: two booking IDs for the same account and slot, reproduced 3 of 3 attempts on the recorded device. This is an illustrative report, not a Hapy incident.

Severity describes impact; priority also considers exposure, workarounds, and release timing. Avoid including credentials or customer information in attachments.

Combine manual exploration and automation

Unit tests check isolated logic such as date conversion or fee calculation. Tapping a button and observing a complete app response is a UI or system-level test, not an isolated unit test. Integration tests check boundaries such as booking storage and notification scheduling.

Automate stable, repeatable assertions where doing so is useful: availability conflicts, retry idempotency, authorization boundaries, and high-value regression journeys. Use manual exploration to vary sequence, interruptions, content, and user expectations. Both can detect errors caused by human mistakes in implementation; neither tests everything automatically.

Usability sessions with representative users answer a different question from scripted functional QA: can people understand and complete the task? Performance profiling and security assessment also need their own methods and expertise. A functional test passing does not establish that a service is secure or handles production load. A/B testing compares product outcomes between variants; it is not a replacement for pre-release defect testing.

Decide whether the release can proceed

Agree on release gates before testing. For this example, a reasonable proposed gate is: all critical booking and account-isolation cases pass on the agreed device matrix; no unresolved duplicate bookings, data loss, or unauthorized access; fixes are retested; and known lower-impact issues have named owners and explicit acceptance.

Record untested combinations and residual risks. If a critical case fails, stop the affected rollout, investigate, and rerun the failed case plus the relevant regression checks after the fix. Do not hide a blocker behind an overall pass percentage.

A release review should contain the tested build, coverage matrix, results, open defects, accepted limitations, and the person approving release. Monitor crash and workflow failures after launch and maintain a recovery plan. Evidence of coverage supports a decision; it is never a guarantee of zero defects.

Talk to Hapy to define a mobile test scope tied to your product’s most important journeys.

FAQs

Can manual mobile testing be performed on real devices?

Yes. Testers can use local physical devices, remote real-device services, and simulators or emulators. Choose the environment that can reproduce the condition being tested.

What is an example of manual mobile testing?

Interrupt a booking confirmation by disconnecting the network, reconnect, and retry. Check the app message and backend records against the requirement that the request creates only one booking.