How We Test Mobile Applications Before Launch

Why Mobile App Testing Is Harder Than It Looks

When a client says "just make sure everything works" — that phrase conceals several hundred scenarios, dozens of devices and platforms, varying OS versions, and unpredictable network conditions.

A mobile app doesn't run in the controlled environment of a browser. It runs in a user's pocket: during a phone call, on low battery, in a subway tunnel on a spotty 4G connection, on a budget Android device from 2021. Each of these conditions is a potential source of a crash or a bug that nobody caught in the office.

The numbers speak for themselves: according to industry analysts, 71% of users delete an app after their first crash. The average cost of fixing a bug in production is 6–15 times higher than fixing it during testing. And an app's rating in the App Store or Google Play, once tanked by a wave of negative reviews, takes months to recover.

In our team, testing isn't the final stage of development. It's a parallel process that starts in the first sprint and ends only after a stable release. Here's how it works in practice.

Stage 1: Manual and Exploratory Testing

Automation doesn't replace humans — especially where it matters to "feel" the product: how intuitive the navigation is, whether the animations feel natural, whether a button label confuses users.

Manual testing covers three main areas:

Functional testing — verifying every usage scenario against test cases. Registration, authorization, core user flows, edge cases (empty fields, invalid input, server failure). Every scenario is documented in advance with its expected outcome.

UI/UX testing — adherence to design specs, correct display across different screen resolutions, behavior on orientation change, accessibility for users with special needs (font size, contrast, screen reader support).

Exploratory testing — the tester works without a script, trying to "break" the app through unexpected actions. This is where bugs appear that no test case anticipated: rapid double-taps, changing language mid-session, opening multiple screens simultaneously.

A rule we follow: every test case is written before feature development begins, not after. This disciplines the team and eliminates "well, it roughly works" moments before release.

Stage 2: Automated Testing

Manual testing is irreplaceable, but it doesn't scale. As an app grows and new releases ship every two weeks, running 400 test cases by hand becomes physically impossible.

We build automated testing on three levels:

CI/CD integration. All automated tests run automatically on every pull request. If unit tests fail — the branch doesn't merge. This eliminates an entire class of "broke something elsewhere without noticing" problems.

Snapshot testing for Flutter and React Native captures the visual state of components and catches unintended UI changes — when the layout shifted after a fix that had nothing to do with the interface.

Stage 3: Testing on Real Devices

Emulators and simulators are useful for quick checks. But they don't replicate real hardware: chipset-specific behavior, camera quirks, battery characteristics, manufacturer gestures layered on top of Android.

Minimum device matrix for release:

Why are budget devices a priority for the Uzbekistan and CIS market? According to analysts, more than 60% of users in the region use Android devices priced under $200. An app that runs perfectly on a flagship can lag or crash on a Redmi Note with 3 GB of RAM. You need to know that before release, not after.

For cloud-based testing across a broad device matrix, we use Firebase Test Lab and BrowserStack — they provide access to hundreds of real devices without maintaining a physical device lab.

Stage 4: Performance Testing

Performance isn't about "runs fast." It's about how the app behaves under conditions far from ideal.

Metrics we measure:

• Cold start time — from tapping the icon to ready-to-use. Benchmark: under 2 seconds for Android, under 1.5 seconds for iOS
• UI response time — from user action to visual feedback. Critical for lists, animations, scrolling: threshold — 16 ms (60 fps)
• Memory consumption — a typical session should stay within reasonable limits for target devices
• Battery drain — background processes, geolocation, and push notifications can drain the battery noticeably faster than normal if implemented inefficiently
• Behavior on poor networks — 2G, unstable 3G, switching between Wi-Fi and mobile data

Tools: Android Profiler, Xcode Instruments, Firebase Performance Monitoring, Charles Proxy for simulating poor network conditions.

The typical mistake: testing performance only on Wi-Fi and flagship devices. A real user in Fergana or Samarkand opens the app on a Xiaomi Redmi 9 with 4G during peak hours. That's who you're optimizing for.

Stage 5: Security Testing

Mobile app security isn't just about HTTPS. It's an entire layer of vulnerabilities specific to mobile platforms.

What we check:

On-device data storage. Tokens, passwords, and personal data must not be stored in plain text in SharedPreferences, UserDefaults, or app logs. This is one of the most common vulnerabilities in mobile applications.

Data transmission. Verifying correct TLS implementation, the absence of certificate pinning bypass, protection against man-in-the-middle attacks via Charles or mitmproxy.

Authentication and sessions. Proper token expiry, inability to reuse revoked sessions, brute-force protection.

Code protection. Obfuscation and minification for Android (ProGuard / R8), reverse engineering resistance, absence of sensitive data in the binary (API keys, hardcoded passwords).

Testing against the OWASP Mobile Top 10 — the standard we use as a checklist. Ten vulnerability categories specific to mobile applications, from insecure data storage to insufficient cryptography.

Stage 6: Regression Testing and the Final Checklist

Before every release — a full regression run. The goal: confirm that new changes haven't broken what was working before.

The regression suite is built from:

• All automated tests
• Manual test cases for critical flows
• Tests written for closed bugs (so they don't come back)

The final pre-release checklist is a document signed off by the QA lead and the development team lead. Without it, the app doesn't go to the store.

What it includes:

• All critical and high-priority bugs are closed
• Automated tests are green on target platforms
• Real-device testing across the device matrix is complete
• Performance is within established benchmarks
• API version is compatible with the current backend
• Screenshots and metadata for App Store / Google Play are up to date
• Analytics and crash reporting (Firebase Crashlytics / Sentry) are connected and functioning
• Deep links and push notifications verified on both platforms

The average regression suite for an app with six months of history contains 150–300 test cases. A full manual run takes 2–3 days. That's exactly why automation isn't optional — it's a necessity once a project reaches a certain scale.

Conclusion

Testing a mobile application isn't "press some buttons and see what breaks." It's a multi-layered process that directly impacts product quality, store reputation, and user trust.

Six stages we go through before every release:

• Manual testing — functional, UI/UX, and exploratory
• Automation — unit, integration, and E2E tests in CI/CD
• Real devices — a device matrix focused on the budget segment
• Performance — cold start, memory, battery, poor network
• Security — OWASP Mobile Top 10, data storage, transmission, code
• Regression and final checklist — formal sign-off on release readiness

A good mobile app isn't one that doesn't crash on a developer's MacBook. A good app is one that works reliably for the end user in real-world conditions. That's exactly what this entire process is built for.