Come ripresentare la richiesta se Google Play dice “More Testing Required”

La tabella scorre lateralmente su schermi stretti

Quella tabella deve restare condizionale perché le indicazioni pubbliche di Google sono meno specifiche dei messaggi di decisione che gli sviluppatori ricevono davvero: fare la media delle due in un’unica risposta sicura produce una pagina sbagliata per metà dei suoi lettori. Ogni affermazione qui sotto è etichettata come indicazione ufficiale, testo di decisione riprodotto, esperienza della community o deduzione operativa, e tutto è aggiornato al 17 agosto 2026.

Le cause del rifiuto restano deliberatamente fuori dall’ambito di questo articolo, che si occupa di cosa fare dopo aver ricevuto il messaggio. Per il lato diagnostico, leggi il nostro articolo su perché le richieste di accesso in produzione vengono rifiutate.

Cosa dice davvero il tuo messaggio di rifiuto

Sviluppatori nello stesso thread di un forum si contraddicono a vicenda perché stanno descrivendo messaggi genuinamente diversi. Per questo motivo questo articolo classifica le prove in tre livelli invece di fare una media:

1. Livello 1
   L’attuale Centro assistenza di Google

   L’unico livello che è testo delle norme, e il meno specifico, perché è scritto per tutti gli sviluppatori contemporaneamente.

2. Livello 2
   Un messaggio di rifiuto riportato dallo sviluppatore che lo ha ricevuto

   Direttamente utilizzabile per quell’app, ma non testo delle norme, e Google ha dimostrabilmente cambiato il testo nel tempo.

3. Livello 3
   Segnalazioni di forum e community

   Utile per mostrare che qualcosa è possibile, mai per dimostrare che sia obbligatorio.

Ecco tutto quello che il Livello 1 dice sulla tua situazione. La brevità è proprio il punto.

... may be required to continue testing your app.

Il passaggio che Google pubblica su cosa può succedere quando una richiesta di accesso in produzione non viene approvata. Guida di Google Play Console, risposta 14151465, consultata il 17 agosto 2026. Vai alla pagina di origine

Quel passaggio pubblico non menziona alcun azzeramento, nuovo conteggio, periodo di attesa o istruzione a ricostruire il gruppo di tester. Questi dettagli compaiono, quando compaiono, solo nel testo delle decisioni specifiche per account o nelle segnalazioni della community. Gli esempi che Google indica per spiegare perché un’app non è pronta sono un numero di tester inferiore al richiesto, oppure tester non coinvolti. Tutto il resto che circola su questo rifiuto è Livello 2 o Livello 3, e il decodificatore qui sotto ti dice a quale livello appartiene il tuo messaggio.

Google Play Console · email di decisione reale Clicca per ingrandire

Un limite su tutto questo: il tuo rifiuto è l’istruzione più specifica a tua disposizione, non l’unica cosa che ti separa da una seconda richiesta. Play Console continua a controllare se il pulsante per inviare la richiesta è attivo, e il tuo account deve comunque avere almeno 12 tester con una cronologia di attivazione idonea il giorno in cui lo premi. Segui qualsiasi durata indicata dal tuo messaggio, e controlla queste due cose separatamente.

E se non riesci a trovare il messaggio della decisione?

Allora la posizione onesta è che non sai quale istruzione si applichi a te, e nessuna pagina può fornirti quella mancante. La variante senza durata non è un’opzione predefinita sicura: darla per scontata quando il tuo account ha in realtà ricevuto l’altro testo significa ripresentare la richiesta prima che un periodo indicato sia terminato.

1. Cerca nell’email del titolare dell’account, inclusa la posta indesiderata e qualsiasi indirizzo diverso da quello che controlli ogni giorno, il paragrafo che inizia con "Before applying again".
2. Controlla le notifiche di Play Console e le pagine sullo stato delle norme o della pubblicazione dell’app per la decisione.
3. Controlla la tua cronologia dell’assistenza di Play Console, dove un contatto precedente sulla stessa decisione potrebbe riportarla per intero.
4. Mantieni attivo il test chiuso esistente mentre cerchi. Nulla nel cercare il messaggio richiede di mettere in pausa, svuotare o ricostruire alcunché.
5. Contatta l’assistenza di Play Console se non riesci a recuperare l’istruzione, e chiedi loro di confermare cosa è stato comunicato alla tua app. Deduzione operativa

Finché non hai il testo o una conferma, non dare per scontata alcuna durata in nessuna delle due direzioni: né altre due settimane, né nessuna.

Il test chiuso di 14 giorni riparte dopo un rifiuto?

La parola "riparte" è quella che crea confusione: viene usata per tre cose diverse, e solo la terza è una regola pubblicata.

• Un azzeramento della piattaforma. Un evento lato Google che cancella il periodo di idoneità per tutti i partecipanti al test. Nessuna fonte trovata
• Un periodo di test aggiuntivo. Un’istruzione, contenuta nel messaggio di rifiuto, a testare per un ulteriore periodo indicato prima di ripresentare la richiesta. Documentato in una famiglia di messaggi
• Una sequenza individuale interrotta. Il periodo di attivazione continuativa di un tester che termina perché si è disattivato. Meccanica pubblicata

Quella terza cosa si applica ai singoli tester, non al test nel suo complesso. Ecco l’intero insieme di prove, classificato per livello.

La tabella scorre lateralmente su schermi stretti

Queste cinque righe supportano un’unica risposta onesta, ed è condizionale: segui il testo del rifiuto che hai effettivamente ricevuto, e non trattare nessun rifiuto come prova che Google abbia azzerato formalmente un timer.

Se la tua email indica altri 14 giorni

Allora quella è la tua istruzione, e il punto più sicuro e più precoce per ripresentare la richiesta è dopo che quei 14 giorni sono davvero trascorsi per intero. Google non pubblica dove quel periodo debba essere svolto, quindi svolgerlo sul canale idoneo esistente è una deduzione operativa, non una regola di Google. Usa le due settimane invece di limitarti ad aspettarle: lo stesso messaggio che ti ha dato il numero chiede anche tester reali. Deduzione operativa

Non è una prova di un meccanismo valido per l’intera piattaforma: a uno sviluppatore è stato detto di fare altri 14 giorni, e questa è tutta l’affermazione. Il normale abbandono può comunque costarti il gruppo, quindi controlla chi è attualmente attivato prima di dare per scontato che i 12 siano intatti.

Se la tua email dice solo di continuare a testare

Allora non ti è stata indicata alcuna durata, e il Centro assistenza di Google non pubblica alcun periodo di attesa numerico per colmare il vuoto. Non inventarne uno, e attento anche all’errore opposto, perché "continue testing" non è un via libera a ripresentare la richiesta lo stesso pomeriggio. Mantieni attivo il test idoneo e invia la richiesta quando due condizioni sono vere: Play Console te lo permette, e puoi migliorare in modo sostanziale le tue risposte sulla prontezza. Se il tuo rifiuto indicava il coinvolgimento o il numero di tester, sono quelle le cose da descrivere in modo diverso.

Devi mantenere lo stesso test chiuso o crearne uno nuovo?

Questa è la domanda più ripetuta nei thread della community dietro questo articolo, e la paura che la accompagna è ragionevole: che scegliere male sprechi altre due settimane. Quello che non si sa è cosa farebbe Google se davvero iniziassi un nuovo canale, perché non ha mai pubblicato nulla in un senso o nell’altro. Data una raccomandazione documentata e un silenzio, il percorso a minor rischio è quello documentato.

Play Console · Test and release · screenshot reale Clicca per ingrandire

Il percorso nella console per controllare tutto questo non è cambiato: Testing Closed testing Manage track Testers

Gli stessi tester contano ancora?

La regola rigida. Ogni tester conteggiato ai fini dell’idoneità ha bisogno di una cronologia di attivazione continuativa idonea, attualmente almeno gli ultimi 14 giorni senza interruzioni. Questo è pubblicato, ed è misurato per singola persona, non come un unico timer globale per il test.

Play Console · Closed testing · Testers tab Clicca per ingrandire

L’incertezza. Google non pubblica alcuna regola che dica che uno sviluppatore rifiutato debba sostituire i propri tester. Un utente di r/androiddev racconta di aver ottenuto l’approvazione al quarto tentativo senza aggiungere alcun nuovo tester, il che va contro l’idea di presentare la sostituzione come obbligatoria. È un singolo aneddoto e non può dimostrare che gli stessi tester funzionino sempre, ma è più di quanto esista sul lato opposto, dove non c’è nulla.

Devi chiedere ai tester di disattivare e riattivare il test?

No. Questo è l’errore più concreto che questo articolo può aiutarti a evitare, ed è diffuso proprio perché dà la sensazione di fare qualcosa.

Disattivarsi pone fine al periodo continuativo di quella persona. Non esiste alcun azzeramento documentato che uscire e rientrare attivi, quindi la tattica distrugge una cronologia di idoneità reale senza ottenere nulla in cambio, e lo fa a ogni tester che collabora, tutti insieme. Uno sviluppatore che applica questo a un intero gruppo trasforma un gruppo che era idoneo ieri in un gruppo che sarà idoneo tra due settimane.

Lo stesso ragionamento vale per la versione più morbida dell’idea, cioè rimuovere i tester che sembrano inattivi così che l’elenco "riparta pulito". Se dopo questo sei sotto i 12, hai peggiorato il problema di idoneità invece di migliorarlo, e il nostro articolo su cosa fare quando meno di 12 tester sono ancora idonei tratta come procedere da lì. Se hai bisogno di ricostruire il gruppo invece di ripararlo, il nostro articolo su modi per reclutare 12 tester affidabili è il compagno pratico.

Cosa dovrebbe cambiare prima di ripresentare la richiesta?

Nota cosa manca in questo elenco: una causa del tuo rifiuto. Google non pubblica un modello di punteggio, e nessuna pagina può dirti quale risposta abbia fatto pendere la decisione. Quello che può dirti è quali argomenti il revisore stia effettivamente guardando, il che è un uso migliore di due settimane rispetto all’indovinare. Per la domanda più ampia sul perché le app falliscano del tutto in questa fase, il nostro articolo su perché il test chiuso viene rifiutato ne tratta le cause; questa sezione resta sul recupero.

Mantieni almeno 12 tester attivati in modo continuativo

Questa è l’unica soglia rigida in tutto il processo, ed è utile leggerla nelle parole originali di Google piuttosto che nella parafrasi di chiunque altro.

Se hai un account sviluppatore personale creato di recente, devi eseguire un test chiuso per la tua app con un minimo di 12 tester che sono stati attivati continuamente per almeno gli ultimi 14 giorni.

Guida di Google Play Console, risposta 14151465. Si applica agli account sviluppatore personali creati dopo il 13 novembre 2023. Google ha ridotto il requisito da 20 a 12 tester l’11 dicembre 2024. Vai alla pagina di origine

Tre cose in questa frase vengono lette male sistematicamente. È un minimo, non un obiettivo, e nulla di pubblicato dice che un numero più alto funzioni meglio. È continuo, misurato per singolo tester, quindi se una persona se ne va interrompe solo la propria idoneità, non quella di tutti. E specifica un test chiuso, motivo per cui il test interno non lo soddisfa, indipendentemente da quanti dei suoi 100 posti riempi. Se stai valutando i canali, il nostro articolo su test interno, chiuso e aperto a confronto spiega a cosa serve ciascuno.

Se il tuo gruppo è sceso sotto la soglia dopo il rifiuto, è la prima cosa da sistemare, e richiede tempo di calendario: un tester sostitutivo ha bisogno dei propri 14 giorni continuativi prima di contare. Reclutare al giorno 10 di un piano costruito intorno al giorno 14 è il motivo per cui capita di ricevere un secondo rifiuto.

Dai ai tester cose specifiche da testare

La raccomandazione di Google è concreta: dai ai tester istruzioni chiare, di’ loro che tipo di feedback vuoi, e incoraggiali a usare quante più funzionalità possibili dell’app. È un compito molto diverso da "per favore tienila installata", che è quello che alla maggior parte dei gruppi di 12 tester viene effettivamente chiesto di fare.

È anche la raccomandazione con il divario più ampio tra quello che dice Google e quello che dice internet. Quello che il modulo per l’accesso in produzione chiede realmente è se i tester hanno usato le funzionalità dell’app, e se il loro utilizzo ha rispecchiato il modo in cui ti aspetti che si comportino gli utenti reali. Sono domande a cui si può rispondere sulla copertura, non sulla cadenza.

• Indica le funzionalità. Due o tre tra le più importanti, per nome, così una risposta sulla copertura sarà poi una descrizione e non un’affermazione generica.
• Indica i flussi. Registrarsi, creare qualcosa, modificarlo, condividerlo o esportarlo, tornare il giorno dopo e trovarlo ancora lì.
• Indica cosa vuoi come riscontro. Dove si sono bloccati, cosa si aspettavano che succedesse, cosa non userebbero più.
• Distribuisci i dispositivi che hai già. Sono consigliati dispositivi reali rappresentativi; non è pubblicata alcuna soglia numerica di modelli di dispositivo.

Registra il feedback e apporta miglioramenti motivati

Google consiglia di rispondere al feedback dei tester e di correggere i bug che il test individua, e dice che farlo può migliorare la probabilità di una richiesta di accesso in produzione riuscita. Questa è una prova molto più solida di qualsiasi ricetta della community su quante release pubblicare, ed è l’unico punto in cui "fare di più" è davvero supportato.

Play Console · Ratings and reviews · Testing feedback Clicca per ingrandire

Nella pratica, questo si traduce in un registro. Ti verrà chiesto di riassumere il feedback ricevuto e cosa è cambiato di conseguenza, e ricostruire tutto questo a memoria due settimane dopo è il punto in cui buoni test producono richieste deboli. Tieni qualcosa di simile, una riga per ogni elemento.

Modello vuoto. La tabella scorre lateralmente su schermi stretti

La riga "nessuna modifica e perché" conta quanto le correzioni. Una risposta sulla prontezza per la produzione che indica quali problemi noti restano e perché non impediscono il lancio è una risposta più solida di una che lascia intendere che tutto fosse perfetto. E il canale attraverso cui è arrivato il feedback è una tua scelta: email, un sito web o un forum, oppure il feedback privato che i tester possono inviare tramite Google Play, che si trova sotto Monitor and improve Ratings and reviews Testing feedback

Sugli aggiornamenti: pubblicane uno quando il test lo giustifica. Google incoraggia a correggere quello che il test rivela, e aggiornare la build durante un test chiuso non interrompe il requisito sui tester, argomento che il nostro articolo su se aggiornare l’app azzera il test chiuso tratta nel dettaglio. Quello che non è pubblicato da nessuna parte è un numero obbligatorio di release, quindi pubblicare build solo per raggiungere un numero è impegno speso su un numero che nessuno ha stabilito.

Controlla il rapporto pre-lancio

Google rimanda gli sviluppatori al rapporto pre-lancio per indagare su problemi, avvisi ed errori prima del rilascio. Leggilo prima della seconda richiesta, e considera quello che segnala come lavoro da fare, non come una diagnosi: nulla di pubblicato dice che un determinato avviso abbia causato un rifiuto dell’accesso in produzione, e nulla dice che tutti gli avvisi debbano essere risolti prima. È una fonte di problemi reali che puoi correggere mentre stai già correggendo altre cose.

Controlla la conformità alle norme, l’affidabilità dell’app e le credenziali del revisore

L’attività di test non è tutto ciò che Google ti chiede di confermare prima di inviare la richiesta. Le sue linee guida attuali indicano quattro aree di prontezza accanto al test chiuso, e due settimane spese solo sul coinvolgimento dei tester possono comunque incontrare una decisione su una di queste invece.

Come ripresentare la richiesta di accesso in produzione

Non esiste un flusso di ripresentazione della richiesta documentato separatamente, nessun modulo diverso, e nessuna coda pubblicata per i tentativi successivi. Ciò che cambia è quello che porti tu.

La tabella scorre lateralmente su schermi stretti

Cosa dire su coinvolgimento, feedback e prontezza

Coinvolgimento. Google chiede se i tester hanno usato le funzionalità dell’app e se il loro utilizzo ha rispecchiato quello che ti aspetti in produzione, quindi la risposta più solida è descrittiva e specifica: quali funzionalità, indicate per nome, e cosa hanno effettivamente fatto i tester con esse. Se un uso entusiasta non corrisponde al tuo test, di’ quello che è vero. Una risposta che descrive un uso modesto ma genuino è difendibile; una che descrive un’attività che non puoi dimostrare è qualcosa che poi devi mantenere coerente in ogni richiesta successiva.

Feedback. Riassumi i temi invece di trascrivere i messaggi, e indica il canale di raccolta. Email, un sito web o un forum, e il feedback privato di Play contano tutti, quindi non esiste un canale sbagliato da aver usato, solo una domanda a cui non puoi rispondere se non hai raccolto proprio nulla.

Modifiche e prontezza. Collega ogni modifica significativa a un riscontro specifico del test, poi spiega perché i problemi rimasti non impediscono il lancio. Queste sono le due risposte in cui due settimane documentate superano visibilmente due settimane non documentate. Per la trattazione completa di come scrivere ciascuna risposta, leggi il nostro articolo su le risposte al questionario per l’accesso in produzione.

Cosa fare se Apply for production è ancora disattivato?

Un pulsante Apply for production disattivato o mancante di solito significa che una condizione di idoneità o di configurazione dell’app non è ancora soddisfatta. Sono possibili anche ritardi della console e problemi specifici dell’account, quindi verifica le condizioni documentate di seguito prima di concludere che l’interfaccia sta malfunzionando.

• Il numero non c’è ancora. L’account potrebbe non avere attualmente 12 tester con i richiesti 14 giorni precedenti di attivazione continuativa, qualunque cosa dica il totale nella lista degli inviti.
• Invitato non significa attivato. Le persone che hanno ricevuto un link e non lo hanno mai accettato non sono tester ai fini di questo requisito. Controlla chi è effettivamente attivato, non chi è stato invitato.
• I sostituti stanno ancora accumulando giorni. Chi viene aggiunto dopo il rifiuto inizia i propri 14 giorni continuativi dal momento in cui si attiva, quindi un gruppo rimpolpato può contare dodici persone ed essere comunque non idoneo per altre due settimane.
• La configurazione dell’app è incompleta. Scheda del negozio, classificazione dei contenuti, accesso all’app o dichiarazioni sulle norme ancora in sospeso possono bloccare la richiesta indipendentemente dal numero di tester.
• Conta solo un test chiuso. Il test interno non soddisfa questo requisito, indipendentemente da quanti posti siano occupati.

Play Console · Dashboard · screenshot reale Clicca per ingrandire

Se nella tua console tutte queste condizioni sembrano soddisfatte e il pulsante continua a non comparire, è una delle situazioni che vale la pena segnalare all’assistenza di Play Console invece di aspettare, perché non stai più risolvendo qualcosa che la documentazione pubblica descrive.

Una riga su cosa stai effettivamente richiedendo, perché è facile perderlo di vista al secondo tentativo: l’approvazione sblocca le release di produzione per l’app, e sblocca anche il test aperto, quindi anche chi voleva solo una beta più ampia e non un lancio sullo store sta aspettando la stessa decisione. Tutto quello che viene dopo è normale gestione delle release, non una continuazione di questo processo.

Servono aperture giornaliere, più tester o più aggiornamenti?

È qui che si fa la maggior parte del danno. Uno sviluppatore rifiutato cerca cosa è andato storto, trova una pagina che dice che i tester devono aprire l’app ogni giorno e che devi pubblicare tre release, e passa le due settimane a inseguire un obiettivo che Google non ha mai fissato, mentre la cosa che Google chiede davvero, se i tester hanno usato l’app in modo significativo e cosa hai fatto con quello che ti hanno detto, resta senza risposta. Vale la pena dirlo chiaramente: le linee guida pubbliche di Google sull’accesso in produzione non prevedono alcuna soglia numerica di coinvolgimento né alcuna griglia di valutazione pubblicata. Le domande del modulo sono elementi di valutazione, non una griglia con pesi, e nessuna dashboard pubblicata converte l’attività dei tuoi tester in un punteggio leggibile. Quindi la mossa utile non è indovinare il numero, ma sapere quali delle cose che ti hanno detto sono davvero pubblicate.

La tabella scorre lateralmente su schermi stretti

Due di questi meritano una frase in più, perché sono quelli che costano soldi veri. Comprare un gruppo di tester più grande è una scelta operativa ragionevole, dato che un gruppo di 12 non ha margine se una persona se ne va, ma nessuno può onestamente venderti questo come una probabilità di approvazione più alta, e le segnalazioni della community includono rifiuti con più di 30 tester e con 19 tester più 17 aggiornamenti. E inseguire una quota di modelli di dispositivo distoglie impegno da ciò che Google chiede davvero nel modulo: non è pubblicata alcuna soglia numerica di dispositivi, e i tester rappresentativi su dispositivi reali sono una raccomandazione, non una formula. Se vuoi i dettagli su cosa conta come partecipante valido a un test chiuso, il nostro articolo su emulatori nel test chiuso di Google Play tratta correttamente il lato dei dispositivi.

Quante volte puoi ripresentare la richiesta?

Questo è quasi tutto l’insieme delle prove pubbliche disponibili, ed è utile vedere quanto sia esiguo prima che qualcuno ti citi un numero. Singoli sviluppatori su forum pubblici raccontano di un’approvazione al quarto tentativo senza aggiungere nuovi tester, un rifiuto al circa sesto tentativo nonostante 19 tester e 17 aggiornamenti, un secondo rifiuto con un gruppo ben oltre il minimo, e un altro secondo rifiuto dopo altre due settimane intere con gli stessi tester e correzioni già pubblicate. Ti dicono che quei tentativi sono avvenuti. Non possono dirti perché ciascuno sia andato come è andato. Riportato dalla community

Ne derivano due conclusioni, e solo due. Primo, non esiste un limite basso evidente: richieste oltre la seconda e la terza esistono, dimostrabilmente. Secondo, e più utile, fare di più della stessa cosa non è una strategia. La maggior parte di quelle segnalazioni descrive sviluppatori che hanno aggiunto tester, aggiornamenti o tempo e sono comunque stati rifiutati. Se la tua seconda richiesta è la prima più due settimane, stai riproducendo l’ultima di quelle segnalazioni.

Sulla paura che si nasconde dietro la domanda: le linee guida pubbliche di Google non classificano una decisione sulla prontezza "more testing required" come una violazione delle norme, e non è stata trovata alcuna prova che decisioni ripetute sulla prontezza portino da sole alla sospensione dell’account. Un problema di norme distinto può comunque coesistere (l’applicazione delle norme è un processo a sé, con proprie notifiche e propri rimedi), quindi leggi qualsiasi messaggio che indichi una violazione delle norme come la cosa diversa che è, non come un altro round di questa.

Quanto tempo impiega Google a revisionare una richiesta ripresentata?

Questa sezione esiste soprattutto per fermare un comportamento: arriva l’ottavo giorno, la stima è superata, e lo sviluppatore inizia a cambiare le cose. Le due segnalazioni della community qui sotto mostrano quanto una revisione possa discostarsi dalla stima senza che ci sia nulla di sbagliato.

Quelle due lunghe attese sono segnalazioni singole e dimostrano solo che attese lunghe possono verificarsi. Non sono una distribuzione, e superare il settimo giorno non è di per sé un segnale che qualcosa sia andato storto. Per un quadro più ampio sui vari tipi di revisione, leggi il nostro articolo su i tempi di revisione di Google Play.

Quando vale la pena contattare l’assistenza di Play Console?

Non esiste una regola pubblicata del tipo "contatta l’assistenza dopo X giorni", e inventarne una sarebbe lo stesso errore di inventare un periodo di attesa. Quello che si può dire è quali situazioni la documentazione pubblica smette di spiegare, ed è lì che l’assistenza diventa l’unica fonte rimasta per una risposta:

• L’istruzione non è disponibile o è contraddittoria. Non riesci a recuperare il messaggio della decisione, oppure quello che dice non corrisponde a quello che mostra la console.
• La console resta bloccata. Apply for production rimane non disponibile anche se i criteri pubblicati sembrano soddisfatti e ogni voce dell’elenco sul pulsante disattivato qui sopra risulta a posto.
• La revisione è sostanzialmente fuori dalla stima senza alcuna informazione sullo stato disponibile da nessuna parte nella console.
• Il messaggio sembra appartenere a un processo diverso. Qualsiasi cosa che nomini una violazione delle norme o un’azione tecnica di applicazione non è questa decisione, e chiedere informazioni su di essa qui spreca le due settimane.

Al di fuori di questi casi, aspettare è l’azione corretta, non quella passiva. Reinviare, modificare il canale o ritirare una richiesta per ripresentarla sono tutte modifiche fatte a un processo che non puoi vedere, e nessuna di esse è indicata da nulla di ciò che Google pubblica.

La tua checklist per ripresentare la richiesta

Gli undici passaggi, in ordine

1. Leggi il rifiuto esatto e verifica se specifica altri 14 giorni. Se non riesci a trovarlo, recuperalo prima di pianificare intorno a una durata.
2. Mantieni attivo il test chiuso idoneo. Non chiudere, eliminare o sostituire il canale a causa del rifiuto, e pubblica su di esso le correzioni fondate quando il test lo richiede.
3. Mantieni almeno 12 tester idonei attivati in modo continuativo. Ognuno di quelli contati ha bisogno del proprio periodo ininterrotto.
4. Non chiedere ai tester di uscire e rientrare. Google non documenta alcun azzeramento che il rientro attiverebbe, e uscire interrompe un periodo continuativo reale che hai già.
5. Dai ai tester istruzioni di test reali a livello di funzionalità invece di chiedere loro di tenere semplicemente installata l’app.
6. Registra il feedback significativo in un breve registro scritto, qualunque sia il canale attraverso cui arriva.
7. Correggi bug e problemi di usabilità fondati, poi convalida la correzione con il tester che l’ha segnalata.
8. Rivedi il rapporto pre-lancio per problemi, avvisi ed errori prima di inviare la richiesta.
9. Controlla le aree di prontezza al di fuori del test: conformità alle norme, pubblico di destinazione e classificazione dei contenuti, affidabilità funzionale e credenziali del revisore funzionanti in Accesso all’app.
10. Prepara risposte specifiche e sincere per l’accesso in produzione su coinvolgimento, feedback, modifiche e prontezza.
11. Invia la richiesta dalla Dashboard quando sei idoneo, e non promettere a nessuno una decisione entro sette giorni.

Copia la checklist

Quell’elenco è il caso generale. Il tuo caso ha almeno tre variabili che il caso generale non può vedere: cosa diceva il tuo messaggio, a che punto si trova oggi il tuo gruppo di tester, e quante volte sei già passato di qui. Lo strumento qui sotto trasforma queste variabili in un percorso ordinato da seguire, e mantiene le tue spunte anche se chiudi la scheda.

Costruisci il tuo percorso

Una cosa che lo strumento non stamperà mai, qualunque cosa tu risponda, è una data in cui Google ti approverà. Nessuno può fornirla, e una segnalazione della community su uno sviluppatore approvato al quarto tentativo convive con un’altra che descrive un sesto rifiuto. Quello che il percorso può fare è assicurarsi che, quando arriva la decisione, venga presa su una richiesta che puoi difendere, e non su due settimane semplicemente trascorse.

Se seguendo quel percorso scopri che la parte relativa ai tester è l’ostacolo (il tuo rifiuto richiede esplicitamente altri 14 giorni, oppure il tuo gruppo non ha più 12 tester idonei), quella è la metà che puoi delegare: PrimeTestLab se ne occupa mentre tu migliori l’app, il registro del feedback e le risposte per la nuova richiesta. Ne parliamo in come aiutiamo più avanti.

Come aiuta PrimeTestLab se ti serve un altro gruppo di tester

Dove un test gestito ha davvero senso, il recupero si divide in due metà. Una è il giudizio: leggere il tuo rifiuto, decidere cosa cambiare, scrivere risposte che puoi difendere. Quella metà è tua. L’altra è la logistica: mantenere 12 persone reali attivate e che usano l’app per l’intera finestra di test. Non è il problema interessante, ma è quello che consuma il calendario.

PrimeTestLab fornisce 12 tester reali su dispositivi reali, da Android 7 a 17, attivati e mantenuti per tutti i 14 giorni, con il test che parte entro 4-6 ore. Lo abbiamo fatto su 7.400+ app in 120+ paesi con un tasso di completamento test gestiti del 99,9%: completamento significa che il test ha mantenuto il numero di tester richiesto e un periodo di attivazione ininterrotto fino alla data di fine.

Quello che non facciamo, e che questo articolo ha sostenuto che nessuno può fare, è promettere la decisione: Google valuta l’accesso in produzione secondo i propri criteri e non pubblica alcuna griglia di valutazione. La nostra garanzia è un nuovo test gratuito o un rimborso completo: condizioni e finestra di richiesta sulla nostra politica di rimborso e nuovo test gratuito.

Reclutare da solo un altro gruppo rispetto a un test gestito

La tabella scorre lateralmente su schermi stretti

Per essere diretti sul limite: comprare tester non risponde al questionario, non scrive il tuo registro del feedback, e non fa approvare nulla a Google. Tutto quello che precede questa sezione è scritto per permetterti di fare bene quelle parti. Quello che un test gestito elimina è la parte in cui una finestra di test crolla per lo stesso motivo della prima.

Un avvertimento che vale la pena ripetere dalla tabella dei miti qui sopra: gruppi più grandi offrono una protezione contro gli abbandoni, ma Google non pubblica alcun numero superiore a 12 che aumenti in modo misurabile la probabilità di approvazione, quindi nessuno (noi compresi) dovrebbe venderti tester in più come probabilità migliori. Compra il margine per il margine, non per altro. Dettagli completi sulla pagina dei prezzi.

Domande frequenti

In sintesi

Se il tuo rifiuto indicava effettivamente altri 14 giorni, o se il tuo gruppo non ha più 12 tester idonei, quella parte legata ai tester è l’unica che puoi delegare mentre ti occupi del resto. Vedi i piani e i prezzi →