02 /QA & Manual Testing
Mobile App Testing
Testing native and cross-platform apps on hardware people actually own, under the conditions apps actually meet: a call arriving mid-flow, a network dropping between screens, an operating system version two releases behind. Emulators are useful for speed and misleading for confidence.
What you get
A device matrix argued from your data
Chosen from the models, operating system versions and screen classes your own analytics report, not from a general popularity chart. The tail is longer and older than most teams expect, and it is where the reports come from.
Interruption and lifecycle coverage
Incoming calls, backgrounding, low memory, permission revocation and process death mid-task. These are the paths that produce one-star reviews, and they are almost never covered by a scripted happy path.
Network condition testing
Slow, flaky, offline and switching between mobile data and wi-fi mid-request. An app that assumes connectivity behaves very differently from one that handles losing it, and the difference only shows under those conditions.
Install, upgrade and migration checks
Upgrading over an old version with existing local data is a distinct path from installing fresh, and it is the one that breaks. It is also the one that reaches every existing user at once.
Store readiness review
A pass over the things that get a submission rejected or a rating damaged: permission prompts and their justifications, orientation handling, accessibility labelling, and behaviour on the smallest supported screen.
How it runs
- 01
Agree the matrix
We take your install base and pick the smallest set of devices that covers the meaningful variation in it. Testing thirty devices badly is worse than testing eight of them properly.
You provide: Analytics on device, OS version and locale distribution
We produce: An agreed device and OS matrix
- 02
Cover the flows
Functional passes over the core journeys on each tier of the matrix, with the differences between platforms treated as findings rather than as expected variation.
We produce: Execution records per device tier
- 03
Break the conditions
Then the part that distinguishes mobile testing from testing a website on a small screen: interruptions, permission changes, network degradation, backgrounding and upgrade paths.
We produce: Condition-specific defect reports
- 04
Report and retest
Findings ranked by how many of your users can reach them, using the same distribution that shaped the matrix, so severity reflects reach rather than how unusual the reproduction felt.
We produce: Cycle report · Retest verification
Where this stops
- Not automated mobile testing. Building a maintainable device-farm suite is a framework project with its own cost, and it belongs under test automation rather than here.
- Not app store submission or release management. We test what you are about to ship; we do not operate your developer account or manage the rollout.
- Not performance profiling at the code level. We report that something is slow, on which device, and under what conditions; instrumenting and fixing the cause is engineering work on your side.
- Not a security assessment of the mobile binary. Reverse engineering, certificate pinning and local storage review are a different discipline from functional testing.
Related reading
- Quality assurance
How to write a bug report a developer can act on
A defect report is a handover of an unfinished investigation. Most of them fail in the same three places, and none of the repairs involve a longer template.
- Test automation
Test data management: five strategies and what each one costs
How a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
- Test automation
When to automate a test, and when the answer is no
Not a philosophy of automation but a decision taken one case at a time. Five signals, four possible verdicts, and why "keep it manual" is not the losing option.
FAQ
Mobile App Testing questions we hear often
Can you test on emulators instead? They are cheaper.
For layout and basic flows, yes, and we use them for exactly that. What emulators cannot tell you is how the app behaves on a three-year-old handset with limited memory, a degraded battery and a real cellular connection. Most of the defects worth finding on mobile live in that gap, so an emulator-only pass buys speed at the cost of the findings you were paying for.
How many devices do we actually need to cover?
Usually fewer than the matrix people arrive with, and different ones. The useful selection covers the extremes rather than the middle: your oldest supported OS version, your smallest screen, one current flagship, and whichever manufacturer skin is over-represented in your install base. Adding a ninth similar device rarely finds anything the first eight did not.
Does this cover React Native and Flutter apps?
Yes, and cross-platform frameworks make it more necessary rather than less. A shared codebase produces genuinely different behaviour on each platform once it touches permissions, keyboards, back navigation or the file system, and those divergences are invisible until someone runs the same flow on both.
What about accessibility on mobile?
We check screen-reader labelling, focus order, touch target sizes and text scaling as part of the functional pass, because on mobile these are usability problems before they are compliance problems. A formal conformance audit against a standard is a separate engagement, and we would say so rather than let a functional pass be mistaken for one.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.