Risposta rapida
«More testing required» è l’esito di una richiesta di accesso alla produzione, non un provvedimento contro la tua app per violazione delle norme. Google esamina il test chiuso che hai svolto e le risposte che hai dato, poi scrive al proprietario dell’account. Se la revisione non è soddisfatta, ti viene chiesto di continuare a testare. Comincia confermando quale decisione hai ricevuto, poi che cosa dimostrano i tuoi registri su idoneità, uso dell’app, feedback e prontezza.
Se invece l’app o la versione è stata rifiutata per un problema specificato, segui le istruzioni di correzione e di nuovo invio previste per quel problema. Aumentare i tester non risolve una decisione sulle norme.
Questo articolo è la diagnosi: quale decisione hai ricevuto, che cosa ogni elemento di prova può e non può dimostrare e che cosa correggere prima di richiedere di nuovo l’accesso. Si basa sui test chiusi che PrimeTestLab gestisce ogni settimana e sulle linee guida di Google, richiamate nel punto in cui servono. Aggiornato all’11 settembre 2026.
Come leggere questo articolo
- Requisito di Google Una condizione obbligatoria di idoneità, di invio o di conformità alle norme.
- Consiglio di Google Google lo raccomanda, oppure la richiesta lo chiede. Non è pubblicata alcuna soglia.
- Nostro suggerimento Una prassi che viene dai test che gestiamo, non una regola su cui vieni valutato.
In questa pagina
Per prima cosa, individua che cosa ha rifiutato Google
Tre decisioni diverse vengono tutte chiamate «test chiuso rifiutato», ma richiedono interventi diversi. Fai riferimento al testo che hai ricevuto davvero.
Quale messaggio hai ricevuto?
| Cosa hai ricevuto | Cosa significa | Cosa fare adesso |
|---|---|---|
| La Dashboard indica che l’idoneità ai test è incompleta | La Dashboard segnala una condizione di test non soddisfatta. Controlla la condizione specifica indicata prima di decidere che cosa deve proseguire. | Completa il test chiuso: almeno 12 tester, ciascuno attivato per gli ultimi 14 giorni consecutivi. |
| «More testing required» dopo la richiesta | La tua richiesta è stata esaminata e non è ancora stata approvata. Google ti chiede di continuare a testare; la decisione e l’email al proprietario dell’account riportano i dubbi che sono stati rilevati. | Passa in rassegna le cinque aree qui sotto, correggi quello che trovi e poi invia una nuova richiesta dal tuo account. |
| App o versione rifiutata per un problema specificato | Una decisione sull’app in sé, che indica un problema di norme o di qualità. Non è un giudizio sul numero dei tuoi tester. | Segui le istruzioni di correzione e di nuovo invio previste per il problema indicato. Aumentare i tester non lo risolve. |
Un canale Production bloccato, da solo, non ti dice se quello che manca è l’idoneità ai test, una decisione sulla richiesta o un altro passaggio dell’account. Orientati con il messaggio specifico che hai ricevuto, non con il blocco.
Fonti: requisiti di test delle app e accesso alla produzione, e pubblicazione e stato della revisione.
Verifica che il requisito valga per te
Requisito di GoogleIl requisito riguarda gli account sviluppatore personali creati dopo il 13 novembre 2023. Google indica che questi account devono soddisfare requisiti di test specifici prima che un’app possa essere pubblicata. Se il tuo rientra tra questi, succedono tre cose in quest’ordine:
- 1Esegui un test chiuso, non soltanto un test interno.
- 2Mantieni almeno 12 tester attivati per 14 giorni consecutivi.
- 3Richiedi l’accesso alla produzione e rispondi alle domande sul test, sull’app e sulla prontezza.
Idoneità non significa approvazione
Soddisfare il requisito ti rende idoneo a presentare la richiesta. La richiesta viene poi esaminata a sé, quindi 14 giorni in regola sono l’inizio del processo, non la fine. Tutti i dettagli: come funziona il requisito dei tester.
Diagnostica il problema in cinque minuti
Apri Play Console accanto a questo elenco e rispondi con sincerità a ogni domanda. Tutto ciò a cui non sai rispondere è il punto da cui iniziare a leggere.
Che cosa fa e che cosa non fa
Questo strumento non legge nulla dal tuo account Play Console e non può confermare il numero dei tester né le date di attivazione. Mette soltanto quello che già sai nell’ordine in cui la revisione lo chiede.
Prossimo passo
Usa la guida alla nuova richiesta per i passaggi successivi a una decisione che richiede altri test. Se la tua diagnosi mostra che ti servono più test con persone reali, confronta le opzioni di supporto al test. Se Google ha indicato un problema dell’app o di policy, risolvilo prima; un altro gruppo di tester non lo risolverà.
Cinque aree da controllare dopo un rifiuto dell’accesso alla produzione
Aree da indagare, nell’ordine in cui puoi indagarle. Non sono ordinate in base alla frequenza con cui causano un rifiuto, perché nessun dato pubblicato stabilisce quell’ordine.
Idoneità o continuità dei tester incompleta
Google chiede un minimo di 12 tester attivati per almeno gli ultimi 14 giorni consecutivi. La continuità vale per singolo tester: chi attiva il test, prova per meno di 14 giorni e poi disattiva non conta per quel periodo interrotto. Un tester che rientra può tornare idoneo dopo un nuovo periodo di attivazione ininterrotto di 14 giorni.
Che cosa controllare
- Conferma di essere sul canale chiuso. Un tester ancora iscritto a un test interno deve abbandonarlo prima che il tuo test chiuso lo raggiunga.
- Conta le persone che hanno attivato il test, non gli indirizzi che hai aggiunto a un elenco. Aggiungere un indirizzo non produce nulla finché quella persona non accetta il link.
- Chiedi ai tester di restare attivati fino al momento in cui richiedi l’accesso alla produzione, non solo per i 14 giorni che lo precedono.
Esempio: la continuità vale per singolo tester
Se 15 tester sono entrati insieme e uno se ne va, i 14 rimasti possono comunque essere idonei, perché ciascuno ha mantenuto il proprio periodo ininterrotto. Un sostituto che entra più tardi fa partire il proprio conteggio e non eredita il tempo già trascorso del tester uscito.
Tieni un piccolo margine sopra il minimo. Esattamente 12 tester sono sufficienti, quindi il margine è una nostra prassi per assorbire una disattivazione senza scendere sotto la soglia, non qualcosa che Google chiede.
Fonti: requisiti di test delle app per i nuovi account sviluppatore personali, e configurare un test aperto, chiuso o interno per gli elenchi di tester e i link di attivazione. Guide pratiche: controllare gli inviti ai tester e l’attivazione, e test interno o test chiuso.
I tester non hanno usato l’app in modo significativo
La richiesta chiede se i tester hanno usato le funzionalità e se l’utilizzo somigliava a quello che ti aspetti in produzione. Google dice anche che ti può essere chiesto di continuare a testare quando i tester non sono stati coinvolti. Le linee guida esaminate non indicano una soglia numerica di coinvolgimento, quindi il lavoro consiste nel descrivere un uso reale.
Tre numeri che non sono lo stesso numero
| Metrica | Che cosa conta | Che cosa dimostra questa metrica |
|---|---|---|
| Tester attivati | Le persone che hanno accettato il link di attivazione del tuo canale chiuso e sono rimaste attivate. | È il numero dell’idoneità, e l’unico dei tre legato alla regola dei 12 tester e dei 14 giorni. |
| Pubblico installato | Gli utenti che hanno la tua app installata su almeno un dispositivo che hanno usato nei 30 giorni precedenti. | L’app è arrivata su un dispositivo in uso. Non dimostra che qualcuno l’abbia aperta. |
| Utenti attivi giornalieri | Le persone che hanno aperto l’app in un dato giorno. | Ci sono state delle aperture. Non dice comunque quali funzionalità siano state usate, né che cosa ne abbiano pensato i tester. |
Fonte: visualizzare le statistiche dell’app. Google dispone dei dati di utilizzo, quindi il coinvolgimento non è invisibile per Google. Quello che non è documentato è quali segnali pesi la revisione, e a quale livello.
Che cosa controllare
- Dai ai tester istruzioni brevi che indichino i flussi da provare, e un solo canale su cui rispondere.
- Chiedi osservazioni specifiche, non un verdetto: che cosa hanno provato, su quale dispositivo, che cosa è successo.
- Chiedi ai tester di riprovare una correzione importante quando viene rilasciata, così il registro mostra una modifica che viene verificata.
Chiedi ai tester di completare le attività che contano per la tua app, di riferire con parole loro quello che vedono e di riprovare le correzioni importanti dopo il rilascio. Un’istruzione fissa come «apri l’app una volta al giorno» è una routine di test facoltativa, non una regola di Google.
Il feedback e le risposte nella richiesta non portano prove specifiche
La richiesta ti chiede di riassumere il feedback che hai ricevuto e le modifiche che hai fatto. Google raccomanda di annotare i temi ricorrenti del feedback man mano, e quel registro è la differenza tra una risposta specifica e una generica.
Registro di test di esempio (la struttura, non contenuti da copiare)
| Build, flusso, ambiente | Rilievo | Intervento o verifica |
|---|---|---|
| Build 8; reimpostazione della password; Android 14 | Il messaggio di nuovo tentativo non era chiaro | Chiarito nella Build 9; il tester ha verificato di nuovo |
| Build 9; impostazioni salvate; Android 13 | Le impostazioni sono rimaste dopo la riapertura | Registrato come superato; nessuna modifica necessaria |
Questo è un formato di registro suggerito, non un modello o un allegato richiesto da Google. Usa le colonne come struttura, mai le righe come fatti da incollare. Annotare una verifica riuscita conta quanto annotare un difetto: è ciò che ti permette di rispondere alla domanda sulla prontezza senza inventarti un problema.
Che cosa controllare
- Usa la sezione del feedback di test in Play Console, più qualsiasi canale che hai dato ai tester. Le valutazioni pubbliche sullo store non rientrano qui.
- Raggruppa prima il feedback per temi, così una sola segnalazione rumorosa non diventa l’intero riepilogo.
- Conserva l’osservazione specifica, sia che tu citi il tester sia che la riassuma in modo fedele.
- Verifica che le funzionalità che descrivi nella richiesta fossero presenti nella build testata e siano state davvero provate. Segnala tutto ciò che è stato testato separatamente o lasciato fuori da questo test.
Fonti: configurare un test aperto, chiuso o interno e indicazioni sull’accesso alla produzione. Un modello di registro riutilizzabile è nel nostro articolo sul recupero, e preparare risposte accurate per l’accesso alla produzione analizza il modulo stesso.
I rilievi non sono stati affrontati o la prontezza non è chiara
La richiesta chiede che cosa hai cambiato in base a quello che hai imparato, e Google raccomanda di agire sul feedback durante il test. Nelle linee guida esaminate non compare alcun numero minimo di versioni da pubblicare, quindi quello che conta è se la risposta rispecchia ciò che il test ha dimostrato.
Che cosa dire quando non c’era nulla da cambiare
Se il test non ha fatto emergere nulla da correggere, descrivi i flussi verificati, i dispositivi su cui sono stati provati e i risultati, poi spiega la decisione sulla prontezza a partire da quel registro. Inventare un problema, o pubblicare una versione di facciata per avere una modifica da dichiarare, rende la risposta più debole.
Che cosa controllare
- Affronta prima i rilievi reali, e indica quale build ha portato ciascuna correzione.
- Collega ogni modifica al feedback che l’ha motivata, così la risposta si legge come causa ed effetto.
- Se un problema importante è ancora aperto, risolvilo prima di presentare l’app come pronta.
Dove questa risposta sbaglia
La risposta debole dice che il test è andato bene. La risposta forte indica che cosa è stato controllato, che cosa è emerso, che cosa è stato fatto e come è stato verificato. La risposta specifica è più facile da valutare.
Restano problemi di accesso, stabilità o funzionalità
Google non consente app che si arrestano in modo anomalo, si bloccano o comunque non funzionano normalmente. Anche la revisione deve poter raggiungere l’app: dove qualcosa è protetto da un accesso, credenziali funzionanti e istruzioni vanno fornite insieme alla versione.
Che cosa controllare
- Fornisci credenziali di accesso funzionanti per la revisione, e tutti i passaggi necessari per raggiungere le funzionalità ad accesso riservato, riferiti alla build che hai inviato.
- Conferma che i tester riescano a installare e ad aprire quella build. Chi è ancora in un test interno deve prima abbandonarlo.
- Esegui un rapporto pre-lancio, poi controlla i segnali di arresti anomali e ANR per i flussi usati dai tuoi tester, e correggi ciò che è riproducibile.
Che cosa non dimostra un rapporto pulito
I rapporti pre-lancio vengono eseguiti automaticamente quando la capacità lo consente. Per raggiungere i contenuti protetti e provare i flussi rilevanti possono servire credenziali o una configurazione personalizzata. Un risultato automatico pulito, inoltre, non è un test manuale. Android vitals si basa sui dati diagnostici di chi ha acconsentito a condividerli, raccolti su un sottoinsieme di dispositivi e di versioni del sistema operativo, quindi una vista non disponibile può riflettere un numero insufficiente di dati all’interno dei filtri che hai selezionato. Le sue soglie pubblicate di comportamento anomalo riguardano la qualità tecnica, non una soglia di superamento per l’accesso alla produzione.
Fonti: funzionalità, contenuti ed esperienza utente, preparare l’app per la revisione, usare un rapporto pre-lancio per individuare i problemi e monitorare la qualità tecnica con Android vitals.
Che cosa può e non può dimostrare ogni elemento di prova
Sapere a quale domanda risponde ciascun elemento è ciò che distingue un problema di tester da un problema di prove o da un problema dell’app.
Risponde aSe eri idoneo a presentare la richiesta: almeno 12 tester, ciascuno attivato per gli ultimi 14 giorni consecutivi.
Non risponde aSe qualcuno di loro abbia usato l’app, o se le tue risposte siano state abbastanza specifiche.
Risponde aQuanti utenti hanno aperto l’app in ciascun giorno mostrato.
Non risponde aQuante volte ciascuna persona l’ha aperta, quali funzionalità ha usato o che cosa ha pensato dell’esperienza.
Risponde aChe la vista selezionata non ha dati sufficienti per individuare problemi con i filtri attuali.
Non risponde aChe l’app non si sia arrestata in modo anomalo. Vitals usa i dati di chi ha acconsentito a condividerli, da un sottoinsieme di dispositivi e di versioni, quindi una vista vuota può voler dire che sono stati raccolti troppo pochi dati, non che sia andato tutto bene.
Risponde aChe un altro sviluppatore ha riportato quel testo. Vale la pena leggerlo per farsi un’idea di come è formulata la decisione.
Non risponde aChe cosa è stato comunicato al tuo account. I messaggi ricopiati nelle community sono aneddotici e non possono stabilire i tuoi tempi.
Risponde aUn’osservazione specifica su cui puoi intervenire e che puoi descrivere, con le parole del tester.
Non risponde aSe quel problema sia diffuso. Una segnalazione è una pista; il rilievo è lo schema che si ripete tra i tester.
Che cosa controllare prima di richiedere di nuovo
Consiglio di Google- 1Leggi sia la decisione in Play Console sia l’email al proprietario dell’account, e segui le istruzioni fornite per la tua app.
- 2Completa l’eventuale periodo di test aggiuntivo che è stato davvero assegnato alla tua app, e nel frattempo tieni attivo il canale chiuso.
- 3Continua a risolvere i dubbi indicati nella decisione, poi presenta una nuova richiesta seguendo le istruzioni mostrate nel tuo account.
Due conclusioni da non trarre
Una durata non indicata non è un’autorizzazione a richiedere di nuovo subito. E un’istruzione a continuare a testare non dimostra che il tempo già trascorso di ogni tester sia stato azzerato: le linee guida pubbliche esaminate non indicano una regola di azzeramento valida per tutti, quindi tratta entrambe le cose come non confermate finché non è il tuo account a dire diversamente.
Google descrive la revisione che segue come, in genere, al massimo 7 giorni, pur precisando che a volte può richiedere più tempo. Quella è la revisione, non il test che la precede. Passo per passo: come richiedere di nuovo dopo una decisione more testing required.
Fonte: i passaggi successivi per l’accesso alla produzione.
Come mantenere i tester coinvolti
Consiglio di GoogleGoogle dice che molti sviluppatori reclutano tra amici, familiari, colleghi, community e canali social, e raccomanda tester che rappresentino i tuoi utenti di riferimento, abbastanza vari da far emergere problemi legati a dispositivi specifici.
Il reclutamento può fallire quando partecipazione e feedback non vengono gestiti: un impegno di 14 giorni senza una struttura intorno compete con tutto il resto della settimana di un volontario. Tre problemi di partecipazione e di feedback a cui fare attenzione:
Dove un gruppo autogestito perde la finestra
Fonte: requisiti di test delle app, che è il punto in cui Google parla del reclutamento dei tester. Le opzioni sono messe a confronto in modi legittimi per trovare 12 tester.
Test autogestito o test gestito
Entrambe le strade soddisfano lo stesso requisito. La differenza è chi sorveglia il conteggio e rincorre il feedback per 14 giorni.
| Da che cosa dipende la richiesta | Gruppo autogestito | Test gestito |
|---|---|---|
| Mantenere 12 tester attivati per 14 giorni consecutivi | Tocca a te monitorarlo. Una disattivazione può ritardare l’idoneità se lascia troppo pochi tester idonei. | Monitorato per te, con il gruppo mantenuto sopra il minimo. |
| Dispositivi reali | Quelli che i tuoi volontari si trovano ad avere. | Dispositivi Android reali, da Android 7 ad Android 17. |
| Avvio | Il tempo che serve per reclutare. | Di solito i tester iniziano da 4 a 6 ore dopo l’ordine. |
| Feedback che puoi riassumere | Dipende interamente da come lo raccogli. | Raccolto attraverso un unico canale e riportato a te. |
| Costo | Gratis, più il tuo tempo per 14 giorni. | Da 19,99 USD per 12 tester. |
Nessuna delle due strade cambia il modo in cui la richiesta viene esaminata. Il test gestito elimina il rischio sulla partecipazione; non risponde al posto tuo alle domande su feedback e prontezza, e nessuno può promettere un’approvazione.
Supporto per i test
Nostro suggerimentoSe la tua diagnosi punta sulla partecipazione, PrimeTestLab gestisce il test chiuso per te: tester attivati su dispositivi reali per tutti i 14 giorni, mantenuti sopra il minimo, feedback in un unico posto. Se invece il problema è un accesso che non funziona o una violazione delle norme già indicata, aumentare i tester non lo risolve.
Starter
12 tester reali
$19.99
Enterprise
25 tester reali
$27.99
Professional
20 tester reali
$29.99
Quella percentuale di completamento è un nostro dato operativo, non un tasso di approvazione di Google: il test gestito ha mantenuto il numero di tester richiesto e un periodo di attivazione ininterrotto fino alla sua data di fine.
Domande e risposte
Perché Google Play mostra «More testing required»?
La tua richiesta di accesso alla produzione è stata esaminata e non è ancora stata approvata, quindi Google ti chiede di continuare a testare. Tra i suoi esempi ci sono un numero di tester attivati inferiore a 12 e tester che non sono stati coinvolti durante il test chiuso. Leggi sia la decisione in Play Console sia l’email inviata al proprietario dell’account per conoscere i dubbi rilevati.
Mi servono 12 tester attivati per 14 giorni consecutivi?
Per un account sviluppatore personale creato dopo il 13 novembre 2023, sì. Google richiede un test chiuso con un minimo di 12 tester attivati per almeno gli ultimi 14 giorni consecutivi. Esattamente 12 è sufficiente, e gli indirizzi invitati non contano finché ogni persona non attiva il test.
Un tester ha disattivato il test durante i 14 giorni. Devo ricominciare da capo?
Non necessariamente. La continuità si misura per singolo tester, quindi chi ha mantenuto il proprio periodo ininterrotto conta comunque. Il periodo interrotto in sé non conta, ma un tester che rientra può tornare idoneo dopo un nuovo periodo di attivazione ininterrotto di 14 giorni. Quello che non avviene è l’eredità: un sostituto che entra più tardi fa partire il proprio periodo invece di subentrare nel tempo già trascorso del tester uscito.
Che cosa devo rispondere se il test non ha rivelato nulla da correggere?
Descrivi i flussi che hai verificato, i dispositivi su cui sono stati provati e i risultati, poi spiega la tua decisione sulla prontezza a partire da quel registro. Nelle linee guida esaminate non compare alcun numero minimo di versioni da pubblicare, e nulla dice che devi rilasciare un aggiornamento durante il test. Inventare un problema rende soltanto la risposta più debole.
Posso richiedere di nuovo subito dopo un rifiuto?
Presenta una nuova richiesta quando la causa radice è risolta, e lascia che sia la tua prontezza a stabilire i tempi. Alcuni messaggi indicano un periodo aggiuntivo di test chiuso; altri dicono soltanto di continuare a testare e non danno alcuna durata. Una durata non indicata non è un’autorizzazione a richiedere di nuovo subito, e le linee guida pubbliche esaminate non indicano una regola di azzeramento valida per tutti.
Quanto tempo impiega Google per esaminare una richiesta di accesso alla produzione?
Google descrive la revisione come, in genere, al massimo 7 giorni, e dice che a volte può richiedere più tempo. Questo riguarda solo la revisione. Il test chiuso che la precede è un periodo separato di 14 giorni consecutivi, e l’eventuale test aggiuntivo richiesto dalla tua decisione è a sua volta separato.
Il tuo prossimo passo
Torna alla verifica di cinque minuti e prendi la prima domanda a cui non sapevi rispondere. Correggi quell’unica cosa, metti per iscritto che cosa ha dimostrato davvero il test e presenta una nuova richiesta seguendo le istruzioni nel tuo account. Se quello che manca è la partecipazione e non le prove, organizza i tester prima del tentativo successivo, così la finestra non si interrompe di nuovo a metà test.
In sintesi
«More testing required» è una decisione sul test che hai svolto, sulle risposte che hai dato e sul fatto che l’app sia pronta. La soglia minima è fissa e pubblica: almeno 12 tester attivati per 14 giorni consecutivi, per un account sviluppatore personale creato dopo il 13 novembre 2023. Al di sopra di quella soglia, le tue risposte dovrebbero spiegare con precisione che cosa ha dimostrato il test. Una formulazione chiara non può sostituire un test significativo o un’app che funziona.
Documentazione ufficiale di Google