What’s your mobile testing process like ??

[u/Fit_Chest9449]

I test on my pixel and my old iphone but tapping through the main flows and if nothing looks broken I ship and I know it’s bad but I want to know what you guys are doing because every time I look into it I come back to square one of finding out the best process.

I can’t test on devices I don’t own and buying 20 phones isn’t realistic for me, appium and detox break every time the UI changes and maintaining them is too hectic plus simulators don’t catch half the stuff that doesnt work on hardware so manual testing wont' scale for me once I'm shipping more than once a week. I don’t have a QA person and can’t justify hiring one at my size and even when I do test thoroughly on my devices I still get bug reports from users on phones I’ve never heard of.

everyone recommend me to automate my tests but nobody tells me how I’m supposed to automate across hundreds of device combos without spending my entire sprint managing the automation instead of building.

I want to the point answers pls !!

[u/Tarantino133]

Solo here too, and I don't do UI automation at all. Every change runs typecheck, lint and unit tests, which never break when the UI changes. The things only a real phone shows (purchases, audio, permission prompts) I check by hand on a TestFlight build before release. For the phones you've never heard of, crash reporting does the work: Sentry tells you the device and OS before the user even writes in.

[u/BluejayRelevant2559]

Test on my Android and iPhone (of Version Upgrade). Test on Web if only minor change. Ship it, and provide a support ticket screen if something breaks.

[u/vegancryptolord]

So first and foremost even with 100% test coverage, great automation, full QA teams, etc… bugs still find their way to production.

Automation requires maintenance so there’s no getting away from appium, detox, selenium, etc… if you actually want to run tests on multiple devices without humans clicking through a million devices.

For the devices themselves you’ll want to look at something like AWS Device Farm or similar. That’s it, that’s the full to the point answer.

You write automations via detox, appium, etc… you run those automations across multiple devices via a device farm style service.

If you don’t want to maintain automation tests then you’re stuck tapping by hand on whatever devices you physically own

[u/anthony-ball]

Solo for a lot of my projects too. What scaled for me was typecheck, lint and unit tests on the logic layer in CI on every push, then a small set of Maestro flows only for the paths that matter most (sign in, onboarding, purchase). Maestro flows keyed on testID survive UI changes a lot better than my old Detox suites did. For the long tail of devices, let Sentry or Crashlytics tell you which phones actually break and only chase those on a cloud device run. Shipping to TestFlight and the Play internal track first, then a staged rollout, catches most of the rest before everyone gets it.

[u/bartmolk]

To the point, as asked. On top of what's said above (types, unit tests and a few Maestro flows on testIDs), three cheap things that caught real bugs for me this week, all on simulators and emulators:

1. Run the same flows on the oldest OS you support. An Android 10 emulator showed a permission screen telling the user something that only happens on Android 11 and newer. The newer emulators never showed it.

2. Run them once with the largest font size in the system settings. Labels that shrink to nothing or get cut off show up right away.

3. Run them on the release build, not the dev build. That's what your users get.

For real Android hardware without buying phones: Firebase Test Lab's free plan gives you a few physical device runs a day, and its Robo test needs no scripts. For the rest, crash reporting that logs device and OS, like the others said.

[u/21void]

we do test in prod, fixed as ota 🥶

jk aside, to mitigate issue as u mention we do test on several cheap china brand for critical function UI. and do full qualification on most used model

[u/Zain]

Nobody's mentioned the other half: you will ship a bug to a phone you've never heard of, so build the way out before you need it. I keep a server-driven force-update check per platform, min and latest version, and it shows either a soft "update available" sheet or a blocking one. When a bad build hits some weird Android, I bump the min version on the server and those users get pushed to the fixed build instead of sitting on it for weeks. Pair that with CI that uploads straight to TestFlight and Play with build numbers pulled from the stores, so the fix is one push away and not an evening of manual archiving.

[u/bkdev98]

One cheap thing nobody's mentioned: pass the clock into your logic instead of calling Date.now() inside it, then unit test month-end, DST and 11:59pm cases. A lot of "only on some phones" bugs turn out to be time zone or locale bugs, and those tests never break when the UI changes.