A test plan before your mobile app's first release

Why mobile is a separate topic

A web app runs in a few browsers. A mobile app runs on hundreds of phone models, several OS versions, with different permission settings, on weak signal and with interruptions from phone calls. Add App Store and Google Play review, which you can’t “fix with a five-minute hotfix”.

Below is the list I start mobile app testing with before a release.

1. Device matrix

Don’t test on everything. Build the matrix from data:

OS versions. The last two major iOS versions and four or five Android versions usually cover most users. Check the minimum version set in the project.
Screen sizes. The smallest supported phone, a typical one and a large one. Plus a tablet if the app supports it.
Android manufacturers. System skins (such as aggressive battery saving) can kill background processes and block notifications.

2. Install and update

Fresh install and first launch (onboarding, consents).
Update from the previous version with data and session preserved.
Uninstall and reinstall.

Updating is the scenario most often forgotten at first release, because there’s no previous version yet. Prepare it straight away, before the second release.

3. Permissions

For each permission (camera, location, notifications, contacts) check three paths: allow, deny, and deny with “don’t ask again”. The app must not freeze or leave the user without an explanation of what to do next.

4. Network and offline mode

No network at app start.
Losing signal while submitting a form or a payment.
Switching from Wi-Fi to mobile data.
A slow connection: does the user see a loading state or a blank screen.

The most dangerous mobile bugs are the ones that cause duplicate operations: two orders or two payments after a retried request.

5. Interruptions and lifecycle

An incoming call, switching to another app, locking the screen, rotating the device. On return, the app should be in the same state and entered data shouldn’t disappear.

6. Notifications and deep links

Check that a notification opens the right screen when the app is closed, in the background and in the foreground. The same goes for links from email or SMS.

7. Store requirements

A working test account for App Store reviewers.
A privacy policy reachable from the app.
Account deletion from within the app, if registration is possible.
Permission descriptions in Info.plist that explain why the app needs them.

What to automate

To start: login, the main business path and payment. With Appium you can write one suite for both platforms, while XCUITest and UIAutomator (Espresso) give faster, more stable native tests at the cost of two separate suites.

// UIAutomator: check that the app returns to the cart screen
device.pressHome()
device.findObject(By.desc("My app")).click()
device.wait(Until.hasObject(By.text("Cart")), 5_000)

Summary

A mobile app’s first release stays with users for a long time, because not everyone updates quickly. It’s better to spend a week testing to a plan than a month firefighting and answering one-star reviews. If you’d like me to prepare and run the tests for your app, describe your project. If the app is still to be built, my company can do that: the software house 2Simple.