Mobile App QA Testing Checklist Before Launch

The pre-launch test table

Test the business flow first

Start with the action that makes the product valuable. For ecommerce, it is browsing, cart, checkout and order status. For a booking app, it is service choice, available time, confirmation, reminder and reschedule. For an online school, it is lesson access, progress, payment and content playback.

Do not start with button colors. Start with the path that would create a refund, support ticket, store rejection or lost customer if it failed.

Devices, networks and permissions

A mobile app can behave differently across devices. Android back navigation, screen cutouts, keyboard behavior, permission dialogs, low-memory states, push handling and background behavior can vary. iOS has its own release, permission and layout patterns.

For an MVP, choose a practical device set: one recent iPhone, one older supported iPhone, one mid-range Android, one older Android and any special device your audience uses. Automated services help, but manual checks reveal hesitation, confusing copy and small interaction problems.

Store testing tracks and timing

Apple TestFlight lets teams invite internal and external testers before publishing. It should be a calendar item, not a last evening task. Google Play supports internal, closed and open testing tracks.

Some new Google Play personal developer accounts must run a closed test with at least 12 opted-in testers for at least 14 consecutive days before production access. If this applies to the account, it changes the launch schedule.

Analytics and crash reporting

Before launch, check that important events fire correctly: sign_up, purchase, booking_created, payment_failed, subscription_started, onboarding_completed and consultation_click when relevant. Use the event plan from mobile app analytics setup.

Crash reporting is also launch quality. The team should know if a crash happens on a specific device, app version or screen. Do not collect sensitive data in logs; combine this with the security checklist.

How testing changes cost

Testing effort grows with roles, payment states, integrations, supported devices, languages, offline behavior and store requirements. For broader planning, read mobile app maintenance cost, app redesign and modernization and mobile app backend development.

Build a risk-based test plan

Not every bug has the same cost. Mark a scenario P0 when failure blocks revenue, access, safety or data integrity: a customer cannot sign in, a payment is duplicated, a booking disappears or one user sees another user's information. P1 problems allow the task to continue but create serious confusion or manual work. P2 covers visual or low-frequency defects that can wait for a planned update.

For each P0 flow, test one successful path and at least three failures. Checkout needs an accepted payment, a declined card, a delayed confirmation and a repeated tap. Booking needs the last available slot, two simultaneous attempts, rescheduling and cancellation. This is more useful than a long checklist with no priority because it tells the team what must block release.

Prepare roles, accounts and test data

Create separate accounts for a new user, returning user, administrator, support employee and every provider role. Prepare empty, normal and extreme data: no orders, one order, a long history, expired subscription, refunded payment, suspended seller and deleted content. Test what each role may view and change. Permission failures often stay invisible when everyone uses one administrator account.

Test data must be recognizable and disposable. Do not use real customer records or personal payment details in screenshots, logs and bug reports. A useful defect report includes app version, device, operating system, account role, steps, expected result, actual result and a screenshot or short recording. That evidence reduces the time spent trying to reproduce the problem.

Define the release decision

Before the final build, agree on release criteria: no open P0 defects, named owners for accepted P1 defects, successful smoke tests on the target device set, verified analytics and crash reporting, valid store links and working support contacts. Also confirm that the production environment, payment credentials, push certificates and privacy declarations match the build being submitted.

Run a short regression after every last-minute fix. A change to login may affect account deletion; a payment fix may affect refunds; a new permission request may change onboarding. Record the tested build number so approval does not accidentally refer to an older package.

After release, watch crashes, payment failures, onboarding completion, support messages and store reviews daily during the first week. The QA-before-launch guide explains this release room in more detail, and the accessibility checklist covers text scaling, screen readers and touch targets.

How Appfyl uses this

Appfyl ties testing to product risk. We identify the core business flow, the roles that touch it, the data that must be protected, the analytics events that prove it works and the devices that matter for the audience.

For booking and delivery products, we test schedule changes, push notifications, failed payments and support actions. For fintech and healthcare products, we test permissions, private data, account recovery and logs. For education products, we test content access, playback, progress and subscription states.

Want to see how Appfyl turns scope into shipped products? View Appfyl cases.

Related Appfyl guides

Use these pages to move from a broad estimate to a clearer scope before talking to a development team.

• Mobile app QA before launch
• Mobile app launch checklist
• Mobile app analytics setup

Want to see how Appfyl turns scope into shipped products? View Appfyl cases.

Next step

Before launch, write your top five "must not fail" scenarios. Then add them to the Appfyl feature brief quiz or your project brief.

Questions people ask