Mobile App Testing Checklist: What I Check Before Every Release

Mobile apps break in ways web apps never will. A user walks into an elevator, loses signal mid-transaction, and your app corrupts their cart data. A phone call interrupts a form submission and the app forgets everything they typed. An OS update changes permission dialogs and your camera feature silently stops working.

I learned these lessons the hard way testing Orocube's POS products across Android and iOS devices. After enough production incidents caused by things I should have caught, I built a checklist that I run before every mobile release. This is that checklist.

Functional Testing

This is the foundation. The app does what it is supposed to do.

I test every item on this list manually at least once per release. Automation covers the regression, but the first pass is always hands-on.

Installation and Updates

This is the category most testers skip. Do not skip it.

The version skip test is critical. Not every user updates immediately. If your migration script only handles v1.1 to v1.2 but a user is still on v1.0, you need to know what happens.

Interruption Testing

This is where mobile testing gets interesting. Users do not use your app in a vacuum. Their phone is doing twenty things at once.

I test interruptions by literally calling my test device from another phone while performing critical flows. It sounds basic, but this is responsible for some of the worst bugs I have ever found.

Network Conditions

Mobile apps must handle bad networks gracefully. This is non-negotiable.

How I simulate network conditions:

On Android, use the Network Link Conditioner in developer options or set up a proxy with Charles/Proxyman that throttles bandwidth. On iOS, go to Settings, then Developer, then Network Link Conditioner. You can simulate 3G, Edge, or a 100% packet loss scenario.

Test scenario: User submits an order on 3G
 
Steps:
1. Enable 3G simulation on device
2. Add items to cart
3. Proceed to checkout
4. Submit order
5. Observe: Does the app show a loading state?
6. Observe: Does it timeout gracefully?
7. Observe: Is the order created or safely rolled back?

Performance Testing

Users uninstall apps that feel slow. Performance is not a nice-to-have.

How I check for memory leaks:

On Android, open Android Studio's Profiler. Navigate through the app for 10 minutes, visiting every screen multiple times. The memory graph should stay roughly flat. If it keeps climbing, there is a leak. On iOS, use Xcode Instruments with the Leaks template. Same process. Navigate, observe, look for the upward trend.

Device and OS Compatibility

The matrix of devices and OS versions is the most time-consuming part of mobile testing. Be strategic about it.

You cannot test every device. Pick a matrix that covers the extremes: smallest screen, largest screen, oldest supported OS, newest OS. If it works on the extremes, it usually works in between.

Security Checklist

Mobile security is different from web security. The device itself is a threat surface.

I do not do full penetration testing myself. But I check these basics on every release. If the app stores a JWT in plain text in SharedPreferences, that is a bug I can and should catch.

Accessibility

Accessibility is not a separate testing phase. It is part of every checklist item above.

My Pre-Release Workflow

Here is how I actually run through this checklist on a real release:

Day 1: Smoke test on primary devices. Install the build on one iOS and one Android device. Run through every core flow. If anything fundamental is broken, send it back immediately. Day 2: Full functional testing. Work through the functional and authentication checklists methodically. File bugs as I go. Day 3: Edge cases and interruptions. This is where I find the bugs that would embarrass us in production. Network conditions, interruptions, device rotation, memory pressure. Day 4: Device matrix and OS versions. Test on the expanded device set. Focus on layout issues, font rendering, and OS-specific behaviors. Day 5: Regression and sign-off. Verify all bug fixes. Run the automated suite. Final exploratory pass. Either sign off or block with clear reasons.

Five days is the ideal. Some releases get compressed to three. When that happens, I prioritize: Day 1 stays the same, Day 2 covers functional plus the highest-risk edge cases, Day 3 is device matrix plus sign-off. The interruption and network testing gets reduced but never eliminated.

The Checklist Is a Starting Point

Every project has its own quirks. A POS app needs payment terminal testing. A social media app needs media upload testing across file types and sizes. A banking app needs transaction integrity testing under every failure mode. Start with this checklist and add to it based on what your app actually does. After three releases, you will have a checklist that catches the specific bugs your app tends to produce. That is when mobile testing stops feeling like guesswork and starts feeling like a system.