Mobile performance testing sounds like a specialist discipline, and the deep end of it is. But most of the performance bugs users actually complain about — slow launches, stuttery lists, an app that dies in the background — are catchable by any QA engineer with a low-end phone and some discipline. Here's what I measure and how, without special tools.
Cold start: the first number that matters
Cold start is the time from tapping the icon (with the app fully killed) to a usable first screen. Users feel this every day, and it regresses silently as features pile into startup. Measure it crudely but consistently: same device, same build type, kill the app, screen-record the launch, and count from tap to interactive in the recording. On Android, adb shell am start -W prints launch timing directly, and the system logs report a Displayed time per activity — free data most teams never look at. Track the number per release; the trend matters far more than the absolute value.
Jank, scrolling, and the low-end device rule
Jank is dropped frames — scrolling that stutters instead of gliding. On a flagship phone you will never see it, which is exactly why my strongest opinion here is: keep a cheap, old, low-end device in the test rotation. A budget Android with limited RAM surfaces jank, slow transitions, and memory issues years before they'd show on a developer's phone. For scrolling checks, I fling the heaviest lists in the app — images, long feeds — and watch on the slow device. Android's developer options can overlay GPU rendering bars if you want something more objective than your eyes, but honestly, on a weak phone, your eyes are a fine instrument.
Slow networks are a performance feature
Fast office Wi-Fi hides an entire category of bugs. I regularly run key flows on a throttled profile — simulator network conditioners and device developer settings both offer 3G-like presets — and watch for three things: spinners that never resolve, screens with no loading state at all, and requests that silently fail with no user feedback. This matters doubly in markets where mobile data is genuinely slow or metered; testing from Amman made me appreciate how differently an app behaves outside its home market's network assumptions.
Memory and battery, the observable way
Without profiling tools you can still catch the big offenders. For memory: use the app hard for ten minutes, background it, open a few heavy apps, return — does it resume where you left it or cold-restart? Frequent process death under mild pressure is a memory smell worth filing. Android's developer options also let you cap background processes to simulate pressure on demand. For battery: the OS battery screen names the top consumers, so after a long exploratory session, check whether your app appears unreasonably high. And a warm phone during light use is a real signal — some of my most useful performance bugs started as "the device gets hot on this screen."
Reporting mobile performance testing results
The value of all this is not precision; it's repeatability and early warning. A performance bug report needs the device model, OS version, build, network profile, and a measured comparison — "cold start went from about three seconds to about six on our low-end device between these two builds" is actionable in a way "the app feels slow" never is. Numbers from a stopwatch and a consistent method beat vibes every time.
Minimum viable setup: one low-end Android, one throttled network profile, cold start timed on every release candidate, and the heaviest list flung on every regression pass. That's an afternoon to establish and it catches the majority of what users will actually feel.
Specialists can take over when you need frame-level traces. Until then, QA measuring imperfectly every release beats a perfect audit that happens once a year.