How to Read the Daily Execution Record

What the account, time, installed version, outcome, and saved screens in each LuneTest run row mean, and how to use them when you describe your testing honestly.

What one run row holds

A single row in the execution record holds which account ran, when it ran, which version was installed at the time, what the outcome was, and how many screens were saved.

Execution record table. Test account, device number, installed version, start time, duration, outcome, and number of saved screens each appear as a column.

The screen above shows the example data on the demo page. In your own workspace the same table is filled in with your app and its accounts.

Selecting a run shows the total elapsed time, the time to app start, the number of crashes and ANRs observed, and the screens saved on that run.

The account is the identity of a run

What distinguishes one run from another is the Google account that performed it, not the device. The workspace shows only the account's Gmail local part, never the full address. Select an account to see only that account's runs.

Which hardware a run happened on is not shown in the customer view. How these accounts come to be registered on the closed track's tester list is described in add tester emails to your closed track.

Times are always Korean time

Every operational time is shown in Korean time, in year-month-day hour:minute:second form. It does not follow your browser's time zone, so the same value appears wherever you open it.

That means you never have to convert time zones when comparing the times on two records.

What the three outcomes mean

Completed means the run went through to the end. Failed means the run did not finish normally, and invalid means the run cannot be counted. One failed or invalid result does not immediately mean there is a problem with the app; it is more accurate to read it alongside the next run to see whether the same state continues.

Crash and ANR counts are taken only from runs that went through to the end. When you carry these values into your own records, the basis for separating a run failure from an observed Crash or ANR is set out in recording a launch failure separately from Crash and ANR.

When version values differ

The version in the participating-accounts table is the version currently installed on that account; the version on a run row is the version installed at the time of that run. Right after you publish a new version, the two can differ. When a new version is picked up is explained in publishing an update during a closed test.

Reading the version history alongside the per-account update table shows which accounts have finished changing over. Where a value has not been confirmed yet, a checking marker or a dash is shown instead of a number. Nothing is filled into that space.

About the saved screens

The screens saved on each run are visible in the run detail, and you can open the original by selecting one.

The number of screens saved can differ from run to run, and a run that did not go through to the end may retain only diagnostic screens.

Using it in a production-access application

Google decides test recognition and production access independently. An execution record does not guarantee approval; it is material you draw on when describing honestly which features you checked, what problems you found, and how you fixed them.

Collecting the runs by date, the version changeovers, and the crashes observed makes that description considerably easier to write. The minimum tester count and continuous opt-in period the application is measured against are in the 12 testers for 14 days checklist.