# Mobile app testing and QA: what to test before launch

> Good mobile app testing combines automated tests on every change with manual testing on real devices, plus performance, security, accessibility, and beta testing with real users before release. Testing throughout development is cheaper than fixing problems after launch.

Source: https://keepwarning.com/blog/mobile-app-testing-and-qa/  
Publisher: KeepWarning (Columbia, MD)  
Topic: Mobile app development  
Updated: October 12, 2026

## Key takeaways

- Test continuously, not just at the end.
- Automate repeatable checks; test usability and edge cases by hand.
- Cover the devices and OS versions your real users have.
- Run a beta with real users and watch crash reports before a wide release.

Users forgive a missing feature far more easily than a crash. Quality assurance (QA) is what protects your ratings and your reputation.

## The testing layers

| Layer | What it checks | How |
| --- | --- | --- |
| Unit tests | Individual pieces of logic | Automated, run on every change |
| Integration tests | Parts working together, APIs, database | Automated |
| UI and end-to-end tests | Key user journeys (sign up, checkout) | Automated on emulators and devices |
| Manual and exploratory | Usability, odd behavior, edge cases | Human testers |
| Beta testing | Real-world use on real devices | TestFlight, Google Play testing tracks |

## What to test

- **Core flows:** sign-up, login, purchase, booking, whatever makes money.
- **Devices and OS versions:** small and large screens, older supported versions, low-memory phones.
- **Network conditions:** slow connections, airplane mode, switching Wi-Fi and cellular.
- **Interruptions:** calls, notifications, low battery, backgrounding the app.
- **Performance:** start-up time, scrolling smoothness, battery and data use.
- **Security and privacy:** see our [mobile app security checklist](/blog/mobile-app-security-checklist/).
- **Accessibility:** screen reader labels, text scaling, contrast, touch target size.
- **Store rules:** meeting [App Store and Google Play requirements](/blog/how-to-publish-an-app-on-the-app-store-and-google-play/).

## Test throughout development

Fixing a bug found during development costs little. Fixing the same bug after release costs support time, refunds, and reviews. Ask your team to show **automated test results and working builds** in every demo.

## A pre-launch test checklist

Use this as a minimum before you release to the public.

**Functionality**
- Every primary flow works from start to finish (sign-up, purchase, booking, logout).
- Edge cases: empty states, long text, special characters, no results.
- Permissions: the app behaves when users decline camera, location, or notifications.

**Compatibility**
- At least two recent OS versions on each platform and the oldest version you support.
- A small phone, a large phone, and a tablet if supported.
- Dark mode, larger text sizes, and landscape orientation if allowed.

**Performance and reliability**
- Cold start time on an older phone.
- Behavior on slow networks and with the connection dropping mid-action.
- Memory and battery use during a normal session.

**Security and privacy**
- Data is encrypted in transit and sensitive data is not stored in plain text.
- Logs do not contain personal data. See the [security checklist](/blog/mobile-app-security-checklist/).
- Privacy policy and store privacy answers match what the app actually does.

**Accessibility**
- Screen reader can reach and describe every control.
- Contrast and touch target sizes meet guidelines. See [UX best practices](/blog/mobile-app-ux-design-best-practices/).

## Manual and automated testing: the right balance

| Automate | Test by hand |
| --- | --- |
| Logic that rarely changes, calculations, API behavior | New features and visual polish |
| Regression checks on key flows before every release | Exploratory testing: "what happens if I do something odd?" |
| Performance checks on each build | Usability with real people |

Automation catches regressions quickly and cheaply. People catch problems automation cannot imagine.

## How to run a beta

1. Recruit 20 to 100 testers who match your real audience, not just friends.
2. Distribute builds with **TestFlight** (iOS) and a Google Play **internal or closed testing** track (Android).
3. Give testers specific tasks and a simple way to report problems.
4. Watch crash reports and analytics, not only comments.
5. Fix the top issues, then release gradually to a small percentage of users before everyone.

## Severity helps you decide what to fix

| Level | Meaning | Action |
| --- | --- | --- |
| **Critical** | Crash, data loss, payment or security failure | Block the release |
| **High** | Core feature broken for many users | Fix before release |
| **Medium** | Workaround exists | Schedule soon |
| **Low** | Cosmetic | Backlog |

## Monitor after launch

Add crash and performance reporting so you see problems as they happen. Release gradually to a small percentage of users first, then widen. For ongoing care, see [mobile app maintenance cost](/blog/mobile-app-maintenance-cost/).

## Frequently asked questions

### What types of testing does a mobile app need?

Functional, usability, compatibility across devices and OS versions, performance, security, accessibility, and beta testing, plus automated unit and integration tests.

### How do I beta test an app?

Use Apple's TestFlight for iOS and Google Play's internal or closed testing tracks for Android to distribute pre-release builds to testers.

### How many devices should I test on?

Prioritize by your audience's analytics or market data: a few popular phones per platform, a small and a large screen, an older supported OS version, and one low-end device.