Mobile App Testing: A Checklist Before You Launch

Testing is how you find out what real users will meet before they do. This guide gives a practical checklist, explains the role of real devices and beta testers, and says how to decide when the app is ready.

Mobile app testing before launch means checking that the main journey works on real devices, that the app copes with poor signal, interruptions and unexpected input, and that it meets each store's review rules. Test on a spread of phones and operating system versions, use testers from outside the team, and fix whatever blocks the main task before anything cosmetic.

What mobile app testing covers

Mobile app testing is a set of checks, not a single step. Each one answers a different question and is usually done by a different person. The developer tests the code. You test whether the app does what the business needs. People outside the project show what a new user finds confusing. The table lists the main kinds.

Kind of test	Question it answers	Who usually does it
Functional	Does each feature do what the brief says?	Developer, then you
Usability	Can a new user finish the main task without help?	People outside the project
Compatibility	Does it work on different phones, screen sizes and operating system versions?	Developer or tester, on real devices
Connectivity and interruptions	What happens with no signal, a phone call or the app sent to the background?	Developer and you
Performance	Is it quick to open, smooth to use and gentle on the battery?	Developer, with your judgement on feel
Accessibility	Can people with large text, a screen reader or limited vision use it?	Developer, and testers who use these tools
Security and privacy	Is user data handled and declared correctly?	Developer, with you checking the declarations
Store readiness	Will the listing and build pass review?	You and the developer together

Ask whoever is building the app which of these are included and which you must do yourself. Your app brief is a good source for the test list. Each feature in it should say what "working" means, and that statement becomes a test.

Test the main journey first

Write down the one task the app exists for. Then walk through it as a brand new user on a clean install: open the app, create an account, complete the task, see the result, close the app, open it again and sign back in. Do it with valid data and with careless data, such as an empty field, a very long name or a wrong password.

If the main journey fails, nothing else matters yet. If it works, widen the circle. If the app takes payments, use the test mode that payment providers offer rather than real cards, and check the provider's documentation for how it works. If the app is the mobile side of a store, place test orders from end to end and compare them with what you would see on the website. The comparison of an ecommerce website and a mobile app explains why both need to agree on products, prices and orders.

A checklist of what to test

Install, first launch and accounts

A clean install opens without errors, and the first screen makes sense with no explanation.
Sign-up, sign-in, password reset and sign-out work. Emails and codes arrive.
If users can create an account, they can delete it from inside the app. Apple's guidelines require this, so check Google's current policy as well.
An update installed over an older version keeps the user's data and settings.
Deleting and reinstalling the app behaves sensibly.

Core features and forms

Every feature on the must-have list works from start to finish.
Forms show errors in plain words next to the field that caused them.
The keyboard type suits the field, the screen does not hide the field being typed in, and autofill works.
Names, addresses and text in other scripts display correctly. If you serve readers of Arabic or Japanese, test right-to-left text and Japanese input.
Dates, times, currencies and number formats suit the user's country, and time zones do not move bookings by a day.

Permissions, notifications and the phone itself

Deny each permission, such as camera, location or notifications, and check that the app explains what is missing and still works where it can.
Notifications arrive when the app is closed, and tapping one opens the right screen.
Rotation, split screen and different text sizes do not break layouts.
A call, a message, a low-battery warning or a locked screen does not lose the user's work.

Connection and failure

Switch on airplane mode in the middle of a task. The app should say what happened and recover when the connection returns.
Test a slow connection and a switch from Wi-Fi to mobile data.
Test what the user sees when the server is down or returns an error.
Check that a payment or booking cannot be submitted twice by tapping twice.

Accessibility and privacy

Text enlarges, contrast is readable, buttons are easy to hit and images that carry meaning have labels for screen readers. Android's quality guidelines list specific checks, and its Accessibility Scanner can help.
The app asks only for the data it needs, and the privacy policy and store declarations match what it collects.
Sessions end sensibly, and sensitive screens do not leave data in notifications or screenshots of the app switcher.

Do you need real devices?

Yes, for the final checks. Simulators and emulators run on a computer. They are quick and useful for checking screen sizes and for day-to-day development. They do not reproduce real touch, battery drain, cameras, sensors, mobile networks, the phone's real performance or how notifications arrive. Android's own quality guidelines recommend emulated devices for the common form factors plus a small number of real hardware devices, and the same logic applies to iPhones.

You do not need every phone. Pick a small, deliberate set:

A current phone with a large screen.
A small or older phone with less memory, which shows slowness and cramped layouts.
The oldest operating system version you promise to support.
The newest version, including any beta that is about to be released, because operating system updates can break an app that worked yesterday.
A tablet, if the app will be installed on tablets.

Android phones vary far more than iPhones in make, screen and software, so spend more of your device effort there. Base the choice on who will use the app. If the app has a website, its analytics show which devices visitors use. Otherwise ask a sample of customers. Revisit the list at every major release.

Who should test the app

Use different people for different questions.

The developer or a test engineer checks the code and the odd cases.
You test with business knowledge. You know what a correct order, booking or report looks like.
The staff who will run the admin side test that side. An app often has a hidden second product: the screen where staff manage content, orders and users.
Outsiders, ideally people like your customers, show what a new user finds confusing. Give them a task, not instructions, and watch without helping.
Testers who use accessibility tools, large text or an older phone show problems the team will not meet.

Who tests depends partly on who builds the app. Ask in-house teams, agencies and freelancers what testing is included in the price; the comparison of in-house, agency and freelancer app development covers the questions to ask. If the app depends on a website or an admin site, those parts also go through the testing stage described in the website development process.

Give every tester the same way to report a problem, and collect the reports in one place. A useful report says what the tester did, what they expected, what happened, the phone model, the operating system version and the app version, and it includes a screenshot or a short screen recording.

Beta testing with TestFlight and Google Play tests

Both stores have their own routes for sending test builds to real people before the public release.

On iPhone, Apple's TestFlight lets you invite testers from your team and from outside it. Testers can send feedback and screenshots from the test app, and crash reports reach App Store Connect. The first build for outside testers goes through a beta review by Apple, so allow time.

On Android, Play Console offers internal, closed and open testing. Google recommends starting with an internal test and then widening to a small closed group. Google also generates a pre-launch report when you upload a build: it installs the app on test devices and runs an automatic check, reporting on stability, compatibility, performance and accessibility. You can supply a test account so the check can get past a sign-in screen. Google sets testing requirements for some newly created developer accounts before they can release to the public, so check the current documentation early in the project and not in the week of launch.

A beta is not a formality. Choose testers who match your users, tell them what to try, ask for feedback by a set date and give them a reason to continue, such as a thank-you. Treat the beta as a rehearsal of launch, including the sign-in process and, where relevant, payment.

Test for store review

Each store reviews the app before it appears. Apple's guidelines say that submissions should be final versions with complete information and working links, with placeholder content removed, and they ask you to test for crashes and bugs before you submit. If the app needs a sign-in, Apple expects you to give App Review a working demo account or a built-in demo mode that shows the full features. Keep those credentials current, and keep the back end running while the review takes place.

Before you submit to either store, check the points listed here.

Every link in the listing and in the app opens, including the privacy policy.
Screenshots come from the final build.
The app does not crash on a clean install, on first launch or on the main journey.
Features behind a sign-in can be reached by reviewers.
Store declarations, such as data collected and content ratings, are complete and accurate.

Create the developer accounts for both stores in your business's name, so that the release does not depend on a contractor.

Log, rank and retest bugs

Not every bug is worth stopping a launch for. Rank them by effect, using a plain scale:

Blocks the main task, loses data or takes payment wrongly. Fix before release.
Gives a wrong result or breaks a secondary feature. Fix before release, or agree a workaround.
Looks untidy or is awkward but does not stop anyone. Schedule for a later release.

Agree the release rule before testing begins, so that decisions are not made under pressure. For example: no open bug in the first group, no crash on a supported device, and every must-have feature signed off. After each fix, retest the bug and the nearby features, because a repair can break something that worked. Test the fix on the same device where the bug appeared.

When the app is ready, and what happens after

An app is ready when the main journey works reliably for people other than its builders, the release rule is met and the store checks are done. It is never free of bugs, and waiting for a perfect build is a mistake. The first version should be small enough to test properly, which is the reasoning behind building a minimum first version. A smaller scope is the best route to a thorough test.

Consider releasing to a limited audience first. Both stores offer ways to release gradually or to a test group, so check the current documentation. Watch crash reports and reviews closely in the first weeks. Testing does not stop at launch: every new release and every new operating system version needs another pass, so budget for it in the maintenance plan.

If you want a team to build and test an app with you, the mobile app development page describes the apps Liftup builds.

Questions and answers

What should I test before launching an app?

Start with the main journey on a clean install, then check sign-in, forms, permissions, notifications, poor connections, interruptions, accessibility and the store's review requirements. Test on a spread of real phones and operating system versions. Fix anything that blocks the main task before cosmetic problems.

Do I need real devices?

Yes, for the final checks. Simulators and emulators are useful for quick checks and screen sizes, but they do not reproduce real touch, battery, cameras, networks or notification delivery. Choose a small set that covers your users' main phones and operating system versions.

Who should test the app?

Use several groups. The developer tests the code, you test that the app does what the business needs, staff test the admin side, and outsiders who resemble your customers show what is confusing. Include testers who use accessibility tools or older phones.

What is a beta test?

A beta test is a trial of a nearly finished build with a limited group of real users before the public release. Apple's TestFlight and Google Play's internal, closed and open tests are the stores' own routes for it. Tell testers what to try and collect their reports in one place.

Which bugs should stop a launch?

Any bug that blocks the main task, loses user data, takes a payment wrongly or crashes the app on a supported device. Agree this rule before testing starts. Untidy layouts and small annoyances can wait for a later release.

How long does app testing take?

It depends on the number of features, devices, platforms and rounds of fixes, so no honest figure fits every app. Plan time for testing, for fixing what you find, for retesting and for store review. Ask your developer how many test rounds the schedule includes.

Do I need to test again after launch?

Yes. Each new release, and each new version of iOS or Android, can change how the app behaves. Keep a short list of core checks that you run before every release, and watch crash reports and reviews after each update.