Come configurare il test interno di Google Play (2026)

Il test interno è l’unico canale della Play Console che si comporta come uno sviluppatore si aspetta che si comporti un software: carichi una build, compare, le persone la installano. Fino al giorno in cui non succede. E allora ti ritrovi davanti a un link che apre una pagina del Play Store dove c’è scritto che l’app non è disponibile per il tuo account, senza codice di errore, senza diagnostica, e con un articolo della guida che mescola tre canali di test in diverse centinaia di righe. Questo articolo separa il canale interno dagli altri due, ti dà il percorso nella console e le regole sulle liste di tester nell’ordine in cui ti servono davvero, e poi dedica spazio vero alla famiglia di errori che riempie i thread di assistenza. Dove le pagine di Google si contraddicono tra loro, e sui tempi lo fanno in modo evidente, trovi entrambe le letture e non solo quella comoda. Tutto quello che leggi qui è aggiornato al 12 agosto 2026.

Come si configura il test interno?

Prima di cominciare

Prepara l’app, la build, gli account dei tester e il tuo accesso alla Play Console. Nota quello che non serve: una scheda del Play Store finita, gli screenshot, la classificazione dei contenuti o il modulo Sicurezza dei dati compilato. Google consente esplicitamente che un test interno parta prima che l’app sia completamente configurata. Verificato

• 01
  Un’app che esiste nella Play Console Creata, non necessariamente compilata in ogni campo. Il primo artefatto che carichi fissa il nome del pacchetto per quell’app e non si può più cambiare, quindi assicurati che l’applicationId sia quello che intendi tenere.
• 02
  Un app bundle valido Google parla di un «app bundle valido». È l’unico requisito sull’artefatto per far arrivare una prima build interna nelle mani dei tester.
• 03
  Gli indirizzi e-mail dei tester Account Google. La guida attuale specifica un account Google con Gmail, oppure un account Google Workspace. Raccogli l’indirizzo esatto con cui ogni persona sarà collegata, perché è quella l’identità a cui è agganciato tutto il canale.
• 04
  L’accesso alla Play Console per farlo Proprietari e amministratori ce l’hanno già. A un utente delegato serve l’autorizzazione a pubblicare le app sui canali di test, e per gestire il canale e le sue liste di tester può servire l’autorizzazione separata a gestire i canali di test e modificare le liste di tester. Un pulsante di pubblicazione assente o disattivato è un problema di accesso, non di build.
• 05
  Play App Signing, solo alla prima release Per la prima release di un’app, la Play Console ti guida nella configurazione di Play App Signing. È un passaggio una tantum che incontri durante il caricamento e non qualcosa da preparare in anticipo, ma vale la pena sapere che arriva prima di cominciare.

Passaggio 1: apri il canale di test interno

Seleziona la tua app, poi vai su Test and release › Testing › Internal testing. Google documenta questo percorso in due modi diversi. L’articolo della guida della Play Console sulla configurazione di un test lo abbrevia in Testing › Internal testing, mentre un’altra pagina della guida mostra il menu principale per intero. Descrivono la stessa destinazione, quindi se la tua console ha un menu più corto di quello scritto qui non sei nel posto sbagliato.

Passaggio 2: crea la lista dei tester interni

Apri la scheda Testers del canale di test interno e scegli Crea mailing list (Create email list). Dai un nome alla lista, aggiungi gli indirizzi, salva le modifiche e poi crea la lista. Gli indirizzi si possono scrivere direttamente nell’interfaccia separati da virgole, oppure caricare come CSV. È la strada del CSV quella in cui le liste si distruggono in silenzio, perché porta con sé tre regole documentate una volta sola e mai più ripetute.

Validatore della lista tester

Passaggio 3: aggiungi la lista e un canale di feedback

Sempre nella scheda Testers, seleziona la lista o le liste di utenti che vuoi usare per questo canale, poi dai a Google un URL o un indirizzo e-mail per il feedback. Quella destinazione viene mostrata ai tester nella pagina di attivazione, ed è l’unica strada integrata che hanno per dirti che qualcosa non va.

Passaggio 4: crea e pubblica la release

Scegli Crea nuova release (Create new release), aggiungi il tuo app bundle, controllalo e pubblicalo con i comandi attuali della console. Le varianti della Play Console differiscono abbastanza nella formulazione esatta dei pulsanti da rendere una sequenza di clic imparata a memoria più un rischio che un aiuto, quindi le istruzioni si fermano dove si ferma la documentazione attuale di Google.

Passaggio 5: copia e condividi il link di attivazione

Copia il link condivisibile per i tester e mandalo in giro. È il passaggio che confonde gli sviluppatori almeno dal 2018, e la confusione è più che ragionevole: ogni altro sistema di inviti su internet manda un’e-mail, mentre il flusso documentato da Google ti consegna un link da distribuire. Non contare sulla Play Console per invitare i tester al posto tuo.

Due condizioni decidono se quel link esiste già. Il link di attivazione compare solo quando lo stato dell’app è Published. Finché l’app resta in Draft o in Pending publication non c’è niente da copiare, e rileggere la scheda Testers non lo fa comparire. Verificato

Passaggio 6: ogni tester attiva il test e installa

L’ultimo passaggio appartiene al tester, ed è l’unico che non puoi fare al posto suo. Ognuno apre il tuo link mentre è collegato con l’account esatto che hai aggiunto, completa l’attivazione su quella pagina, poi segue il link al Play Store e installa. Finché non succede, sono idonei ma non iscritti, e un tester idoneo non riceve niente. Manda il link scrivendo accanto il nome dell’account che hai invitato, perché attivare il test con l’identità sbagliata è uno degli errori più segnalati di questo flusso e sembra in tutto e per tutto un link rotto.

Chi fa cosa

Tutta la sequenza in una tabella

Scorri la tabella in orizzontale per vedere tutte le colonne

Quanto passa prima che i tester possano installare?

Durante un test interno corrono cinque orologi separati, e le lamentele sui tempi nascono quasi sempre dal confrontare i due sbagliati. Una cosa è la build che arriva al sistema di distribuzione di Google. Il link di attivazione destinato ai tester che diventa attivo è la seconda. Una modifica pubblicata che raggiunge chi è già entrato nel test è la terza. Un’app installata che si aggiorna da sola è la quarta. E la scheda provvisoria sostituita dal nome vero della tua app è la quinta, ed è il motivo per cui una build interna perfettamente funzionante può sembrare incompleta per un paio di giorni.

La mia attesa è ancora normale?

L’unica versione utile di quella domanda include che cosa stai aspettando, perché tra una fase e l’altra la risposta cambia di un fattore cento. Lo strumento qui sotto chiede tutte e due le cose, cita quello che Google pubblica davvero per quella fase ed etichetta i propri riferimenti numerici come lettura di questo articolo e non di Google.

Cronometro di propagazione

Tutti gli orologi, uno accanto all’altro

Scorri la tabella in orizzontale per vedere tutte le colonne

Il punto editoriale da portarsi a casa: pochi secondi, pochi minuti, qualche ora e fino a 48 ore sono tutti veri allo stesso tempo, perché descrivono pezzi diversi della stessa catena. Qualsiasi articolo che li appiattisca in un unico numero finirà per ingannare qualcuno proprio nel momento in cui gli serve precisione. Verificato

Una release interna aspetta la revisione di Google?

Qui le parole vanno scelte con cura, perché le due fonti di Google non sono formulate allo stesso modo. La pagina di prodotto del test interno lo presenta come un modo per distribuire le build senza dover aspettare le revisioni delle app. La guida della Play Console è più prudente e dice che i test interni potrebbero non essere soggetti alle consuete revisioni di norme e sicurezza di Play.

L’affermazione corretta, quindi, è che il test interno normalmente ti lascia distribuire senza aspettare il flusso di revisione standard delle app; quella sbagliata è che le release interne non vengano mai esaminate. Google non ha promesso un’esenzione categorica da ogni revisione, e scrivere che lo abbia fatto è il modo in cui un articolo diventa falso la prima volta che la release interna di qualcuno viene bloccata. Verificato, con una precisazione sulle parole

Il test interno vale per i 12 tester?

È il fraintendimento più costoso di tutto l’argomento, e continua a circolare. Almeno un articolo del 2026 molto ripreso descrive il requisito obbligatorio come qualcosa che si soddisfa sul canale di test interno. La pagina dei requisiti di Google dice il contrario, con parole che non lasciano spazio a interpretazioni.

La regola decisionale, in una riga

Usa il test interno per un QA privato e veloce con persone di cui ti fidi. Usa il test chiuso quando ti serve il test obbligatorio prima della produzione. È tutta qui la regola, ed è di proposito tutto quello che questo articolo dice sul confronto: l’analisi completa dei tre canali sta in test interno, chiuso o aperto, che è costruito apposta per quella domanda.

Scorri la tabella in orizzontale per vedere tutte le colonne

A chi si applica davvero il requisito

Il requisito ha un ambito preciso, ed è proprio lì che si annida quasi tutta la confusione. La pagina di Google lo documenta per gli account sviluppatore personali qualificati creati dopo il 13 novembre 2023. Google ha annunciato la norma il 9 novembre 2023, ed è per questo che vedrai citate entrambe le date come punto di partenza.

Sugli account dell’organizzazione, attenzione a come lo dici. La pagina dei requisiti di Google circoscrive la regola agli account personali; non contiene una frase che dichiari esenti gli account dell’organizzazione. La formulazione difendibile è che il requisito è documentato per gli account sviluppatore personali qualificati e che la pagina citata non lo impone agli account dell’organizzazione. Ambito dedotto

Attivati per 14 giorni non è la stessa cosa di usata per 14 giorni

La soglia numerica è scritta in termini di tester attivati continuamente, non di uso quotidiano. Quella è la parte misurabile. Separatamente, Google valuta quello che dichiari sul tuo test quando richiedi l’accesso in produzione e può chiedere altri test se il numero di tester o il coinvolgimento sono insufficienti. Le pagine concorrenti collassano regolarmente queste due cose in un’unica regola inventata sui minuti di uso giornaliero.

Quindi: la soglia è la continuità dell’attivazione, e il coinvolgimento viene valutato in aggiunta, non al posto suo. Che cosa significhi in pratica per un test in corso lo spiegano la regola dei 14 giorni continuativi e il requisito dei 12 tester spiegato. Verificato

Perché il link del mio test interno non funziona?

È l’errore che riempie i thread della community sul test interno, ed è anche il meno documentato. Gli sviluppatori ci arrivano dopo aver fatto tutto quello che la Play Console ha chiesto, ed è per questo che l’esperienza spiazza tanto: nessun codice di errore, nessuna diagnostica, e la pagina che annuncia allegramente che l’app non è disponibile per il tuo account, come se il problema fosse l’account e non il sintomo. Le segnalazioni vanno da una domanda su Stack Overflow del 2018 fino ai thread della Google Developer Community di luglio 2026, in inglese e in portoghese, e descrivono sempre la stessa manciata di cause.

La mossa utile è smettere di pensarlo come un link rotto e cominciare a pensarlo come un circuito. La regola di consegna di Google è una serie di condizioni, e un solo contatto aperto ferma tutto quello che sta a valle. Quattro stati coprono le cause che tornano di continuo in quelle segnalazioni: non è nella lista dei tester, è nella lista ma non ha attivato il test, ha attivato il test ma usa l’account Google sbagliato e è tutto configurato bene e si sta ancora propagando. L’ultimo non è affatto un guasto, ed è per questo che ci si perde così tanto tempo.

Trova il contatto aperto

Imposta ogni interruttore qui sotto su quello che hai davvero confermato, non su quello che dai per scontato. I contatti sono ordinati in base a quanto poco costa verificarli, quindi il primo ancora aperto è quello su cui conviene lavorare adesso.

Simulatore dei contatti di accesso

“L’app non è disponibile per il tuo account”

L’accesso dei tester è legato a un’identità, non a un dispositivo o a un link. Google richiede che l’account sia incluso nella configurazione dei tester e che abbia attivato quel programma di test. Se manca una delle due metà, il Play Store non ha modo di distinguere quella persona da un estraneo che ha trovato il tuo URL.

Il motivo per cui capita così spesso è banale: telefoni e browser sono abitualmente collegati a più account Google, e quello che apre un link non è sempre quello che hai invitato. Alcuni thread della Google Developer Community di marzo 2026 descrivono tester che non riescono proprio a passare all’identità giusta, perché il selettore degli account si comporta diversamente da come se lo aspettano, e thread in portoghese di metà 2025 riportano lo stesso schema con una risposta che punta dritta alla corrispondenza dell’account selezionato in Google Play. Segnalato dalla community

Non c’è nessun link di attivazione da copiare

Prima di tutto il resto, controlla lo stato dell’app. Google mostra il link di attivazione solo quando lo stato dell’app è Published. In Draft o Pending publication il link non è nascosto né in ritardo: non esiste ancora. È la soluzione più pulita di tutto il set di troubleshooting, perché la condizione è binaria e la vedi nella tua console. Verificato

È pubblicata ma nessuno la trova nella ricerca su Play

È il comportamento previsto, non un difetto. Google afferma che un test interno o chiuso che precede il test aperto o la produzione non è rintracciabile con la ricerca sul Play Store. I tester a cui dici di «cercare l’app su Play» falliranno ogni volta, per quanto la tua configurazione sia corretta, e ti diranno con ragione che l’app non esiste.

Manda il link diretto. Scrivi esplicitamente nel messaggio che cercare l’app non funziona, perché è la prima cosa che tutti provano. Verificato

Alcuni tester sono ancora sulla versione vecchia

Lavora su tre cause, in ordine. Primo, la propagazione: le altre modifiche pubblicate possono metterci diverse ore ad arrivare ai tester, quindi un aggiornamento recente potrebbe semplicemente non essere arrivato. Secondo, i codici di versione: un utente riceve il codice di versione compatibile più alto tra tutti i canali per cui è idoneo e, siccome tutti sono idonei per la produzione, può arrivargli un codice di versione di produzione più alto al posto di una versione di test più bassa. Ne esce la situazione paradossale in cui la tua build interna più recente è vera, corretta e comunque non è quella che ha il tester. Terzo, l’idoneità del canale: un account attivato sul test interno non è idoneo a ricevere le build chiuse o aperte, quindi se hai spostato il lavoro su un altro canale, quell’account sta guardando dalla parte sbagliata. Verificato

Torna tutto e continua a non funzionare

Adesso, e solo adesso, vale la pena provare i rimedi della community: riavviare il dispositivo, riavviare il Play Store, svuotare la cache o i dati del Play Store, o aprire il link in un profilo del browser pulito. Arrivano dai thread della Google Developer Community, non dalle norme di Google, e sono riportati come cose che hanno funzionato a qualcuno, non come comportamento documentato. Metterli al primo posto è il modo in cui gli sviluppatori perdono giornate intere, perché non sistemano un problema di configurazione e mascherano un ritardo di propagazione facendolo passare per un successo. Segnalato dalla community

Esiste anche un caso limite vero. Un thread della community di febbraio 2026 descrive un link di test interno che non ha mai funzionato, e un thread di maggio 2026 riporta un HTTP 500 sulla pagina di attivazione. Per nessuno dei due è stata accertata una causa generale, e inventarsi una spiegazione tecnica sarebbe peggio che ammetterlo. Se la tua configurazione è verificabilmente corretta, le finestre di propagazione sono passate e l’errore è persistente o restituisce un errore del server, quello è un buon momento per rivolgersi all’assistenza della Play Console invece di continuare a cambiare impostazioni. Causa non verificata

Dal sintomo alla soluzione, con il grado di evidenza

Scorri la tabella in orizzontale per vedere tutte le colonne

Limiti e regole che quasi tutti sbagliano

Scorri la tabella in orizzontale per vedere tutte le colonne

Test interno e condivisione interna delle app

Sono due funzionalità diverse con nomi che si somigliano fin troppo, e sbagliare quella giusta costa un pomeriggio. Il test interno è il canale formale descritto in tutto questo articolo: una release, una lista gestita di massimo 100 tester, l’attivazione e gli aggiornamenti consegnati tramite Google Play. La condivisione interna delle app è invece uno strumento di condivisione rapida che prende un APK o un app bundle caricato e ti restituisce un link di download da girare in giro. Ha controlli di accesso propri, semplicemente diversi: la pagina di Google che la descrive ti lascia limitare i download a mailing list oppure aprire il link a chiunque tu lo mandi e, in entrambi i casi, il tester deve prima attivare la condivisione interna delle app nella sua app Play Store.

La regola pratica: usa la condivisione interna delle app per lanciare una build a un collega nei prossimi dieci minuti, e usa il canale di test interno quando vuoi lo storico delle versioni, la lista dei tester e una build che potrai promuovere più avanti. La scadenza a 60 giorni è il dettaglio che frega le persone, perché un link che funzionava in una segnalazione di due mesi fa è semplicemente morto, non configurato male. Nessuna delle due funzionalità conta per il test chiuso con 12 tester. Verificato

La trappola degli acquisti in-app

Non ripetere l’affermazione più diffusa, cioè che durante il test interno sia tutto gratuito. La regola di Google separa l’app da quello che ci si vende dentro. L’app a pagamento in sé è gratuita da installare per un tester interno. Gli acquisti in-app continuano invece ad addebitare, a meno che l’account di quel tester non sia configurato anche come tester delle licenze.

Su un test che coinvolge abbonamenti la differenza vale soldi veri, e almeno un articolo di confronto oggi ben posizionato afferma il contrario senza mezzi termini. Se i tuoi tester stanno per provare un flusso di acquisto, configura prima il test delle licenze oppure mettiti in conto addebiti reali. Verificato

Due cose che non sono colpa tua

Buona parte dei consigli generici sul test interno che si trovano online ti dice di sistemare cose che non possono essere la causa: fai perdere tempo e a volte rompi una configurazione che funzionava.

Affermazioni verificate, con verdetto

Ogni riga qui sotto è un’affermazione che circola davvero sul test interno. La colonna del verdetto dice quello che sostengono le fonti primarie, non quello che suona ragionevole.

• Falso
  “Il test interno vale come test dei 12 tester.” La pagina dei requisiti di Google chiede espressamente un test chiuso. È l’errore più costoso di tutto l’argomento, perché fa perdere alle persone l’intera finestra di 14 giorni.
• Superato
  “Servono ancora 20 tester.” Storia vecchia dall’11 dicembre 2024. Il minimo attuale è 12.
• Falso
  “I tester interni hanno tutti gli acquisti gratis.” È gratuita solo l’app a pagamento in sé. Gli acquisti in-app addebitano, a meno che non sia configurato il test delle licenze.
• Falso
  “Se il tuo tester è all’estero, aggiungi il suo paese.” Google esenta espressamente il test interno da quella limitazione sulla distribuzione.
• Fuorviante
  “Se non funziona subito, il tuo link è rotto.” È Google stessa a mettere in conto qualche ora per un primo link e diverse ore per le modifiche successive.
• Fuorviante
  “I tester ricevono il link di attivazione via e-mail in automatico.” Il flusso documentato da Google prevede che sia lo sviluppatore a copiare il link condivisibile e a distribuirlo. Non fare piani basati sulla Play Console che invita i tester al posto tuo.
• Parziale
  “Per il test interno puoi usare un gruppo Google.” La guida attuale della Console documenta le mailing list per il test interno e i gruppi Google per il test chiuso. La risorsa testers dell’API di pubblicazione supporta i gruppi in modo più ampio, ma questo non stabilisce come si comporti la Console nel 2026 per questo canale. Usa il metodo documentato con la mailing list e non fare piani su un gruppo.
• Parziale
  “Google consente esattamente un canale interno.” L’API di pubblicazione espone il canale interno standard come un unico canale predefinito, e la guida documenta altri canali chiusi con nome proprio senza pubblicare un numero massimo di canali interni. Di’ «il canale di test interno standard» invece di affermare un limite rigido.
• Vero
  “Puoi eseguire un test interno prima di finire la scheda del Play Store.” Google dice che un app bundle valido basta per distribuire internamente prima che l’app sia completamente configurata.
• Vero
  “Il feedback dei tester in un test non danneggia la mia valutazione pubblica.” Google afferma che il feedback degli utenti di un test non incide sulla valutazione pubblica dell’app.

Chiudere un test interno

Metti in pausa il canale. I tester tengono la copia che hanno già installato, ma smettono di ricevere aggiornamenti di test da lì. Vale la pena saperlo prima di dare per scontato che mettere in pausa un canale tolga l’app dal telefono di qualcuno, perché non è così. Verificato

Come si sposta una build sul test chiuso?

È il passaggio a cui arriva quasi chiunque dopo un test interno riuscito, ed è qui che il percorso verso l’accesso in produzione comincia davvero a contare. Le istruzioni qui sotto evitano di proposito uno script pulsante per pulsante, perché le varianti della Play Console sono diverse tra loro e un percorso di clic imparato a memoria è la prima cosa che si rompe.

1. 01
   Apri il canale di destinazione Vai su Test and release › Testing › Closed testing e gestisci il canale chiuso che vuoi usare.
2. 02
   Crea una release su quel canale Una release chiusa è una release a sé, anche se porterà l’artefatto che hai già testato.
3. 03
   Riusa l’artefatto testato con Aggiungi dalla libreria Seleziona la versione che hai caricato durante il test interno invece di ricaricare il bundle. È questa la parte documentata nella guida attuale di Google sulle release (risposta 9859348). Verificato
4. 04
   Configura i tester del test chiuso Usa i comandi dei tester propri del canale chiuso. Per il test chiuso la guida attuale supporta le mailing list oppure i gruppi Google, ed è una differenza reale rispetto al canale interno.
5. 05
   Controlla e pubblica Poi condividi il link di attivazione del test chiuso come hai fatto con quello interno. Valgono le stesse due condizioni: essere nella lista ed essere attivato.

Posso tenere gli stessi tester?

Sì come persone, no come attivazioni contemporanee, ed è la distinzione che a questo punto manda all’aria più test chiusi di qualunque altra cosa.

Un account attivato sul test interno non è idoneo a ricevere le build del test aperto o chiuso. L’istruzione di Google è che il tester esca prima dall’interno e poi attivi il test chiuso. Quindi il gruppo di QA interno che hai messo insieme con cura può senz’altro diventare il tuo gruppo di test chiuso, ma ognuno di loro deve uscire attivamente dal canale interno prima di riuscire a vedere qualcosa su quello chiuso.

Scorri la tabella in orizzontale per vedere tutte le colonne

Da qui in poi la meccanica è un altro argomento: reclutare persone che restino attivate per 14 giorni continuativi, farle contare come si deve e superare il questionario per l’accesso in produzione. Se ne parla in come invitare i tester al test chiuso, perché la Play Console mostra 0 tester attivati e il questionario per l’accesso in produzione.

Dove entra PrimeTestLab

Vale la pena essere precisi su questo passaggio di consegne, perché i due canali falliscono per motivi completamente diversi. Il test interno fallisce sulla configurazione: un link che non esisteva ancora, un account che non ha mai attivato il test, una finestra di propagazione che qualcuno non ha aspettato. Sono problemi che si risolvono leggendo con attenzione, ed è a questo che servono i primi due terzi di questo articolo.

Il test chiuso fallisce sulle persone. La condizione numerica pubblicata da Google è almeno 12 tester attivati sul test chiuso negli ultimi 14 giorni continuativamente, che in pratica vuol dire dodici esseri umani che entrano e che ci sono ancora nella seconda settimana. Oltre a quel conteggio, ti serve che quei tester installino e usino la build in modo significativo, perché quando esamina la richiesta di accesso in produzione Google fa domande su coinvolgimento, uso delle funzionalità e feedback. Nessuna delle due metà è un problema di documentazione, e nessuna quantità di competenza sulla console le risolve. La maggior parte degli sviluppatori se ne accorge nel momento in cui finisce il test interno e capisce che il requisito non si è spostato di un millimetro.

Eseguire il test chiuso da soli, oppure affidarlo a noi

Scorri la tabella in orizzontale per vedere tutte le colonne

Sì, 25 tester oggi costano meno di 20. È una promozione, non un refuso: in questo momento Enterprise porta lo sconto più profondo dei tre piani, il che gli dà anche il costo per tester più basso, circa $1.12 contro $1.50 del piano Professional. I due piani eseguono lo stesso test chiuso: l’unico motivo per cui l’ordine si inverte è la promozione, e la pagina dei prezzi riporta la cifra aggiornata se nel frattempo è cambiata.

Su 7.400+ app in 120+ paesi manteniamo un tasso di successo del 99,9% sul requisito del test chiuso. Quello che non ti diremo mai è che l’approvazione è garantita. Google valuta la richiesta di accesso in produzione secondo criteri suoi e può chiedere altri test, e chi ti promette un esito certo ti sta descrivendo qualcosa che non controlla. Quello su cui ci impegniamo è la parte che controlliamo: se il test non va a buon fine, ricevi un nuovo test gratuito o il rimborso completo.

FAQ sul test interno

Conclusione