Test chiuso Google Play: 12 tester, 14 giorni e un piano per ottenere l'accesso alla produzione (2026)

Se il tuo account sviluppatore Google Play è un account personale appena creato, il test chiuso di Google Play è un ostacolo da superare prima del lancio. Quando richiedi l'accesso alla produzione, almeno 12 tester devono essere iscritti al tuo test chiuso e ognuno deve esserlo stato senza interruzioni nei 14 giorni precedenti. Gestiscilo come un progetto di test di due settimane, con un responsabile, un calendario e un ciclo di feedback, non come una casella da spuntare all'ultimo giorno.

Cosa richiede il test chiuso di Google Play nel 2026?

A novembre 2026, gli account sviluppatore personali creati dopo il 13 novembre 2023 devono eseguire un test chiuso con "almeno 12 tester iscritti senza interruzioni da almeno 14 giorni" prima di poter richiedere l'accesso alla produzione. Fino ad allora, le opzioni Produzione e Pre-registrazione restano bloccate per l'app.

• 12 tester devono essere iscritti al test chiuso nel momento in cui invii la richiesta.
• Devono essere stati iscritti nei 14 giorni precedenti, senza interruzioni.
• Un tester che annulla l'iscrizione e si iscrive di nuovo deve completare altri 14 giorni consecutivi per essere conteggiato.
• Il test chiuso diventa disponibile una volta completata la configurazione dell'app. Il test aperto resta bloccato finché non ottieni l'accesso alla produzione.
• Il test interno non ha prerequisiti, ma è un canale separato.

Le regole si trovano nella pagina di Google Requisiti di test delle app per i nuovi account sviluppatore personali. Quella pagina riguarda solo gli account personali. Non dice nulla sugli account organizzazione, quindi controlla cosa mostra la tua Dashboard invece di dare per scontato l'uno o l'altro caso.

Come si configura un canale di test chiuso in Play Console?

Per configurare un test chiuso, apri Test and release > Testing > Closed testing in Play Console, fai clic su Manage track, aggiungi i tester nella scheda Testers e poi pubblica una release. Puoi aggiungere i tester tramite elenco email o Google Group. Ogni elenco contiene fino a 2.000 utenti, quindi la dimensione dell'elenco non è mai il limite. Il vero problema è convincere le persone a iscriversi.

1. Nella scheda Testers, crea un elenco email o inserisci un Google Group come yourgroupname@googlegroups.com.
2. Aggiungi un URL o un indirizzo email per il feedback. Google lo mostra nella pagina di iscrizione dei tester.
3. Copia il link di iscrizione condivisibile e salva le modifiche.
4. Crea una release nel canale chiuso e pubblicala.
5. Condividi il link di iscrizione insieme all'URL del Play Store quando la release è live. I tester non possono trovare un'app non ancora in produzione cercandola su Play.

La pagina di Google sulla configurazione dei test elenca diverse trappole. "Il link di iscrizione viene visualizzato solo quando lo stato dell'app è 'Published'", quindi le app in bozza (Draft) o in attesa di pubblicazione (Pending publication) non hanno un link. Caricare un CSV sovrascrive gli indirizzi già presenti nell'elenco, e i file CSV salvati come UTF-8 con BOM vengono rifiutati. Con un Google Group, le persone devono unirsi al gruppo prima di potersi iscrivere al test. Chi fa già parte del tuo test interno deve uscirne prima di poter ricevere il test chiuso.

Quanti tester reclutare e quali vengono conteggiati?

Recluta 15–16 tester, non 12, perché contano solo le persone iscritte tramite il link di iscrizione di Play e chi abbandona prima del quattordicesimo giorno non conta affatto. I 14 giorni di ogni tester partono dal momento della sua iscrizione, quindi chi si aggiunge tardi sposta in avanti la prima data utile per la richiesta.

Buone fonti sono la tua mailing list, la lista d'attesa della beta, gli amici con un telefono Android e altri sviluppatori indipendenti disposti a testare la tua app se tu testi la loro. Chiedi a ciascuno di confermare di aver accettato il link di iscrizione e di aver installato l'app da Play. Un APK installato manualmente o una build inoltrata non contano. Se la tua app è a pagamento, Google precisa che i tester devono acquistarla per partecipare: un motivo in più per offrire una build di test gratuita o un codice promozionale.

Cosa devono fare i tester durante i 14 giorni?

I tester devono usare l'app come farebbero gli utenti reali, con un compito specifico ogni pochi giorni, così da raccogliere feedback e rilasciare correzioni durante il periodo di test. Il modulo per la produzione chiede se i tester hanno usato tutte le funzionalità e se il loro utilizzo rispecchiava il comportamento reale, e ti servono risposte a entrambe le domande.

I tester non possono lasciare recensioni pubbliche sulle versioni di test. Raccogli il feedback tramite l'URL o l'email di feedback, oppure tramite il feedback privato in Google Play. Tieni un registro di ogni segnalazione, di cosa hai modificato e di quale build l'ha risolta. Se il test fa emergere crash o schermate non funzionanti, il piano di test della build di release per i rifiuti 2.1 è una checklist utile anche per le build Android.

Cosa succede quando gli sviluppatori ricevono "more testing required"?

Le testimonianze pubbliche mostrano che raggiungere il numero di tester ti permette di inviare la richiesta, ma non garantisce l'approvazione. A distinguere le approvazioni dai rifiuti sono il coinvolgimento visibile dei tester e gli aggiornamenti nati dal feedback.

• Rifiutato dopo un servizio di tester. Nella community di MIT App Inventor, uno sviluppatore ha riferito a luglio 2024 (quando la soglia era di 20 tester) di aver raggiunto il numero tramite un servizio di scambio di tester. Ha comunque ricevuto "More testing required to access Google Play production", con le motivazioni "Testers were not engaged with your app during your closed test" (i tester non hanno interagito con l'app durante il test chiuso) e "You didn't follow testing best practices, which may include gathering and acting on user feedback" (non sono state seguite le best practice di test, che possono includere la raccolta del feedback degli utenti e l'intervento su di esso). Google gli ha scritto: "Before applying again, test your app using closed testing for an additional 14 days with real testers" (prima di presentare una nuova richiesta, testa la tua app con un test chiuso per altri 14 giorni con tester reali). Ha anche detto di non essere riuscito a compilare il modulo post-test perché non sapeva chi fossero i suoi tester né come avessero testato. La pagina della discussione non riporta alcuna soluzione.
• Approvato dopo un test riorganizzato. Una sviluppatrice su DEV Community ha scoperto che la maggior parte di amici e familiari usava un iPhone. Solo 4–5 persone avevano installato l'app e circa la metà l'aveva rimossa nel giro di pochi giorni. È passata a un Google Group impostato su "Anyone can join" e ha reclutato altri sviluppatori tramite un'app di test reciproco, che il post promuove. Ha raggiunto 14 tester in due giorni, ha rilasciato 6 piccoli aggiornamenti durante il periodo di test e ha compilato il modulo con risposte accurate. Riferisce di aver ottenuto l'approvazione due giorni dopo la richiesta.

Morale: entrambi gli sviluppatori avevano raggiunto il numero di tester richiesto. Quella approvata poteva dimostrare utilizzo reale, aggiornamenti e feedback, mentre quello rifiutato aveva i numeri ma nessuna prova da descrivere nel modulo. Se hai già ricevuto quell'email, la guida a Google Play "More testing required" spiega cosa cambiare prima di ripresentare la richiesta.

Cosa chiede il modulo Apply for production?

Il modulo Apply for production, che si apre dalla Dashboard, ha tre parti: il tuo test chiuso, la tua app e la tua prontezza per la produzione. Le risposte vanno perse se fai clic su Discard o lasci una sezione senza fare clic su Next, quindi preparale in anticipo.

Google avverte inoltre che "la revisione non è una fase di risoluzione dei problemi". Prima di inviare la richiesta, verifica la conformità alle norme, la classificazione dei contenuti, la stabilità e, se l'app richiede l'accesso, che le credenziali di login funzionino. La guida alla configurazione dell'account demo è scritta per Apple, ma lo stesso login per il revisore funziona anche per Google.

Cosa verificare prima di premere Apply for production?

Prima di inviare la richiesta, verifica che almeno 12 tester iscritti abbiano ciascuno 14 giorni consecutivi, che il registro del feedback mostri correzioni rilasciate e che tutte le attività di configurazione dell'app siano completate. Pianifica la data di lancio tenendo conto della revisione di Google, che "di solito richiede sette giorni o meno, ma occasionalmente può richiedere più tempo".

Esempio pratico: uno sviluppatore indipendente completa la configurazione dell'app il lunedì e pubblica la build 1. Invita 16 persone da una lista d'attesa e da una community di sviluppatori, e 14 si sono iscritte entro il secondo giorno. Sollecita due persone e ne aggiunge altre tre. Il quarto giorno un tester segnala un crash su un dispositivo più vecchio e la build 2 esce il quinto giorno. Poiché chi si è aggiunto più tardi ha iniziato i suoi 14 giorni più tardi, lo sviluppatore conta i giorni persona per persona, non dalla prima release. Invia la richiesta quando 12 persone hanno 14 giorni consecutivi, con un registro che mostra nove bug trovati e sette risolti.

1. La Dashboard mostra almeno 12 tester iscritti, ciascuno con 14 giorni consecutivi.
2. L'ultima build del canale chiuso è quella che intendi promuovere e rispetta il livello API target attuale (vedi la guida al livello API target 36).
3. Il registro del feedback elenca problemi trovati, modifiche apportate e build rilasciate.
4. Scheda dello store, classificazione dei contenuti, sicurezza dei dati e le altre attività di configurazione sono completate.
5. Le credenziali di accesso per il revisore funzionano, se l'app richiede il login.
6. Le risposte del modulo sono pronte e specifiche su tester reali e modifiche reali.

Se pubblichi anche su iOS, la checklist per l'invio all'App Store copre la parte Apple. Se preferisci affidare il lancio a qualcun altro, il nostro servizio di pubblicazione sugli store configura Play Console e App Store Connect e prepara entrambe le revisioni per $599; le quote degli account sviluppatore sono a parte. Puoi anche scrivere a yagyeshsrbobde@gmail.com.