Test aperto su Google Play 2026: tetto da 1.000+ o 12 tester

Quel requisito è esattamente il vuoto che PrimeTestLab è nato per colmare.

Sono quattro le domande che portano quasi tutti su questa pagina: gli sconosciuti possono trovare la mia app, mi servono davvero 1.000 tester, il feedback della beta mi rovinerà la valutazione e posso usare questo invece di implorare dodici persone di installare qualcosa. Tre di queste hanno risposte pulite nella documentazione di Google, e la quarta è quella che fa male. Qui sotto viene prima la configurazione in Console, perché è a quello che serve questa pagina, e alla quarta domanda è dedicata la sezione subito dopo. Tutto quello che c’è qui è aggiornato al 12 agosto 2026, verificato sulla pagina di Google dedicata ai requisiti di test (risposta 14151465), sulla sua pagina di configurazione dei test (risposta 9845334) e sulla pagina di prodotto del test aperto nella Play Console. Dove un’affermazione poggia su un thread della community invece che su Google, la pagina lo dice invece di promuoverla a fatto.

Che cos’è davvero il test aperto

Metà della confusione nasce dal nome. Chi vede “Open testing” nella Play Console lo legge come uno stato di pubblicazione che potrebbe aver attivato per sbaglio, e chi legge “test” dà per scontato che l’app debba restare nascosta. Nessuna delle due letture è giusta. Il test aperto è un canale di distribuzione che sta accanto al test interno, al test chiuso e alla produzione, e la sua caratteristica distintiva è che ci possono arrivare degli sconosciuti.

In che cosa si differenzia da una release in produzione

Una release in produzione è l’app. Un test aperto è una build parallela che gli utenti con i requisiti scelgono di attivare, e le due possono girare insieme: chi sta in produzione tiene la versione in produzione, e chi entra nel test aperto riceve invece la versione di test. Google risolve la cosa con il codice di versione, servendo a ogni utente il codice di versione compatibile più alto tra i canali per cui ha i requisiti: è per questo che un tester aperto che è anche un utente in produzione può ritrovarsi sull’una o sull’altra build a seconda di che cosa hai pubblicato e dove.

La differenza pratica che conta di più è la reversibilità. Chiudere un test aperto vuol dire mettere in pausa il canale: i tester smettono di ricevere aggiornamenti di test e l’app resta installata sui loro dispositivi. Non esiste un’uscita silenziosa equivalente da un lancio in produzione andato online troppo presto. Per la visione affiancata di tutti e quattro i canali, il confronto tra test interno, chiuso e aperto copre l’intera matrice; questo articolo resta sul test aperto.

Il test aperto in sintesi

Una riga merita un avviso anticipato, perché è la riga che porta la maggior parte delle persone su questa pagina: “nessun numero minimo di tester effettivi” e “un tetto di almeno 1.000” sono due affermazioni diverse su due cose diverse. Il selettore del tetto le smonta come si deve.

Come configurare il test aperto in Play Console

Prima di iniziare

Perché il canale collabori devono essere vere tre cose. Primo, il test aperto deve essere disponibile per il tuo account, il che per un account personale creato dopo il 13 novembre 2023 significa che l’accesso in produzione è già stato concesso. Secondo, deve essere stato caricato un Android App Bundle, perché i controlli dei tester si popolano a partire da un bundle esistente. Terzo, la scheda dello store deve essere pronta a essere vista: Google consiglia che l’app e la scheda dello store siano pronte a essere visibili su Google Play prima di scegliere il test aperto, e quel consiglio serve davvero a qualcosa, non è una formula di rito.

L’articolo di Google dedicato alla configurazione dei test abbrevia la stessa destinazione in Testing, poi Open testing, mentre la sua pagina sui requisiti di test scrive il percorso per esteso. Se la tua Console raggruppa il menu in modo diverso da uno screenshot trovato altrove, il motivo è questo, e la destinazione è la stessa in entrambi i casi.

Configura tester e feedback

Nella pagina Open testing, seleziona la scheda Testers ed espandi Manage testers. Se quella sezione è vuota, l’indicazione di Google è precisa: assicurati di aver caricato un app bundle. Finché non esiste una build non c’è niente da configurare.

Il controllo dei partecipanti ha due impostazioni. Illimitati è selezionata per impostazione predefinita. Numero limitato ti fa impostare un massimo, e Google non accetta un massimo inferiore a 1.000. Quell’unica frase è all’origine di quasi tutta la confusione su questo canale, e per questo ha una sezione tutta sua e uno strumento più avanti.

Poi aggiungi un URL di feedback o un indirizzo email, così i tester hanno un posto dove mandare feedback privati, copia il link di test condivisibile per il reclutamento e seleziona Salva modifiche. Il link di attivazione compare solo quando lo stato dell’app è Published; non si vede per un’app in Draft o Pending publication, il che è utile sapere prima di passare un pomeriggio a cercare un link che ancora non può esistere.

Un controllo sta fuori da quel pannello e viene saltato di continuo: la disponibilità per paese e area geografica. Google documenta la gestione della disponibilità per paese sui canali di test chiuso e aperto di un’app, e “aperto” vuol dire pubblico all’interno dei mercati che hai selezionato, non ovunque. È il motivo silenzioso per cui un link corretto funziona per te e fallisce per il tester a cui l’hai mandato.

La configurazione, in ordine

1. 01
   Verifica che il test aperto sia disponibile per il tuo account

   Per un account personale creato dopo il 13 novembre 2023, l’accesso in produzione deve essere già stato concesso. Un canale in grigio di solito è una questione di requisiti, non un guasto.

2. 02
   Apri il canale

   Test and release, poi Testing, poi Open testing.

3. 03
   Assicurati di aver caricato un app bundle

   Google indica esplicitamente questa soluzione quando la sezione Manage testers è vuota.

4. 04
   Apri la scheda Testers ed espandi Manage testers

   È qui che stanno l’impostazione dei partecipanti e il link condivisibile.

5. 05
   Imposta la capienza dei partecipanti

   Illimitati, che è l’impostazione predefinita, oppure Numero limitato con un tetto di almeno 1.000. Il tetto è un limite massimo, non un obiettivo di reclutamento.

6. 06
   Aggiungi un URL di feedback o un indirizzo email

   Il feedback dei test si legge in Play Console, in Ratings and reviews, poi Testing feedback.

7. 07
   Copia il link di test condivisibile

   Google fornisce un URL che puoi distribuire via web o email; chiunque abbia i requisiti e lo possieda può accedere al test aperto.

8. 08
   Seleziona Salva modifiche

   La configurazione è una cosa diversa dalla release. Salvare qui non pubblica nulla.

9. 09
   Controlla la disponibilità per paese e area geografica

   Google documenta la disponibilità per paese sui canali di test chiuso e aperto. Seleziona i mercati in cui il test deve girare invece di dare per scontato che ogni paese di Play sia attivo, perché un utente fuori da quella disponibilità non può entrare nemmeno con un link per il resto corretto.

10. 10
    Crea e distribuisci la release del test aperto

    Prepara la release sul canale di test aperto e distribuiscila. È il passaggio che rende attivo il canale.

11. 11
    Verifica l’accesso dei tester, poi dai tempo alla propagazione

    Google dice che dopo la prima pubblicazione di un test il link può richiedere qualche ora prima di diventare disponibile, e che le modifiche pubblicate in seguito possono richiedere diverse ore.

Il test aperto può sostituire il test chiuso con 12 tester?

È l’equivoco più costoso tra i risultati di ricerca sul test aperto. Il ragionamento che c’è dietro è del tutto logico: aperto vuol dire che può entrare chiunque, dodici tester sono difficili da trovare, quindi il test aperto dev’essere il modo di saltare il problema del reclutamento. La documentazione di Google chiude quella porta in una sola frase.

Letta in sequenza con il resto di quella pagina, significa che per gli account interessati l’ordine è fisso: prima il test chiuso, poi l’accesso in produzione, poi il test aperto, che è facoltativo. Il processo pubblicato da Google non offre alcuna configurazione né alcun canale di test alternativo che inverta quei primi due passaggi per un account soggetto al requisito.

L’accesso in produzione non è una release in produzione

Queste due espressioni vengono usate una per l’altra e non indicano la stessa cosa. L’accesso in produzione è un permesso che Google concede al tuo account per un’app dopo aver esaminato il tuo test chiuso e le tue risposte sul grado di preparazione. Una release in produzione è quando pubblichi davvero una build sul canale Production per il pubblico generale.

Una volta concesso l’accesso, Google dice che diventano disponibili sia il canale Production sia Open testing. Da lì puoi far girare un test aperto pubblicamente rilevabile mentre l’app non ha ancora avuto alcuna release in produzione. È la sequenza che dovrebbe volere quasi ogni primo lancio: il test chiuso soddisfa il requisito, il test aperto raccoglie segnali dal mondo reale e la release in produzione arriva quando decidi tu.

A quali account si applica davvero

Google fissa il requisito per account sviluppatore personali creati dopo il 13 novembre 2023, una data che risale ormai a 2 anni e 9 mesi fa. Contano due precisazioni, ed entrambe sono punti in cui altre pagine esagerano:

• La data è una soglia, non un annuncio. Il post ufficiale di annuncio di Google è datato 9 novembre 2023. La pagina dei requisiti usa il 13 novembre 2023 come data limite per la creazione dell’account. Scrivere “annunciato il 13 novembre” è sbagliato anche se il numero è giusto.
• Il numero era 20 prima di essere 12. Google ha abbassato la soglia da 20 tester a 12 l’11 dicembre 2024, cioè 1 anno e 8 mesi fa, e la durata di 14 giorni non è cambiata. Le pagine che stampano ancora 20 come requisito attuale sono vecchie, non più severe. La storia completa sta nell’articolo che racconta il passaggio da 20 a 12 tester.

Gli account dell’organizzazione stanno fuori dal testo di quella pagina: Google circoscrive il requisito agli account personali interessati e non lo formula come una regola universale con un’esenzione esplicita per le organizzazioni. Le risposte ufficiali nella community dicono che gli account dell’organizzazione non hanno il requisito di test e, a parte questo, alcuni sviluppatori hanno segnalato account dell’organizzazione migrati che mostravano ancora un vecchio blocco di test. La lettura prudente è che si tratti di ambito, non di immunità: Parziale Segnalato dalla community Se la tua Console mostra ancora il blocco, per il tuo account l’autorità è la tua Console. La scelta del tipo di account, invece, è tema dell’articolo su account personale o dell’organizzazione.

Un’app in test aperto è pubblica o ricercabile?

L’idea che “il test aperto sia solo su invito” è una delle risposte sbagliate più resistenti su questo argomento, e la si vede correggere negli stessi thread dei forum in cui compare. Vale la pena dirlo chiaramente: un test aperto non è una beta privata con un nome dal suono pubblico. Degli sconosciuti possono trovarlo, entrarci e usare la tua app senza mai parlarti.

Questo ha una conseguenza che si sottovaluta finché non è tutto online. La rilevabilità pubblica espone al mercato generale il nome della tua app, l’icona, la descrizione, gli screenshot e la sua stessa esistenza: per questo Google consiglia che l’app e la scheda dello store siano pronte a essere visibili su Google Play prima di scegliere questo canale. Se i concorrenti vadano poi a cercarle è una deduzione pratica da quella rilevabilità pubblica, non qualcosa di cui Google parli; il dato documentato è semplicemente che la scheda si può trovare.

Rilevabile non vuol dire immediato

Google documenta che il test è rilevabile. Non pubblica un tempo garantito perché un’app compaia nella ricerca, e le indicazioni sulla propagazione che dà sono modeste: dopo la prima pubblicazione di un test, il link può richiedere qualche ora prima di diventare disponibile, e le modifiche pubblicate in seguito possono richiedere diverse ore. Oltre a questo, capita che qualche scheda si comporti male davvero. Un thread della Google Play Developer Community dell’aprile 2026 riferisce di una scheda di test aperto che restituiva un 404 mentre il canale risultava attivo. Segnalato dalla community Quello è un caso per l’assistenza, non un periodo di attesa documentato, e la sezione sulla risoluzione dei problemi distingue le due cose.

I tester aperti lasciano valutazioni o recensioni pubbliche?

La paura che porta le persone a questa domanda è precisa e vale la pena nominarla: esce una prima release, gli utenti reali trovano i primi bug e un’ondata di recensioni da una stella blocca per sempre la valutazione dell’app prima ancora che abbia un pubblico. È un rischio reale del pubblicare in produzione troppo presto. Non è un rischio del test aperto.

Che cosa fa davvero il feedback

L’affermazione da fare e quella da evitare

La distinzione conta se ci stai costruendo sopra il tuo piano di lancio. “Il feedback dei test resta privato” è difendibile e verificabile. “I beta tester non possono mai danneggiare la mia valutazione” è un’affermazione più grande di quanto dica la documentazione, ed è la versione più grande quella che prima o poi coglierà qualcuno di sorpresa.

Servono davvero 1.000 tester per il test aperto?

Ogni volta che leggi “il test aperto richiede 1.000 tester” si stanno confondendo due cose diverse. Una è un limite di configurazione su un campo della Play Console. L’altra è un requisito di partecipazione che, per il test aperto, non esiste. Se imposti il tetto a 1.000 e si attivano 37 persone, hai 37 tester aperti e un test aperto perfettamente normale. Il 37 è aritmetica di esempio, non una soglia pubblicata da Google.

Vale anche la pena separare tutto questo dal numero che invece ti vincola davvero. Il 12 di “12 tester per 14 giorni continuativi” è un minimo reale e appartiene al test chiuso, sulla strada verso l’accesso in produzione. Il 1.000 di cui si parla qui è un valore minimo per un tetto massimo, in un canale del tutto diverso. Due numeri, due canali, una collisione molto frequente.

Se quello che vuoi davvero è un piccolo gruppo di tester scelti da te, il tetto non è il tuo problema e il test aperto non è il tuo canale. Una lista di inviti controllata è esattamente ciò a cui serve il test chiuso, e il confronto tra i canali spiega quale serve per quale scopo.

Quando conviene davvero usare il test aperto

Quattro casi in cui il canale si merita l’esposizione

• Distribuire paese per paese

  Google presenta il test aperto come strumento per testare un nuovo mercato e adattarci l’app prima di un lancio più ampio. Una beta pubblica in un solo paese ti dà una varietà di dispositivi reale, condizioni di rete reali e feedback linguistico reale che nessuna lista di inviti tra amici può riprodurre.

• Guardare le metriche prima di impegnarti

  Google descrive il test aperto come un modo per raccogliere feedback quantitativi e qualitativi su larga scala, provare funzionalità pre-release e monitorare le metriche prima del lancio. Se ti servono numeri più che opinioni, un gruppo pubblico più ampio di solito è la via più rapida per ottenerne di statisticamente utili: retention, conversione, carico sul backend e varietà di dispositivi si leggono in modo diverso su larga scala rispetto a dodici installazioni su invito.

• Verifiche su stabilità, retention e monetizzazione

  Google Ads descrive l’uso di un test aperto per valutare la stabilità dell’app, la retention, la monetizzazione e l’efficacia delle creatività pubblicitarie prima di un lancio ampio. Se hai in programma una campagna per app sul test aperto, Google Ads consiglia anche di non limitare i download del test aperto sul Play Store, che è un secondo motivo per lasciare l’impostazione dei partecipanti su Illimitati.

• Un ultimo sguardo a una funzionalità quasi finita

  Il canale è pensato per la fase in cui la build è quasi pronta e le incognite rimaste riguardano il comportamento su larga scala più che i bug evidenti. Il feedback arriva in privato, quindi niente di quello che scopri in questa fase finisce sulla tua valutazione pubblica.

Tre motivi che non sono motivi

• Per evitare di reclutare 12 tester chiusi. Per un account personale creato dopo il 13 novembre 2023 non funziona affatto: il canale sta dietro allo stesso blocco. È il motivo per cui la maggior parte delle persone legge questa pagina, ed è l’unica risposta che non si può addolcire.
• Per tenere privata l’app o la scheda. È l’esatto contrario di quello che fa questo canale. Se il motivo per cui vuoi testare in silenzio è che l’idea non è ancora pubblica, il test aperto ti lavora attivamente contro.
• Per testare con un gruppo piccolo e scelto da te. Quello è il test chiuso. Limitare un test aperto al minimo consentito di 1.000 non lo rende un test privato; imposta soltanto un tetto che non raggiungerai mai.

Dal test chiuso al test aperto alla produzione

Che cosa si porta dietro davvero

“Promuovere” una build suona come un unico pulsante che fa salire la tua app di un gradino. Il comportamento documentato da Google è più meccanico e più utile da capire: la distribuzione si decide utente per utente in base al codice di versione. Ogni utente riceve il codice di versione compatibile più alto pubblicato su un qualsiasi canale per cui ha i requisiti, ed è per questo che un tester aperto che è anche un utente in produzione non resta sulla build di test per fedeltà. Ci resta perché quella build ha il codice di versione più alto.

Lo stesso modello spiega l’etichetta Promoted. Un canale di test risulta Promoted quando i suoi bundle attivi sono attivi anche nel canale di riserva più stabile, cioè quando sul canale di test non c’è nulla che la produzione non abbia già. È la descrizione di uno stato, non un’azione che compi tu.

Il test aperto non compare su Google Play? Controlla prima queste cose

Controlla quattro stati prima di trattarlo come un problema di indicizzazione di Play o come un caso da assistenza. L’app non ha ancora i requisiti per il canale, la release è stata configurata ma mai distribuita, l’app non è in stato Published, oppure non è passato abbastanza tempo dalla prima pubblicazione. Quei quattro sono i posti in cui vivono le spiegazioni ordinarie; tutto il resto è davvero raro.

Che cosa non concludere

Non esiste alcun numero pubblicato di download che un’app debba raggiungere prima di comparire nella ricerca di Play. Quell’affermazione circola come esperienza personale nei thread dei forum e nessuna fonte primaria la sostiene. Non esiste nemmeno un tempo garantito di indicizzazione nella ricerca: Google documenta che il test è rilevabile e dà indicazioni sulla propagazione di link e modifiche, e si ferma lì. Se una scheda è ancora rotta ben oltre la finestra di propagazione documentata, la risposta onesta è che hai un caso per l’assistenza, non un’impostazione che ti sei perso.

Se invece il problema è sul lato chiuso, e i tuoi tester dicono di non vedere affatto l’app, le cause sono un’altra serie: l’articolo su l’app non disponibile ai tester copre i problemi di link e di requisiti, mentre ho aggiunto 12 tester ma 0 si sono attivati copre il problema di conteggio che blocca l’orologio dell’accesso in produzione.

Come ti aiuta PrimeTestLab

Il vero collo di bottiglia è il reclutamento. Quasi tutti gli sviluppatori che leggono queste righe sanno sviluppare l’app, caricare il bundle, scrivere la scheda dello store e rispondere al questionario. Quello che li blocca per settimane è trovare una dozzina di persone con un account Google disposte a installare qualcosa, restare attivate e non disinstallare in silenzio il nono giorno. Non è un problema di ingegneria, ed è esattamente per questo che essere bloccati lì dà così fastidio.

Su 7.400+ app il tasso di successo lato tester si è mantenuto al 99,9%, e quel numero riguarda il test che si svolge senza intoppi, non la decisione di Google sulla tua app. L’approvazione dipende dal rispetto delle norme di Google da parte della tua app, e nessun servizio può prometterla. Quello che fa un test gestito è toglierti di mezzo l’unico requisito puramente logistico, così i quattordici giorni passano davvero. Se un test portato a termine finisce comunque con un rifiuto, la politica di rimborso descrive il nuovo test gratuito e il rimborso completo, e i casi che non copre.

Domande frequenti

Conclusione

Se è proprio quel requisito a bloccarti, è la parte che puoi delegare. Guarda i piani e i prezzi →