No: non azzera mai
Un aggiornamento ordinario lascia scorrere il tempo di attivazione dei tuoi testerGoogle non pubblica alcuna regola secondo cui creare una nuova release faccia ripartire il test chiuso. Il requisito riguarda ogni tester che resta attivato per 14 giorni continui, con almeno 12 tester di questo tipo al momento della richiesta. Il version code e il numero di build che carichi non ne fanno parte.
Tester che escono dal test, così meno di 12 hanno 14 giorni senza interruzioni.
Un tester che disattiva il test e rientra ricomincia i propri 14 giorni, e un sostituto parte dal primo giorno. Se così ti restano meno di 12 tester con 14 giorni senza interruzioni, la tua richiesta deve aspettare. La causa non è l’aggiornamento.
Risposta rapida
No. Aggiornare la stessa app sul suo canale di test chiuso in corso non fa ripartire di per sé il tempo di attivazione dei tuoi tester. Per gli account sviluppatore personali creati dopo il 13 novembre 2023, l’app ha bisogno di almeno 12 tester rimasti attivati ciascuno negli ultimi 14 giorni consecutivi quando richiedi l’accesso in produzione. Un tester che disattiva il test ricomincia i propri 14 giorni. Google raccomanda di agire in base ai feedback, ma non pubblica alcun numero obbligatorio di release. Se i tester non vedono una nuova build, controlla la pubblicazione, l’idoneità all’implementazione e l’aggiornamento sul dispositivo.
È una delle paure più comuni nel test chiuso: sei a metà della finestra di 14 giorni, trovi un bug e ti blocchi, temendo che caricare una correzione cancelli i progressi e ti costringa a ricominciare le due settimane da capo. Non succede. Il requisito dei 14 giorni osserva i tuoi tester, non le tue build. Questa guida separa ciò che interrompe la finestra del test chiuso da ciò che non la interrompe, ti offre due strumenti interattivi per provare tu stesso qualsiasi azione e spiega cosa controllare quando i tester non vedono una nuova build. È stata verificata l’ultima volta sulle pagine di assistenza di Google il 16 ottobre 2026.
In questa guida
Aggiornare l’app azzera l’orologio di 14 giorni del test chiuso?
No. È la paura più comune tra gli sviluppatori durante la finestra di test, e la risposta è rassicurante: caricare un nuovo app bundle sul canale di test chiuso esistente non fa ripartire di per sé il tempo di attivazione dei tuoi tester.
Il requisito dei 14 giorni è legato ai tuoi tester, non alla tua build. Google lo misura per singolo tester: quando richiedi l’accesso in produzione, almeno 12 tester devono essere stati attivati ciascuno negli ultimi 14 giorni, continuamente. Il numero di versione della tua app, quante volte carichi un nuovo AAB e cosa cambi nelle note di rilascio non fanno parte di quel requisito.
Questa domanda torna di continuo nella Google Play Developer Community. Il Centro assistenza di Play Console definisce il requisito solo in termini di tester attivati e di tempo, mai di caricamenti di build. Un Product Expert di Google ha dato la risposta pratica direttamente, in una risposta della community accettata a gennaio 2024: un aggiornamento durante il test può richiedere una revisione, ma non azzera i 14 giorni. È la lettura delle norme da parte di un esperto, non una frase delle norme stesse.
Hai dubbi su un’azione specifica? Usa il verificatore qui sotto: scegli cosa stai per fare e ti dirà se tocca i 14 giorni dei tuoi tester.
Quale azione ti preoccupa?
Basato sul requisito pubblicato della Play Console di Google (tester attivati × giorni consecutivi) e sull’esperienza ampiamente riportata dagli sviluppatori. I due rischi segnalati dalla community sono identificati come tali.
Cosa azzera davvero il timer di 14 giorni?
La finestra continua di 14 giorni si capisce meglio come controllo di coerenza, non come conteggio passivo del calendario. Google vuole vedere che hai mantenuto almeno 12 tester attivati senza interruzioni. Ci sono solo due trigger confermati che interrompono quella continuità:
Il conteggio degli attivati scende sotto i 12
Se un tester esce e scendi a 11 tester validi, non puoi fare richiesta finché un dodicesimo tester non ha 14 giorni senza interruzioni, e un sostituto parte dal primo giorno. Ecco perché lavorare con esattamente 12 tester è rischioso.
I tester escono formalmente dal test
Un tester esce aprendo il link web del test e scegliendo di uscire. È diverso dalla disinstallazione. I 14 giorni di quel tester si fermano, e se rientra ricominciano. Ritarda la tua richiesta solo se ti lascia con meno di 12 tester validi.
Inviare un build nuovo non è in questa lista. Né correggere un typo nella scheda dello store, un tester che invia feedback, né l’app che va in crash sul dispositivo di un tester: quest’ultimo è proprio il punto del test. Il simulatore qui sotto rende chiara la differenza: premi pure il pulsante di update e non si muove nulla; perdi tester sotto i 12 e la sequenza crolla.
Cosa NON azzera l’orologio
Inviare un AAB nuovo sullo stesso canale
Modificare note di versione o scheda dello store
Un tester che invia feedback
L’app che va in crash sul dispositivo di un tester
Alzare il versionCode o il nome della versione
Un tester che disinstalla senza uscire dal test
Come invio un update a un test chiuso?
Inviare un update è lo stesso flusso della tua prima versione, con una differenza importante: crei la nuova versione sullo stesso canale di test chiuso in cui i tuoi tester sono già attivati. Non avvii un test nuovo: aggiungi un build al test che sta già girando, ed è proprio per questo che l’orologio di 14 giorni continua. Ecco i due passaggi in Play Console.
Crea una nuova release sul canale chiuso Test e rilascio > Test > Test chiuso > Gestisci canale
Apri il canale di test chiuso che stai già usando, fai clic su Crea nuova release e carica l’app bundle (AAB) aggiornato. Mantieni lo stesso nome del pacchetto e la stessa configurazione di firma, e assegna alla build un versionCode più alto: cambiare solo il versionName non è un upgrade. Aggiungi brevi note di rilascio che descrivono cosa è cambiato, poi salva. Resta sullo stesso canale: è questo che fa continuare i 14 giorni dei tuoi tester.
Rivedere e lanciare l’update Review release > Start roll-out
Procedi con Avanti e Rivedi release, poi avvia l’implementazione sul canale chiuso. Quindi apri Panoramica della pubblicazione: se ci sono modifiche in attesa, scegli Invia modifiche per la revisione, e se la pubblicazione gestita è attiva, pubblica tu le modifiche approvate. Un aggiornamento inviato può risultare In revisione prima che i tester lo ricevano, e Google osserva che una modifica pubblicata può richiedere diverse ore per arrivare ai tester. I tester esistenti di norma si aggiornano direttamente, senza reinstallare e senza una seconda attivazione.
Questo non fa ripartire il tempo di attivazione dei tuoi tester. Poiché pubblichi sullo stesso canale chiuso in cui i tester sono già attivati, i loro 14 giorni continuano a scorrere sotto la nuova build. Stai aggiungendo una build, non avviando un nuovo test. Se i tester ancora non vedono la nuova build, segui i controlli della sezione successiva.
Perché i tester non ricevono la nuova build?
Prima verifica che la build prevista sia pubblicata sul canale del tester, poi controlla l’account del tester e la versione installata, e solo alla fine il telefono. È un ordine di controlli, non una classifica delle cause più comuni. Hai finito quando un tester idoneo ha installato la build prevista e ha testato di nuovo la modifica; una nuova data nella scheda dello store non basta.
Il mio aggiornamento è ancora in revisione
Un aggiornamento inviato può richiedere una revisione prima che quella build arrivi ai tester. Apri Panoramica della pubblicazione in Play Console e agisci in base a ciò che mostra:
- Modifiche non ancora inviate: controlla l’elenco e scegli Invia modifiche per la revisione.
- In revisione: verifica che siano l’app, il canale e la versione giusti e segui eventuali messaggi nella Console. Non caricare un’altra build solo per sbloccarla; Google conta il tempo di revisione dall’ultima modifica inviata.
- Modifiche pronte per la pubblicazione: la pubblicazione gestita è attiva, quindi pubblica tu le modifiche approvate.
Una release in attesa di revisione e i tuoi tester che restano attivati sono due stati separati. Google non indica da nessuna parte che la revisione di un aggiornamento ordinario metta in pausa o azzeri il tempo di attivazione dei tuoi tester.
Solo alcuni tester riescono ad aggiornare
Un aggiornamento pubblicato raggiunge solo i tester a cui viene distribuito e che ne hanno diritto. Controlla questi punti in ordine:
- Implementazione graduale: gli aggiornamenti sui canali di test, test chiuso compreso, possono usare una percentuale di implementazione, che non aumenta da sola. In Test chiuso > Release, apri Gestisci implementazione per vedere la percentuale e se l’implementazione è interrotta.
- Account: l’indirizzo nel tuo elenco o nel tuo Google Group, l’account che ha attivato il test e l’account con cui è stato eseguito l’accesso al Play Store devono essere lo stesso.
- Test interno: un tester ancora attivato nel tuo test interno non può ricevere le build del test chiuso finché non esce dal test interno e partecipa a quello chiuso. È una correzione dell’iscrizione, non un passaggio di routine dell’aggiornamento.
- Version code: Google Play installa il versionCode compatibile più alto a cui il tester ha diritto. Cambiare solo il versionName non è un upgrade.
- Dispositivo: la build deve supportare il dispositivo del tester e le tue impostazioni di distribuzione devono includerlo.
La release è disponibile, ma il telefono ha ancora la vecchia build
Usa il percorso di aggiornamento del Play Store prima di toccare l’iscrizione del tester:
- Apri la scheda Play dell’app tramite il tuo link di test e tocca Aggiorna se compare, oppure vai al tuo profilo > Gestisci app e dispositivo > Aggiornamenti disponibili.
- Controlla l’aggiornamento automatico: può essere disattivato, limitato al Wi-Fi o disattivato solo per questa app.
- Controlla la connessione e lo spazio libero, poi chiudi e riapri il Play Store.
- Solo a quel punto svuota la cache del Play Store (informazioni app > Spazio di archiviazione e cache > Svuota cache). Svuotare la cache non può pubblicare una release che è ancora in revisione.
Non chiedere ai tester di uscire dal test e rientrare per ricevere un aggiornamento. Uscire interrompe i 14 giorni senza interruzioni di quel tester. Nemmeno disinstallare l’app, cancellare i dati di Google Play Services o ripristinare il telefono fa parte di un normale aggiornamento.
Qual è la differenza tra tester invitati e attivati?
Questa distinzione fa fallire più pubblicatori al primo colpo di qualsiasi altra cosa, ed è la chiave per capire perché i build non contano per l’orologio. Il sistema di Google muove i tester in un funnel, e solo le fasi finali pesano.
Invitato
Hai aggiunto un’email all’elenco dei tester o a un Google Group. Nient’altro è ancora successo.
Attivato
La persona ha aperto il link di invito, ha effettuato l’accesso con l’account Google e ha attivato il test. È lo status che l’orologio di 14 giorni misura.
Installato e attivo
Ha scaricato l’app e continua a usarla. Non cambia il conteggio grezzo, ma è ciò che Google pesa nell’engagement al momento dell’accesso alla produzione.
Come chiarisce la documentazione di Google, aggiungere un’email non basta. Ogni tester deve aprire il link di attivazione, autenticarsi e diventare tester in modo esplicito prima di essere conteggiato. È anche per questo che un aggiornamento ordinario dell’app non fa ripartire i tuoi progressi: i tester restano attivati, quindi i loro giorni continuano a contare tra una build e l’altra. Per la guida completa passo passo, vedi come invitare i tester correttamente.
Consiglio di chi gestisce migliaia di test: gestisci i tester tramite un Google Group invece che con un elenco statico di email. Google documenta che il caricamento di un CSV sovrascrive l’elenco di tester precedente, quindi un Group evita di cancellare per errore tester attivi mentre modifichi l’elenco. Un Group non è però una garanzia: l’appartenenza continua a controllare l’accesso, quindi rimuovere qualcuno dal Group o collegare un Group diverso cambia chi è idoneo.
Qual è la formulazione esatta del requisito di Google?
La pagina ufficiale di aiuto di Play Console, "App testing requirements for new personal developer accounts", dichiara con precisione:
"If you have a newly created personal developer account, you must run a closed test for your app with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously."
Google Play Console Help · answer 14151465E, separatamente, nel momento in cui richiedi l’accesso alla produzione:
"At least 12 testers must be opted-in to your closed test when you apply for production access. They must have been opted-in for the last 14 days continuously."
Google Play Console Help · answer 14151465Google lascia anche chiaro, con le sue parole, che i giorni devono essere consecutivi: non contano i tester che hanno attivato il test, testato per meno di 14 giorni e poi uscito, e anche se tornano ad attivare, i 14 giorni devono essere consecutivi per contare. Quella clausola da sola uccide il mito che "i 14 giorni sono cumulativi" e, con la stessa importanza, non dice nulla sui tuoi build.
Tre fatti da fissare
Inviare update durante il test è buono o cattivo?
Qui l’ansia dello sviluppatore diventa opportunità. Inviare update durante il test chiuso è ampiamente visto come segnale positivo di engagement. Vale separare cosa dice Google ufficialmente da cosa ha concluso la community di sviluppatori, perché le due cose si sovrappongono senza essere identiche:
Continua a iterare e correggere
L’aiuto di Play Console incoraggia l’iterazione continua: continua a usare il test chiuso mentre correggi problemi e bug segnalati dagli utenti, e aggiornare l’app nel test chiuso prima di andare in produzione è "un ottimo modo per ridurre recensioni e valutazioni di bassa qualità".
Quando richiedi l’accesso alla produzione, il modulo chiede di descrivere l’engagement ricevuto e cosa hai fatto con il feedback dei tester.
Attivo batte congelato
Chi è sul campo va oltre: un’app ferma alla versione 1.0 per 14 giorni senza alcuna attività sembra un test fatto solo per spuntare la casella, mentre una che pubblica correzioni in risposta ai feedback sembra sviluppo vero. Alcuni sviluppatori pubblicano due o tre piccoli aggiornamenti per mostrare reattività, ma Google non pubblica alcuna quota del genere (vedi la sezione sul numero di release più sotto).
Questa è un’opinione della community e un’inferenza ragionevole, non una regola pubblicata di Google. Google non ha fissato alcun requisito numerico del tipo “pubblica X aggiornamenti”.
Il messaggio: aggiornare è sicuro e incoraggiato, e la storia di engagement che costruisci con questo può aiutarti a rispondere al modulo di produzione. L’unico rischio reale viene da cosa invii, non dall’atto di inviare, e questo porta all’unica vera riserva.
Servono due o tre release durante il test chiuso?
Le indicazioni pubblicate da Google sul test chiuso non fissano un numero minimo di release. Raccomandano di agire in base ai feedback dei tester e di correggere i problemi emersi durante il test, e la richiesta di accesso in produzione ti chiede di descrivere le modifiche che hai apportato. Il numero di caricamenti non fa parte del requisito.
- Mantieni almeno 12 tester attivati per 14 giorni senza interruzioni (requisito pubblicato)
Proteggi l’attivazione continua di ogni tester fin dal primo giorno. - Agisci in base ai feedback e correggi i problemi emersi dal test (indicazione di Google)
Tieni una breve traccia del feedback, della correzione e del nuovo test. - Pubblica due o tre release in ogni caso (folklore della community, nessuna quota pubblicata)
Non inventare modifiche e non aspettarti che un numero di release ti faccia ottenere l’approvazione.
Da dove viene il consiglio: la versione esplicita più antica che abbiamo trovato è un’ipotesi di uno sviluppatore, in una discussione di ottobre 2024, secondo cui due o tre aggiornamenti potrebbero mostrare a Google un lavoro guidato dai feedback. È stata ripetuta nei thread della community nel giro di poche settimane e in seguito è comparsa nelle guide come se fosse una raccomandazione di Google. La fonte originale è sconosciuta, e gli sviluppatori riferiscono rifiuti sia con sia senza diversi aggiornamenti, quindi un numero di release da solo non dimostra nulla.
Se il test trova un problema reale, correggilo, pubblica la build e chiedi ai tester di testare di nuovo. Se non lo trova, dillo con onestà quando rispondi al questionario per l’accesso in produzione. Caricare build solo estetiche mentre un aggiornamento è in revisione può anche rimandare indietro la tua app nella coda di revisione, perché Google conta il tempo di revisione dall’ultima modifica inviata.
Un update cattivo può azzerare l’orologio in modo indiretto?
Sì, ed è la riserva che conta. Sebbene l’atto di aggiornare non azzeri mai il timer in modo diretto, le conseguenze di un update rotto possono. Segui la catena:
Quindi la regola è semplice: aggiorna pure, ma valida la stabilità di base di ogni build prima di inviarlo al canale chiuso. E non correre mai con esattamente 12 tester, perché una sola uscita per un build cattivo può farti scendere. Un buffer di tester sopra i 12 assorbe quel rischio.
Leggi la catena con attenzione: l’aggiornamento non fa ripartire il tempo di attivazione di nessuno. Il ritardo deriva dalla perdita di tester validi; la build difettosa è solo ciò che ha provocato le uscite. Mantieni build stabili e un buffer, e il rischio indiretto diventa molto più piccolo.
I tester devono reinstallare o attivare di nuovo dopo un update?
No. I tester esistenti che hanno attivato il test e installato la tua app di norma si aggiornano direttamente tramite Google Play. Non devono attivare di nuovo il test e tu non devi inviare di nuovo il link.
Di norma gli aggiornamenti si installano sopra la versione esistente
L’aiuto di Play Console, in Set up an open, closed, or internal test (answer 9845334), lo dice chiaro: "Once your testers have installed your app, they'll automatically be updated to use the test version within a few minutes." I tester restano attivati su ogni build: senza reinstallare, senza un secondo clic per attivare il test.
Una riserva di tempo dalla stessa pagina di Google: quando pubblichi modifiche aggiuntive, "may not be available for testers for several hours" prima dell’update automatico sul dispositivo. Ma lo status di attivazione dei tester, che è ciò che l’orologio di 14 giorni misura, prosegue su ogni AAB nuovo. È esattamente per questo che un update di build non azzera l’orologio: i tester non sono mai usciti.
Eccezione importante Nuove autorizzazioni possono interrompere l’update silenzioso
Un tipo di build non sempre si distribuisce in silenzio: un update che aggiunge una autorizzazione pericolosa (sensibile) nuova, come ACCESS_FINE_LOCATION, fotocamera o microfono. A seconda dell’autorizzazione e del target API level, Google Play può mostrare un pulsante Update che il tester deve toccare e approvare a mano invece di installare in background, e chi lo ignora resta sul build vecchio. Anche quando l’installazione è silenziosa, l’autorizzazione nuova viene concessa solo a runtime, quindi una funzione che ne dipende può sembrare rotta finché il tester non la concede.
In un test chiuso è una trappola silenziosa: pubblica a metà test un aggiornamento pieno di autorizzazioni e alcuni tester possono restare sulla vecchia build o trovare una funzione bloccata finché non concedono l’autorizzazione. Una nuova autorizzazione ad alto rischio può anche richiedere una dichiarazione delle autorizzazioni in Play Console prima che la build possa essere pubblicata. Il consenso in fase di esecuzione sul telefono e la dichiarazione nella Console sono controlli separati.
Prima di lanciare a metà test: confronta le autorizzazioni del manifesto nuovo con il build live. Se l’insieme delle autorizzazioni è cambiato, avvisa i tester di aprire Play Store e aggiornare manualmente (e concedere il nuovo prompt), e lascia margine per una possibile revisione della dichiarazione.
Miti comuni del test chiuso, smentiti
Gran parte del panico intorno all’aggiornare si riduce a una manciata di miti. Ecco i cinque che rubano più sonno agli sviluppatori, con ciò che è vero davvero:
Mito 1"Creare una nuova versione azzera l’orologio."
Mito 2"Disinstallare è uguale a uscire dal test."
Mito 3"I 14 giorni sono cumulativi."
Mito 4"Esattamente 12 tester bastano."
Mito 5"I tester devono usare l’app ogni giorno."
Cosa azzera l’orologio e cosa no
Ecco l’intera domanda in una schermata. Salvala, fai uno screenshot o inviala a chi nel team continua a chiedere. Tutto legato al build è sicuro; solo ciò che muove il conteggio dei tester non lo è.
| Azione | Azzera l’orologio di 14 giorni? |
|---|---|
| Inviare un AAB nuovo sullo stesso canale chiuso | No |
| Modificare note di versione o metadati della scheda | No |
| Un tester che invia feedback | No |
| L’app che va in crash sul dispositivo di un tester | No |
| Un tester che disinstalla (senza uscire dal test) | No* |
| Il conteggio degli attivati scende sotto i 12 | Sì |
| Un tester che esce formalmente dal link web | Sì** |
| Inviare un build rotto che genera uscite sotto i 12 | Indirettamente |
| Mettere in pausa il canale di test chiuso | Rischio segnalato |
| Sovrascrivere l’elenco e omettere tester attivi | Rischio segnalato |
* Non è un’uscita dal test, ma un tester senza l’app installata non la sta testando. ** Solo se ti lascia con meno di 12 tester validi. “Sì” qui significa che la tua prima data utile per la richiesta slitta: i tester rimasti conservano i loro giorni, ma un sostituto parte dal primo giorno. Google documenta che il caricamento di un CSV sovrascrive l’elenco precedente e che mettere in pausa un test ne blocca gli aggiornamenti; come vengano contati i giorni dopo non è documentato, quindi considera le ultime due righe come “non rischiare”.
Come il requisito è cambiato nel tempo
Se stai leggendo tutorial vecchi, ecco perché i numeri non tornano. La durata è sempre stata 14 giorni consecutivi; solo il conteggio dei tester si è mosso.
Prima di novembre 2023 non c’era un test chiuso obbligatorio per arrivare in produzione. Potevi pubblicare senza reclutare tester.
Google ha annunciato il requisito il 9 novembre 2023. Gli account personali creati dopo il 13 novembre 2023 dovevano eseguire un test chiuso con 20 tester attivati per 14 giorni continui. Gli account dell’organizzazione erano esenti.
L’11 dicembre 2024 il minimo è sceso da 20 a 12, con la durata di 14 giorni invariata. Gli account dell’organizzazione restano esenti.
Qualsiasi guida che dica ancora di reclutare 20 tester è obsoleta. Abbiamo coperto il cambio in dettaglio in cosa è cambiato da 20 a 12 tester.
Cambiamenti di policy del 2026 che devi conoscere
Il test chiuso non esiste nel vuoto. Alcune scadenze del 2026 possono incrociare il tuo calendario di lancio: nessuna cambia come funziona l’orologio di 14 giorni, ma possono collidere con la finestra se non guardi il calendario:
Scadenze 2026 che incrociano il tuo calendario
Date secondo l’aiuto di Google Play Console (target API level) e l’Android Developers Blog (developer verification). I tempi della verifica sono a fasi e possono espandersi nel 2026-2027, quindi conferma sulle pagine ufficiali prima di pianificare su di esse. La nostra guida ai requisiti di pubblicazione 2026 segue l’elenco completo.
Come PrimeTestLab mantiene l’orologio in corsa
La parte più difficile del test chiuso non è capire le regole; è tenere 12 o più persone reali attivate e con engagement per 14 giorni di fila mentre tu iteri. È esattamente per questo che esiste PrimeTestLab. Forniamo tester su dispositivi reali, che attivano il test, e guidiamo la configurazione in Play Console così l’orologio parte pulito e avanza mentre invii correzioni. Vedi il servizio di test chiuso di Google Play completo. Manteniamo un tasso di successo del 99,9% su oltre 12.100 app, con test live in 4-6 ore.
Aggiungi i nostri tester in Play Console, condividi l’URL del test e i 14 giorni iniziano. Da lì puoi pubblicare aggiornamenti quando ti serve; i tester restano attivati mentre iteri.
Un piano sopra il minimo di 12 tester ti dà tester extra che iniziano lo stesso giorno, così una sola uscita, anche se causata da una build difettosa, non ti lascia sotto i 12. Un buffer aiuta solo se quei tester attivano il test presto: un sostituto tardivo inizia i propri 14 giorni. I prezzi sono per app, più il 5% di commissione di servizio (minimo $1.50) al checkout.
Domande frequenti
Posso aggiornare l’app nel test chiuso senza riavviare i 14 giorni?
Sì. Un aggiornamento ordinario della stessa app sul suo canale chiuso in corso non fa ripartire di per sé il tempo di attivazione dei tester. Mantieni i tester esistenti idonei e attivati. La nuova build potrebbe comunque richiedere revisione e pubblicazione prima che i tester possano installarla, quindi verifica la consegna separatamente dal requisito di test.
Qual è l’unica cosa che azzera l’orologio del test chiuso?
Google non pubblica una checklist degli azzeramenti che copra ogni azione nella Console. Il requisito riguarda l’attivazione continua di ciascun tester. Un tester che esce e rientra ricomincia i propri 14 giorni, e perdere abbastanza tester validi può ritardare la tua richiesta. Un nuovo sostituto parte dal primo giorno. Un normale aggiornamento della build è un evento diverso.
Qual è la differenza tra tester invitati e attivati?
Invitato significa che l’account è nel tuo elenco di tester o nel tuo Google Group. Attivato significa che il tester ha aperto il link del test con quell’account e ha attivato il test. Inserire solo un indirizzo non completa l’iscrizione. Chiedi ai tester di confermare l’account, poi di installare, usare l’app e inviare feedback significativi.
I tester devono attivare di nuovo dopo un update?
Di norma no. I tester esistenti e idonei ricevono un aggiornamento ordinario tramite Google Play senza partecipare di nuovo allo stesso test. Mantieni intatta la loro iscrizione, poi chiedi loro di controllare la scheda e la build installata. L’installazione automatica dipende dalla disponibilità della release e dalle impostazioni del dispositivo, quindi non promettere a ogni tester l’aggiornamento entro pochi minuti.
Disinstallare è uguale a uscire dal test?
No. Disinstallare rimuove l’app da un telefono; disattivare il test cambia la partecipazione al test. Né il numero di installazioni di oggi né l’elenco degli invitati di oggi dimostra un’iscrizione continua. Un tester che ha disinstallato non può nemmeno testare quell’installazione, quindi verifica che sia ancora nel test e chiedigli di reinstallare l’app e continuare a testare.
Google vuole che invii update durante il test?
Google raccomanda di agire in base ai feedback dei tester e di correggere i problemi, e la richiesta di accesso in produzione chiede cosa hai cambiato dopo il test. Non pubblica un numero obbligatorio di release. Pubblica correzioni utili quando ti servono, registra cosa è cambiato e testale di nuovo. Non pubblicare release solo estetiche per soddisfare una presunta regola dei due o tre aggiornamenti.
Di quanti tester ho davvero bisogno nel test chiuso?
Per gli account personali creati dopo il 13 novembre 2023, il minimo è di 12 tester che siano rimasti attivati ciascuno negli ultimi 14 giorni consecutivi al momento della richiesta. Reclutare presto tester extra ti dà un buffer. I sostituti aggiunti tardi non ereditano i giorni dei tester usciti, e nessun numero di tester garantisce l’accesso in produzione.
Devo pubblicare due o tre aggiornamenti per superare il test?
Le indicazioni pubblicate da Google non fissano questa quota. Le domande riguardano il test, i feedback, le modifiche e la preparazione dell’app. Se il test trova un problema reale, correggilo e registra il nuovo test. Se non lo trova, descrivi il test con onestà. Un numero di release da solo non dimostra che il test sia stato utile né garantisce che l’accesso in produzione venga concesso.
La mia release è disponibile, allora perché il mio tester ha ancora la vecchia versione?
Controlla l’account Google del tester, la sua iscrizione al canale, la percentuale di implementazione e il versionCode. Poi chiedigli di aprire la scheda Play e verificare se compare Aggiorna. L’aggiornamento automatico può essere disattivato o rimandato dalle condizioni del dispositivo. Verifica che la build sia stata davvero installata; la data di aggiornamento nella scheda non basta.
Lo stato “In revisione” mette in pausa il mio test di 14 giorni?
Un aggiornamento in revisione è in attesa che Google elabori quella build. Google non indica da nessuna parte che la revisione di un aggiornamento ordinario metta in pausa il tempo di attivazione già maturato dai tuoi tester. Verifica che il test in corso sia ancora disponibile e che l’iscrizione sia intatta. Un altro invio può ritardare la revisione della release, che è una cosa separata dal requisito di test continuo.
I tester devono uscire e rientrare per ricevere l’aggiornamento?
No. Uscire dal test chiuso e rientrare non risolve un problema di aggiornamento, e interrompe i giorni di attivazione consecutivi di quel tester. Prima controlla la pubblicazione, l’account del tester, l’implementazione e il versionCode, poi prova il normale percorso di aggiornamento del Play Store. Correggi a parte un’iscrizione davvero sbagliata, sapendo che effetto ha sui 14 giorni di quel tester.
Conclusione
Riepilogo
Aggiornare l’app durante il test chiuso di 14 giorni è sicuro, normale e incoraggiato. Google misura l’attivazione senza interruzioni di ogni tester, quindi un aggiornamento ordinario sullo stesso canale chiuso non fa ripartire i 14 giorni dei tuoi tester. I rischi reali sono perdere tester validi, tester che escono formalmente dal test o pubblicare una build così difettosa che i tester abbandonano. Pubblica correzioni reali, agisci in base ai feedback e proteggi il numero di tester con un buffer reclutato presto. Se vuoi aiuto per mantenere attivati 12 o più tester, PrimeTestLab fornisce da 12 a 25 tester reali a partire da $19.99 più il 5% di commissione di servizio (minimo $1.50), con il test attivo in 4-6 ore. Se l’accesso in produzione non viene concesso dopo il test completo, scegli tu: nuovo test gratuito o rimborso completo. Vedi i piani e i prezzi →