There are three different identities in a typical test: the Google account joining the track, the account used inside your app and the developer account managing Play Console. They should not be treated as interchangeable.

Pick an app-account strategy

If people can register independently, provide a short path from the welcome screen to the first meaningful action. Explain email verification and which free features are available. If you supply demo accounts, give each person a separate account when shared data or concurrent sessions could interfere.

Use synthetic records instead of customer information. Grant only the app permissions needed for the agreed test. Testers do not need your personal Google password, payment credentials or administrator keys.

Prepare review access separately

Google reviewers may need access instructions for restricted functionality. Follow the current App access or sign-in details requirements in Play Console; sending credentials to your testing team does not update that declaration.

Run a clean-device rehearsal

Try a new installation, registration, sign-in, sign-out and password recovery. Check what happens when verification mail is delayed or a session expires. Include a clear route for reporting a blocked account.

Document whether premium areas are in scope and how authorized access is provided. Do not ask testers to make an unapproved purchase. After testing, revoke temporary access and remove synthetic data according to your retention process, without deleting evidence needed to understand reported bugs.