Testing Your First-Run Experience Before a Google Play Closed Test Starts

Every tester sees your first-run experience exactly once. After the first session, they have an installed app with data in it, permissions decided and onboarding dismissed. If something breaks or confuses them in those first minutes, you can't re-create that moment with the same person. So test the first run yourself, thoroughly, before you share the opt-in link.

This post is a practical checklist for that first session: what to test on a clean install, what to ask testers about it, and what to fix before day one of the 14-day closed test.

Why the first run deserves its own test pass

Most developers test with a build that has been installed for weeks. Their debug data is there, they are logged in, and they know where every button is. A new tester has none of that. The first run is where several kinds of bugs hide:

• Code paths that only run when no local data exists (empty databases, missing preferences).
• Onboarding screens that were written early and never revisited.
• Network calls that assume an account or a cached config already exists.
• Permission prompts that appear at confusing moments.

The rest of your closed test, days 2 to 14, covers the returning-user experience. The first run only gets one shot per tester, so it needs preparation.

Step 1: Reproduce a true clean install

Running from Android Studio over an existing install does not give you a clean first run. Use one of these instead:

1. Uninstall the app completely, then install the release build you plan to upload (an AAB-derived build or a locally generated APK set, not the debug variant).
2. Run adb uninstall your.package.name and then install again.
3. For a quick reset on a test device, use adb shell pm clear your.package.name. This wipes app data but it is not identical to a fresh install on every device, so do a full uninstall at least once.

Also check for leftover state outside the app: Android Auto Backup can restore data after a reinstall on some setups. If your app suddenly skips onboarding after a reinstall, that may be why. Decide whether that is what you want, because it will also affect testers who have previously installed a similar build.

Step 2: Walk through the first five minutes with a stopwatch

Open the app cold and note the time at each of these points:

• Icon tap to first visible screen.
• First screen to the first moment the app does something useful.
• Number of taps before a user could say what the app is for.

You do not need exact numbers, just a feel for where it drags. If the first useful action sits behind a long sign-up, several permission prompts and a four-page tutorial, expect testers to mention it. Android's documentation on launch time explains how the system measures cold starts: see App startup time on developer.android.com.

Questions to ask yourself

• Can onboarding be skipped, and does skipping leave the app in a usable state?
• Does every onboarding screen still match the current UI?
• Is anything asked for before the user understands why (account, location, notifications)?
• If the user taps back on the first screen, what happens?

Permission details like grant, deny and revoke flows deserve their own pass, which is covered in the post on runtime permissions. Here, just check the timing: does the prompt appear in context, or on launch before anything makes sense?

Step 3: Break the first run on purpose

Real testers will not follow your happy path. Try these interruptions during onboarding:

1. Rotate the screen halfway through. Does progress or typed input disappear?
2. Switch to another app and come back. Android may kill your process in the background. Does the app restart from onboarding, resume correctly, or crash?
3. Turn on airplane mode before first launch. Does the app explain what is wrong, or sit on a spinner? (The offline post goes deeper on this.)
4. Change the system font size or language before first launch and check that onboarding text is not clipped.
5. Kill the app from recents after finishing onboarding and relaunch. Does it skip onboarding as expected, or show it again?

That last one is a classic. A flag saved too late, or saved only in memory, means testers see onboarding every time they open the app, and they will tell you so.

Step 4: Check the empty states

A new user has no data, so every list, feed and dashboard is empty. Look at each one:

• Is there a message explaining what will appear and how to add the first item?
• Is there a blank white screen where a loading or empty indicator should be?
• Do charts, counters or averages handle zero items without crashing or showing odd values such as NaN?

Empty-state bugs are some of the easiest crashes to ship, precisely because developers rarely see them again after their first week of development.

Step 5: Tell testers what to look at on day one

Testers give better feedback when they know what you want. Write a short note with the opt-in instructions, something like:

On your first launch, please note anything that confused you, anything you didn't understand, and anything that felt slow. Tell us what you expected the app to do and whether it did it.

Ask for specifics: device model, Android version, and the screen where they got stuck. Written feedback with those details is much easier to act on than a general impression. If you're unsure how to ask for it, the guide on collecting useful feedback from closed testers covers question design in more depth.

Where TesterMob fits

With TesterMob, testers install your app on their own Android phones, use it for about 20 minutes a day and write feedback. That means your first-run experience gets tried on a range of real devices rather than only on your own. It is still up to you to read the day-one feedback and decide what is a real problem. TesterMob is not affiliated with Google and cannot guarantee production approval, but clean first-run feedback is something you can act on straight away. Pricing is a one-time $9.99 per app, paid in USDT, and the details are on the pricing page.

Step 6: Fix first-run issues with the second build

Don't rush to push a new build after the first complaint. Collect the first day or two of feedback, group it, and look for repeats. Several testers stuck on the same screen is a clear signal. One person with an unusual device may not be.

Prioritize in this order:

1. Crashes or dead ends during onboarding.
2. Screens where testers could not tell what to do next.
3. Slow or confusing steps that are not blocking.
4. Visual polish.

Remember that testers who already completed onboarding will not see your fixed first run. For those, confirm the fix yourself on a clean install, and consider whether the new build changes anything for people who installed the old one. The upgrade path post covers that side.

A quick pre-upload checklist

• Release-signed build tested on a fully uninstalled device.
• Onboarding can be completed, skipped and interrupted without crashing.
• Process death and rotation tested mid-flow.
• Every empty screen shows something sensible.
• Permission prompts appear with context.
• Test instructions for testers mention what to note on the first launch.

Closed testing requirements and Play Console screens can change over time, so check the current rules in Play Console Help before you start. If you have questions about how TesterMob works in practice, the FAQ is a good place to begin.

An hour spent on a clean-install pass now is cheaper than discovering, on day three, that every new tester has been stuck on the same welcome screen.