Recording a Launch Failure Separately from Crash and ANR

How to record a Google Play closed-test observation so that a failed install, an app that never started, and an observed Crash or ANR do not end up as the same note.

Write down the conditions you started from

The first line of a record should carry the app version you checked, the time you started, and the flow you meant to observe. Trying to cover every screen in one pass blurs the point at which the problem appeared.

If you only intended to check the first screen after install, record that scope and nothing wider. Not widening a record to say that features you never opened were fine is what lets you rebuild the same conditions on the next test.

Keep install and launch as separate steps

Whether the app could be installed and whether the installed app started are not the same result. After the install finishes, record separately what appeared when the icon was tapped.

Do not write that the launch was confirmed simply because the install screen was cleared. The reverse also holds: seeing the first screen does not mean the flows after it were checked. Splitting the steps narrows where to look next on its own.

Separate a launch failure from an observed Crash or ANR

An app that did not run is not automatically a Crash or an ANR. Distinguish whether it stopped at the launch step, whether an abnormal termination was observed after a particular screen opened, or whether the app was seen to stop responding.

Record the screen you saw and the step it happened at as fact, and keep the cause as a separate item to check. This split is not there to dress up the name of a result; it is what makes the same symptom comparable on the next test. The three outcome values LuneTest records, and which runs its Crash and ANR counts come from, are described in how to read the daily execution record.

Identify test accounts without personal data

Refer to a test account only by a short internal identifier. Do not record its password, verification codes, or personal information.

Confirm separately that the account registered on the Play Console list is the one used for this check. If the accounts do not match, the same link and the same app version can produce a different screen. The registration step those accounts go through is in add tester emails to your closed track.

Record what the physical device observation covers

If you checked on a physical Android device, note the device identifier, the app version, and the step observed. Do not generalise a result from one device into a result across a wide device range.

Even on the same app version, results are not directly comparable when the screen and conditions checked were different. Use an observation only within the scope you tested, and leave anything that needs more checking marked as open.

End with a single next question

Close the record by reducing what to check next to one item. If the install succeeded but the first screen never appeared, the next check is an observation of the launch step.

Changing several settings at once makes it hard to tell which one mattered. Holding the same test account and the same app version while checking one item at a time is what keeps the new record comparable to the last one. Where a new version is involved, publishing an update during a closed test explains when that version is actually observed.

Keep Google's decision separate from your own record

A test record is material for examining the state of your app. It does not decide test recognition or production access on Google's behalf. Google makes that decision independently, and LuneTest does not guarantee it.

Preparation items and record examples for a Google Play closed test are collected in the LuneTest English guides, and the requirement those preparations are measured against is in the 12 testers for 14 days checklist. Keeping facts and observation scope separate is what makes a launch failure and an observed Crash or ANR comparable on the next test.