Solo developers and small teams do not skip testing because they think it is unimportant. They skip it because the day before launch there are forty things to do and no obvious way to rank them.
So here is a ranking. This checklist is ordered roughly by how often each item is the thing that produces a one-star review in week one. Work down it, and stop when you run out of time — you will have covered the expensive failures first.
Tier 1: The launch blockers
If you check nothing else, check these.
Fresh install on a device that has never seen your app
Not a rebuild over your existing dev install. A genuinely clean install, on a device with no cached data, no keychain entries, no saved credentials.
An enormous share of catastrophic launch bugs live in the gap between "the app as you have it" and "the app as a new user gets it." You have been running with an account that was created six versions ago. Your first user has not.
The complete first-run experience, start to finish
Install → onboarding → account creation → email or SMS verification → first meaningful action. Every screen, no shortcuts, real email address.
Verification flows are the classic failure: the email lands in spam, the deep link opens the wrong screen, the token expires too fast, or the "resend" button does nothing. Every one of those loses a user permanently at the very first step.
Payments, end to end, with real money
If you charge, run at least one real transaction on each platform. Then run the failure cases:
- A declined card
- Cancelling the payment sheet halfway
- Losing connectivity mid-transaction
- Restoring purchases on a fresh install
- What a user sees if payment succeeds but your server does not hear about it
That last one is the nastiest bug in commerce apps, and it is invisible until it happens to a paying customer.
Permission denial paths
Someone will tap "Don't Allow" on camera, location, notifications, and photos. What happens? A crash, a blank screen, or a graceful explanation with a route to settings?
Test denial and, on iOS, "Allow Once", which expires and behaves differently on the next launch.
No network, and bad network
Turn on airplane mode and use the app. Then re-enable and check it recovers. Then try the harder case: a connection that is technically alive but very slow.
You are looking for infinite spinners, blank screens with no explanation, actions that silently do nothing, and lost user input.
Tier 2: The credibility killers
These rarely crash the app. They make it look amateur, which is nearly as costly.
Backgrounding and resuming
Background the app mid-flow — mid-form, mid-upload, mid-payment. Leave it a few minutes. Come back. Is your state intact? Is your session still valid? On Android, force a process kill and confirm you resume gracefully rather than into a broken half-state.
Rotation and unusual screen sizes
If you support landscape, rotate on every screen, especially ones with keyboards or modals open. Check the smallest device you support and the largest — small screens truncate, large screens and tablets stretch layouts into strange shapes.
System font scaling and dark mode
A meaningful number of users run larger text sizes. Turn font scaling up and look for clipped labels, overlapping text, and buttons whose text no longer fits.
If you support dark mode, check every screen. Hardcoded colours show up as white-on-white or invisible icons, and they are always on the screen you forgot about.
Deep links and notification taps
Tap a push notification with the app closed, backgrounded, and open. Does it route correctly in all three states? Do your marketing and email links open the right screen rather than dumping the user on the home screen?
Empty, long, and hostile content
Every list needs an empty state. Every text field needs to survive a very long input, emoji, right-to-left characters, and a leading space. Every avatar needs a fallback for the user with no photo.
Tier 3: Before you scale
Older and slower devices
Your test device is probably better than the median device of your audience. Find the oldest supported device you can and run the core flow. Watch for slow launches, janky scrolling, and out-of-memory kills.
Accessibility basics
Turn on VoiceOver or TalkBack and try the primary flow. You do not need full compliance on day one, but unlabelled buttons and images make the app unusable for some users and are a fast fix.
Also check colour contrast on your secondary text. Light grey on white looks elegant in your design tool and disappears in sunlight.
Interruptions
Take a phone call mid-flow. Get a notification during payment. Let the screen lock and unlock. Trigger low battery mode.
The uninstall/reinstall cycle
Uninstall and reinstall while logged in. Does the user get back to their data, or does the app act as though they are new? On iOS, remember the keychain survives uninstall — which produces its own confusing half-logged-in states.
Working the list efficiently
Test the unhappy paths first. Your happy path is the one you have exercised a thousand times during development. The bugs are in denial, cancellation, failure, and interruption.
Write down device and build for anything you find. Future-you will not remember. See our guide on writing bug reports that get fixed.
Get someone else to run it. You cannot un-know your own app. You skip past ambiguous screens automatically because you know what they mean. A person who has never seen it gets stuck in places you cannot see any more — and being stuck is what your real users will do.
That last point is the one with the worst effort-to-value ratio to solve alone, and it is the reason organised outside testing exists: fresh eyes, on devices you do not own, running the flows you are too close to see.
Bugfed handles that part — vetted testers on real devices running your build, with structured reports so you get findings rather than a group chat full of screenshots.