Google Play Internal Testing
Internal Testing e il canale più rapido di Google Play per distribuire build Android a un piccolo gruppo di tester (fino a 100 per app). E perfetto per QA interno, demo a stakeholder, validazione di release prima del rollout. Si affianca a Closed e Open Testing per scenari più ampi.
Differenze tra le tracce
Internal Testing: pubblicazione quasi istantanea, max 100 tester, niente review.
Closed Testing: gruppi privati estensibili, richiede review iniziale.
Open Testing: beta aperta a chiunque trovi il link, review più accurata.
Production: rilascio agli utenti finali, review completa.
Setup degli account tester
Gli account vanno aggiunti tramite indirizzo email Google nella console. Possono essere creati gruppi di tester riutilizzabili tra app diverse. Ogni tester deve accettare il programma cliccando sul link di partecipazione fornito dalla console.
Tracce e strategie di rilascio
Internal Testing e ideale per QA quotidiano. Closed Testing per gruppi di clienti selezionati con NDA. Open Testing per beta pubbliche. Production con rollout graduale (1%, 5%, 10%, 50%, 100%). Una strategia robusta combina tutte le tracce per ridurre rischi.
Pre-Launch Report
Anche su Internal Testing puoi attivare il Pre-Launch Report: dispositivi reali girano test automatici e segnalano crash, performance, problemi di accessibilità. E gratuito e fondamentale per qualsiasi release. Configura account demo nei test settings di Play Console.
Promozione tra tracce
"Promote release" permette di passare un'AAB validato da Internal a Closed/Open/Production senza nuova build. Riduce errori e velocizza il ciclo. Mantieni sempre un changelog ben curato (note di rilascio) perché viene mostrato agli utenti in Play Store.
Tester management
Crea gruppi Google riutilizzabili (es. "qa-team", "early-adopters") da Play Console. Modifica composizione senza dover ripubblicare. Per gruppi grandi (>50 tester) usa Google Groups esterni linkati alla console per delegare l'amministrazione.
Versioning e gestione build
Mantieni un schema di versioning chiaro: 1.0.0 production, 1.1.0-beta.1 internal testing, 1.0.1 hotfix. Sincronizza versionName e versionCode tra i track. Strumenti come gradle-versioning-plugin automatizzano il bump per ogni release, riducendo errori manuali frequenti.
Strategie di test
Internal Testing per smoke test (1 ora dopo release), Closed Testing per regression test (2-3 giorni), Open Testing per acceptance test (1 settimana), Production con staged rollout (1-5-10-50-100%). Ogni step ha criteri di esit definiti: crash-free rate >99.5%, ANR <0.5%, no critical regression dai test automatici.
Procedura passo-passo
- Apri Play Console, sezione Testing > Internal testing.
- Crea una nuova release e carica il bundle AAB.
- Compila note di rilascio (saranno visibili ai tester).
- Aggiungi tester individuali o tramite gruppo email.
- Pubblica la release: in pochi minuti diventa scaricabile.
- Condividi il link di partecipazione con il team.
- Raccogli feedback tramite Play Console o tool esterni (Firebase, Sentry).
Test track promotion
"Promote release" da Play Console permette di passare un'AAB validato da Internal a Closed/Open/Production senza nuova build. Riduce errori e accelera il ciclo. Mantieni un changelog ben curato perché viene mostrato agli utenti in Play Store. Configura automation in CI per pubblicare automaticamente la promotion dopo passing dei test.
Multiple flavor management
Per gestire dev, staging, production usa product flavors Android. Ogni flavor ha applicationId distinto (es. com.app.dev, com.app.staging, com.app.prod). Configura Play Console con app separate per ogni flavor. Pipeline CI/CD pubblica su track diversi a seconda del branch (develop -> dev internal, main -> production rollout).
Crashlytics integration
Internal Testing rileva crash che non emergono in debug. Configura Crashlytics e velocity alert per nuove release. Imposta soglia di acceptance: nessun crash in nuove versioni che colpisca >0.5% degli utenti. Block release fino a fix verificato. Rigorous discipline aumenta drasticamente la qualità generale.
Errori comuni e come risolverli
- Tester non vede l'app: deve accettare il programma tramite il link.
- Versione non aggiornata: verifica che il versionCode sia incrementato.
- App firmata male: usa Play App Signing per evitare problemi di chiavi.
- Crash non riportati: integra Crashlytics o ANR Detector.
- Confusione tra track: assegna correttamente la build alla traccia desiderata.
Domande frequenti
D: I tester pagano l'app o gli IAP?
R: No, gli IAP sono in modalita testing, le transazioni non vengono addebitate.
D: Posso passare un build da Internal a Production?
R: Si, tramite promote release, evitando di ricaricare il bundle.
D: Quanto sono lunghe le review delle Internal release?
R: Tipicamente meno di 1 ora, spesso istantanee.
D: I tester possono lasciare recensioni in Play Store?
R: No, le recensioni sono visibili solo in test program e non influenzano il rating pubblico.
Best practice operativa
Pubblica su Internal Testing dopo ogni merge in develop. Esegui smoke test automatici. Promote a Closed Testing a fine sprint. Promote a Production solo dopo crash-free rate verificato e business validation. Pipeline gradual reduce drasticamente il rischio di rilasci problematici.
L'integrazione di Internal Testing con strumenti DevOps moderni (GitHub Actions, GitLab CI, Bitrise) permette di automatizzare completamente la pipeline: ogni merge su develop genera automaticamente una build di Internal Testing, esegue smoke test automatici e notifica il team via Slack. Strumenti come Fastlane supply automatizzano upload e versioning.
Hai bisogno di aiuto?
Se vuoi sviluppare la tua app con G Tech Group, scrivici tramite il modulo di contatto.