Skip to content

12Testers for 14 Days · free working tool

Turn a closed test into a handover the developer can use.

Keep responsibilities, participation checks, observations, and release decisions in one working record. Mark the work you have completed, add a source or next action, and take a readable handover away with you.

Updated · 16 handover checks · local notes and export

Use a handover record alongside Play Console.

A closed test has two parallel records. Play Console shows whether the account meets its testing requirement. Your working record explains which release people used, what they tried, what failed, and who responded. This tracker helps with the second record; it cannot inspect your account or certify participation.

Start with the exact build and a rehearsal of the tester journey. Continue with the participation window and concrete observations. Finish by giving the developer a packet of references and unresolved decisions. You can use this structure with your own tester group or when coordinating a run through 12Testers for 14 Days.

Example: a tester can install, but cannot sign in.

An install confirmation is useful, but it does not explain whether the app’s main task was tested. Record the blocked journey, ask the developer to check access, and reference the replacement build or configuration change. Add a retest result only after someone repeats the journey. If it remains blocked, keep the issue open in the handover.

Your testing handover record

0 of 16 checks marked complete · 0 evidence references recorded

Loading your local tracker…

Testing handover checks and evidence
01

Before invitations

Agree on the testing handover

Make the developer and the testing coordinator work from the same release record. A paid package or a tester list is not a substitute for working access.

Record the package name, version code, closed-track name, and person who can publish a replacement build. Keep a reference to the release record rather than guessing from a screenshot.

Use an eligible tester account to open the opt-in page, install the closed release, sign in, and finish the main task. Note any country, device, or account restriction that prevented access.

Give testers a goal, a short path through the app, expected results, and a place to report failures. Keep passwords and private tester details out of this public-browser tracker.

Name the role responsible for missing access, a blocked login, an unavailable tester, and a release-blocking defect. Agree how that role will be contacted and how a resolution is recorded.

02

Participation record

Record the qualifying window

Use Play Console to establish eligibility. Use your own run record to explain what happened during testing; the two records answer different questions.

For personal accounts created after 13 November 2023, Google's current guidance requires at least 12 testers opted in continuously for the preceding 14 days before applying. Check the account's current Play Console guidance.

Record when the qualifying group was established and where the count was checked. An upload date alone does not establish a continuous opt-in window.

If someone leaves or cannot use the release, record the date and action taken. Do not assume a replacement tester inherits the previous tester's qualifying time.

Reconcile your participation notes with the status shown in Play Console. Leave the application date unconfirmed when the underlying count or continuity is uncertain.

03

Evidence trail

Connect observations to released fixes

A useful closeout explains an actual app journey, what testers observed, and how the developer responded. More checkmarks do not make missing evidence real.

Name a task such as creating a project or completing a booking, the build used, and the outcome. Include failed attempts and relevant device context, not just app-open counts.

Link an observation to reproduction steps, an expected result, an actual result, and an owner. Remove personal data before sharing reports outside the team.

Reference the issue, the changed build, and the repeated task. A developer saying 'fixed' and a tester confirming the result are separate pieces of information.

List unavailable devices, unexercised features, or scenarios that remain uncertain. Give each gap a next action instead of describing all features as fully tested.

04

Closeout review

Hand the decision back to the developer

The service can help coordinate a run. The account owner remains responsible for the application, policy declarations, and decision to release.

Collect the participation summary, task coverage, issue references, changed builds, retests, and open risks. Make sure someone receiving the packet can find each source.

Record whether a remaining problem blocks release, who owns it, and when it will be reviewed. Do not mark an issue resolved merely because the testing package has ended.

Use the evidence brief builder to prepare notes in your own words. Verify claims about engagement and fixes against the actual run before using them in Play Console.

Confirm the current Play Console status, app setup, and policy declarations. Completing this tracker neither submits an application nor guarantees Google's production-access decision.

These ticks are your record of completed work. They do not verify tester eligibility, send an application, or predict Google’s decision. Avoid storing passwords, access tokens, or tester email addresses here.

Separate completion, evidence, and the release decision.

  • A completed check means you believe an action is done. It does not mean this tool verified that action.
  • An evidence reference lets the next person locate the record or see what is still missing. Prefer a dated note or issue reference over a vague statement such as “all done.”
  • A release decision belongs to the developer. Include open issues and gaps so that decision can be made with the limitations visible.

For applicable personal accounts created after 13 November 2023, Google’s current guidance calls for at least 12 testers opted in continuously for the preceding 14 days before applying for production access. Check the current official Play Console requirements for the account. Completing a service package or this tracker does not guarantee approval.

Use the record for the next conversation.

Share an appropriate, anonymized handover with the person making the release decision. The production access evidence brief turns those references into review notes. The sample closeout report illustrates how findings and next actions can be organized. If you need help with tester coordination, compare the current testing packages and confirm the scope for your app.

Using the testing handover tracker

What should I put in an evidence reference?

Use a record you can find again: a release version, a dated participation check, an issue reference, or a retest note. If the evidence does not exist yet, record the next action instead. Do not add tester email addresses, passwords, or account tokens.

Does finishing the tracker mean my app qualifies?

No. The tracker records your own work and references. Play Console establishes the account’s eligibility, and Google reviews the application. A complete handover can still contain an unresolved release risk.

Can a coordinator complete this for a developer?

A coordinator can assemble the testing record and identify gaps. The developer should verify the qualifying window, policy declarations, unresolved issues, and final application wording from the owning account.

Where are my notes saved?

This tool saves the tracker locally in this browser when storage is available. It does not upload your entries. Download a handover copy before switching browsers, using a shared device, or clearing browser data.