How To Test A Mobile App: Step-by-Step QA For iOS & Android

Step 2. Pick devices, OS versions, and networks

You can't test every device. You can test the right ones.

Build a targeted device matrix

!Build A Targeted Device Matrix

Pull your analytics data or your target market research. For most apps, 80% of users are on 6–10 device/OS combos. We typically test on:

• iOS: Latest version and one version back, on iPhone SE (small screen), iPhone 15 (mainstream), iPhone 15 Pro Max (large screen)
• Android: Latest two OS versions, on a Samsung Galaxy S series (flagship), a Pixel (stock Android), and a budget device like a Redmi Note (where performance issues show up first)

That's 8 configurations. Covers the range without burning a week.

Test under real network conditions

Wi-Fi in your office is not representative. Your users are on spotty LTE in a subway, on hotel Wi-Fi with a captive portal, or on 3G in a rural area.

Use network throttling tools (Charles Proxy, Android's built-in network emulator) to simulate:

• 3G speeds (750 kbps down)
• High latency (300ms+)
• Packet loss (5–10%)
• Airplane mode toggle mid-flow

We once found a bug where an app silently dropped a user's form submission on a network switch from Wi-Fi to cellular. The data just vanished. No error, no retry. That one only showed up on a throttled connection test.

Step 3. Test core flows on real devices

Simulators are fine for early development. They're not fine for QA sign-off. Real devices catch things emulators miss: touch response delays, camera permission dialogs that render differently, hardware-specific rendering bugs, and battery-related throttling that kills background sync.

Run structured test sessions

Each session follows a written test case. The tester knows the steps, the expected result, and how to flag a deviation. Free exploration has its place — in dedicated exploratory sessions with a time box and a theme, not during core regression.

A test case looks like:

1. Precondition: User logged in, cart has 2 items
2. Steps: Tap checkout → Select shipping → Enter payment → Confirm
3. Expected: Order confirmation screen with order ID
4. Actual: [Tester fills in]
5. Pass/Fail

Log defects so someone else can reproduce them

A bug report that says "checkout broken on Android" is useless. A bug report that says "Checkout fails on Samsung Galaxy A54 running Android 14, build 2.3.1-rc2, after adding 3+ items with a promo code applied — payment button becomes unresponsive after 2 taps" gets fixed in a day.

Every defect log needs: device, OS version, app build, steps to reproduce, expected vs. actual result, and a screen recording if possible.

Step 4. Automate regression and run in CI

Once your core flows are stable and your test cases are documented, automate the repetitive ones.

What to automate first

Start with:

• Login/auth flows — these break constantly and block everything downstream
• Core purchase/conversion paths — the money flows
• Smoke tests — does the app launch, load the home screen, render without crashing?

Skip automating anything that changes frequently (UI-heavy features in active redesign) or requires subjective judgment (animations, "does this feel right").

| Automation Priority | Criteria |

|--------------------|----------|

| High | P1 flow, runs every sprint, stable UI elements |

| Medium | P2 flow, runs weekly, moderate UI stability |

| Low | Edge case, rarely executed, frequently changing UI |

Tools we use: Detox for React Native end-to-end tests, Maestro for cross-platform flow testing, Appium when we need broader device coverage through BrowserStack's device farm.

Connect tests to your CI pipeline

Tests that don't run automatically don't run consistently. Wire your automated suite into your CI system (GitHub Actions, Bitrise, CircleCI) so every pull request triggers:

1. Unit tests
2. Integration tests
3. A smoke test on 2–3 target devices
4. Full regression on the release branch (nightly)

Our default setup runs smoke tests on every PR (takes ~8 minutes) and full regression nightly (takes ~35 minutes across 6 devices via BrowserStack). A developer whose PR breaks a smoke test gets a Slack notification within 10 minutes.

How to keep quality high after launch

Shipping isn't the finish line. The first 72 hours after a release are when real users hit edge cases your test matrix missed.

Monitor crash rates through Firebase Crashlytics or Sentry. Set alerts for crash-free rate dropping below 99.5%. Watch app store reviews daily for the first week — users report bugs there before they email support.

Keep running your automated regression suite on every release branch, not just during active sprints. When you catch a regression before it ships, you skip the emergency hotfix cycle entirely.

If your team doesn't have the QA bandwidth to maintain this after launch, that's worth fixing. Talk to the Brilworks team — we embed QA engineers who own quality from sprint one through post-launch monitoring.