Risposta rapida
Prepara le risposte partendo da quello che hai registrato su reclutamento, test, feedback, modifiche e prontezza dell’app. Usa gli esempi qui sotto come traccia, sostituisci ogni dato concreto e segui il testo e il limite di caratteri che ti mostra il tuo modulo in Play Console.
Il modulo ti chiede del test che hai appena concluso, dell’app che hai costruito e della tua decisione di pubblicarla. Questa pagina percorre un campo alla volta, mostra una bozza svolta e spiega cosa scrivere quando le tue prove sono poche, qualitative o non hanno prodotto nessuna modifica al codice.
Che cos’è il questionario di accesso alla produzione?
Quando il tuo test chiuso soddisfa i criteri, in Play Console compare «Richiedi l’accesso alla produzione» nella dashboard della tua app. Quel pannello elenca i criteri che ti mancano ancora e contiene un link Anteprima delle domande, così puoi leggere il modulo prima di iniziare. Google divide le domande in tre sezioni:
Google descrive lo scopo della sezione sul test chiuso come la conferma che le app siano testate in modo soddisfacente prima della pubblicazione. La Sezione 2 è la parte più leggera: Google dichiara che quelle risposte non vengono mostrate su Google Play e non incidono sull’accesso alle funzionalità di Play Console.
Cosa pubblica Google
- La revisione richiede di solito 7 giorni o meno, e a volte può richiedere più tempo.
- Ti può essere chiesto di continuare a testare se non hai 12 tester idonei o se i tester non hanno interagito con l’app.
- Le risposte della Sezione 2 non vengono pubblicate e non incidono sull’accesso alle funzionalità.
- Uscire dal modulo senza percorrerlo fino in fondo può far perdere le risposte non salvate: usa Avanti tra una sezione e l’altra e Richiedi alla fine.
Fonte: Guida di Play Console, requisiti di test per gli account sviluppatore personali.
Questa pagina copre nove domande della richiesta iniziale, più una domanda della nuova richiesta segnalata da sviluppatori a cui è stato chiesto di continuare a testare. Google non pubblica un elenco fisso e, stando alle segnalazioni, il testo, il tipo di campo e le domande che compaiono cambiano da un account all’altro. Segui il tuo modulo.
Ogni esempio di questa pagina sta sotto i 300 caratteri e mostra il proprio conteggio. Alcuni sviluppatori segnalano un limite vicino a quella cifra, ma non è stato possibile verificare nessun limite universale attuale: fa fede il contatore del tuo modulo. Nessuna prova pubblicata collega la lunghezza della risposta all’esito.
Quali prove ti conviene preparare?
Fallo una volta sola e il modulo smette di essere un problema di scrittura. Raccogli queste tre cose prima di aprirlo. Tutto quello che trovi in questa pagina si costruisce a partire da lì.
Le cifre su cui il modulo ti farà domande, prese dalle informazioni sull’idoneità in Play Console e dai tuoi registri, così che le due fonti concordino con quello che scrivi.
- Quanti tester erano attivati e in quali date.
- Se l’attivazione è rimasta continuativa negli ultimi 14 giorni, senza interruzioni.
- Su quale versione ciascun tester ha chiuso il test.
Disinstallare non è uscire dal test. Un tester che elimina l’app resta attivato; per uscire serve un gesto deliberato, dal link del test o dalla sezione beta dell’app nel Play Store (Uscire dal programma beta di un’app). Quindi il numero di installazioni non dimostra né che il test sia avvenuto né che si sia fermato.
Attività, non aggettivi. Annota i flussi che hanno completato e come lo sai.
- Quali flussi principali sono stati percorsi: registrazione, attività principale, condivisione, impostazioni, pagamento.
- Più o meno quante volte è stata aperta l’app e in quale periodo.
- Dove le persone si sono bloccate e, se lo sai, su quali dispositivi o versioni di Android.
Indica la fonte di ogni affermazione. Un conteggio basato sulle segnalazioni dei tester è una cosa diversa da un conteggio registrato dall’analytics, anche quando entrambi si scrivono come numeri. Vanno bene tutti e due, basta dire quale dei due hai.
Google indirizza gli sviluppatori alla pagina del feedback di test in Play Console e consiglia di tenere un registro. Basta una riga per ogni rilievo:
- Dove è arrivato il feedback (feedback in Play Console, modulo nell’app, chat, email).
- Che cosa hai rilasciato in risposta e in quale versione.
- Come hai verificato che funzionasse e quali rilievi restano aperti.
Un registro che risponde a quattro delle nove domande
Bastano tre colonne. Le righe qui sotto appartengono all’app inventata che presentiamo nella sezione successiva; le tue saranno completamente diverse, ed è proprio questo il punto.
| Cosa ha rilevato il test | Cosa è stato rilasciato | Come è stato verificato |
|---|---|---|
| Dopo la modifica di un piano turni i promemoria non partivano. | Versione 1.4.1: corretta la riprogrammazione dei promemoria dopo le modifiche al piano turni. | Entrambi i tester che l’avevano segnalato hanno confermato che i promemoria sono arrivati per i due turni successivi. |
| La pubblicazione di un piano turni falliva con connessioni lente e la bozza andava persa. | Versione 1.4.2: la bozza resta in locale e il tentativo si ripete finché la pubblicazione non riesce. | Nuovo test con connessione rallentata prima e dopo: la bozza è rimasta. |
| La vista settimanale risultava compressa sugli schermi piccoli. | Non rilasciata. Pianificata dopo il lancio. | Aperto. Indicato come punto aperto nella risposta sulla prontezza, invece di dichiararlo risolto. |
E se non hai dati di analytics dettagliati?
Se non hai raccolto analytics di sessione, puoi comunque rispondere a ogni domanda. Quello che non puoi fare è trasformare un’impressione in una misura. Scrivi quello che sai e indica come lo sai. «Dieci tester su dodici mi hanno detto di aver creato almeno un piano turni; non avevo analytics di sessione» è utilizzabile e verificabile. Una durata media di sessione inventata no.
Lo stesso vale per il rapporto pre-lancio: Google lo descrive come un test automatico sui propri dispositivi, con limiti di copertura (Usare il rapporto pre-lancio per individuare i problemi). Documenta una scansione automatica, non un test fatto da persone.
Se Android vitals non mostra arresti anomali
Una dashboard vuota non dimostra zero arresti anomali. Android vitals dipende dai dati diagnostici idonei e Google segnala che una vista vuota può significare dati insufficienti con i filtri che hai selezionato (Android vitals). Se i dati sono pochi, dichiara questo limite.
Scrivi prima le risposte altrove
Google avverte che uscire dal modulo senza aver premuto Avanti in ogni sezione e Richiedi alla fine può far perdere il lavoro. Scrivi le risposte in un documento, confrontale tra loro e poi incollale nel modulo.
Ti servono ancora tester?
Se hai completato il test, usa gli esempi qui sotto per preparare le risposte a partire dai tuoi dati e verifica ogni risposta rispetto a ciò che è realmente accaduto. Se ti servono ancora tester, confronta le opzioni di supporto al test: PrimeTestLab fornisce le risposte al questionario dopo il suo test, e tu le verifichi e invii la richiesta.
Come usare questi esempi di risposta
Ogni dato di ogni esempio qui sotto è inventato. Descrivono tutti la stessa app di fantasia, così puoi vedere come un solo registro di test diventa nove risposte coerenti. Nessuno di questi esempi è una risposta pronta da inviare per la tua app, e non lo diventa accorciandolo.
Sostituisci ogni nome, numero, data, funzione e rilievo con i tuoi prima di usare qualunque cosa di questa pagina. Una risposta che dice ancora «Shiftly», o che continua a dichiarare dodici tester in quattordici giorni quando non è andata così, descrive il test di qualcun altro.
Quale variante scegliere?
Le bozze predefinite seguono tutte il test inventato di Shiftly. Le schede alternative descrivono situazioni diverse: un altro metodo di reclutamento, prove più scarne, un altro tipo di app. Scegli quella che corrisponde al tuo test, poi rendi coerenti le risposte collegate. Una risposta «nessuna modifica» non può stare accanto a risposte su feedback e prontezza che dichiarano correzioni rilasciate, e la scheda del gioco è un gioco di fantasia a sé.
Come si legge una bozza
- Il testo evidenziato così è un dato che devi sostituire.
- Copia come modello trasforma ognuno di questi in un segnaposto tra parentesi, mai in una frase già pronta.
- Le spiegazioni stanno fuori dal riquadro della bozza, così non puoi incollare una nota redazionale nel modulo.
- Il conteggio dei caratteri misura l’esempio, non quello che scriverai tu.
Esempio illustrativo, non un’app reale
ShiftlyUn’app di fantasia per pianificare i turni di piccoli negozi e bar, usata in tutta la pagina solo per tenere coerenti le nove risposte. Non è un cliente, non è un caso di studio e non le attribuiamo nessun risultato.
- Test chiuso 12 tester, 14 giorni continuativi
- Flussi principali Registrazione, creazione del piano turni settimanale, invito a un collega, pubblicazione, promemoria del turno
- Release durante il test 1.4.1 e 1.4.2
- Punto aperto Vista settimanale compressa sugli schermi piccoli
Parte 1: il tuo test chiuso
Questa sezione ti chiede di descrivere reclutamento, attività e feedback. Tieni le risposte coerenti con le informazioni sull’idoneità in Play Console e con i tuoi registri del test, e racconta le attività, il feedback e le verifiche che nessuna metrica della dashboard riesce a cogliere.
Come hai reclutato gli utenti per il tuo test chiuso?
Google chiede da dove sono arrivati i tuoi tester. Indica la fonte che hai usato davvero e chiarisci chi ha condotto il test. La varietà è una buona pratica, non una regola contro la fonte unica: un solo canale dichiarato con onestà vale più di un elenco inventato.
Cosa serve in questo campo
- Il canale o i canali che hai usato davvero.
- Chi sono i tester rispetto al pubblico della tua app.
- Chi ha definito gli scenari, letto il feedback e rilasciato le modifiche.
Bozza di esempio (inventata)
Ho reclutato 12 tester dalla mia rete personale: cinque colleghi del coworking, quattro amici che gestiscono i turni di un negozio e tre da un forum di test. Si sono attivati entro due giorni e sono rimasti attivati per tutti i 14 giorni. Ho definito io gli scenari e ho letto io il feedback.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Bozza di esempio (inventata)
Ho reclutato 12 tester tramite un servizio di test a pagamento. Ho scelto io gli scenari, ho letto il feedback in Play Console e nei report del fornitore, ho rilasciato due aggiornamenti durante il test e ho chiesto a chi aveva segnalato di confermare la correzione.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Bozza di esempio (inventata)
Tutti e 12 i tester vengono da una sola fonte: un gruppo di negozianti indipendenti di cui già facevo parte. Sono esattamente le persone per cui l’app è pensata. Ho invitato ognuno direttamente invece di pubblicare un link di test pubblico.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«Ho trovato i tester online.»
Non indica nessun canale, nessun rapporto con il tuo pubblico e nessuno che abbia condotto il test.
Nessuna indicazione pubblicata dice che nominare un fornitore influisca sull’esito. Quello che conta è che il resto del modulo sia coerente: se i tester li ha reclutati un fornitore, scrivi chi ha definito gli scenari, chi ha letto il feedback, chi ha fatto le modifiche e chi le ha verificate.
Quanto è stato facile reclutare i tester?
Una scala che va da molto difficile a molto facile. Scegli l’opzione che corrisponde alla tua esperienza. Nessuna indicazione pubblicata segnala un’opzione preferibile. Le righe qui sotto sono illustrazioni approssimative, non criteri: reclutare può essere difficile o facile per motivi che nessuna di esse copre.
- Molto difficile Non hai raggiunto i 12 tester e il test è slittato o si è fermato.
- Difficile Hai dovuto chiedere più volte, o fare diversi tentativi in un periodo lungo.
- Né difficile né facile Ci è voluto un po’ di impegno e più o meno il tempo che ti aspettavi.
- Facile Una o due richieste hanno riempito l’elenco.
- Molto facile Avevi più volontari che posti.
Nessuna di queste opzioni è consigliata. Il testo e il numero delle scelte possono essere diversi da quelli mostrati qui sopra: leggi il tuo modulo.
Descrivi il coinvolgimento che hai ottenuto dai tester
Gli esempi che Google porta qui riguardano l’uso delle funzioni e quanto somiglia a un uso reale in produzione. «Molto coinvolti» non descrive niente che qualcuno possa immaginare. Indica i flussi, il periodo, l’andamento e da dove arrivano le tue cifre.
Cosa serve in questo campo
- Quanti tester e in quale periodo.
- Da due a quattro flussi che hanno completato davvero, indicati per nome.
- L’andamento dell’utilizzo e da dove arrivano le cifre.
Bozza di esempio (inventata)
In 14 giorni, 12 tester hanno creato 31 piani turni; tutti hanno completato registrazione e creazione del piano, nove hanno invitato un collega e sette ricevuto un promemoria. Chi gestiva più negozi apriva l’app quasi ogni giorno, gli altri ogni settimana. Le cifre vengono dal log eventi in-app.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Bozza di esempio (inventata)
Durante il test non avevo analytics di sessione. Dieci tester su dodici mi hanno detto di aver creato almeno un piano turni settimanale e sei di aver invitato un collega. Ho visto due tester completare la registrazione in una sessione condivisa. Non posso riferire il numero di sessioni.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«I tester erano attivi e hanno usato l’app.»
Nessun numero, nessun periodo, nessun flusso indicato per nome e nessuna fonte.
Riassumi il feedback che hai ricevuto
Google chiede sia che cosa diceva il feedback sia come lo hai raccolto. Indica il canale, i temi emersi davvero e che cosa hai fatto per ciascuno, compreso quello che non hai fatto. Far stare più rilievi in un campo corto è la parte che richiede lavoro di sintesi.
Cosa serve in questo campo
- Dove è arrivato il feedback.
- I temi emersi davvero, qualunque sia il loro numero.
- Quali hai già rilasciato e quali restano aperti.
Bozza di esempio (inventata)
Le segnalazioni sono arrivate dal feedback di test in Play Console e da una chat di gruppo. I temi: promemoria mancati dopo la modifica di un piano turni, pubblicazione fallita su rete lenta, vista settimanale compressa su schermi piccoli. I primi due sono corretti e rilasciati, il terzo è aperto.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«Il feedback è stato positivo.»
Non indica il canale, non indica i temi e non dice che cosa hai fatto: esattamente le tre cose che il campo chiede.
Se il feedback è stato davvero tutto positivo, scrivilo e indica che cosa copriva. Un difetto inventato deve poi restare coerente anche con la Q8 e la Q9.
Ti mancano tester che restino attivati per 14 giorni senza interruzioni?
PrimeTestLab mette a disposizione 12 tester pre-qualificati a partire da 19,99 USD, con avvio entro da 4 a 6 ore.
Parte 2: la tua app o il tuo gioco
Google dichiara che queste risposte non vengono mostrate su Google Play e non incidono sull’accesso alle funzionalità di Play Console. Scrivile in modo piano: non è il testo della scheda dello Store e qui non c’è niente da vendere.
A chi è destinata la tua app?
Google ti chiede precisione. «Tutti» non descrive nessuno. Copri chi sono, quale problema hanno e quando aprono l’app. Se hai davvero due tipi di utente, nominali entrambi.
Cosa serve in questo campo
- Chi sono: ruolo, situazione o fascia d’età se è davvero rilevante.
- Il problema che hanno prima che la tua app esista.
- Quando e quanto spesso la usano.
Bozza di esempio (inventata)
Shiftly è pensata per titolari e responsabili di negozi e bar con un organico da 3 a 20 persone che oggi preparano i turni su carta o in un’app per appunti. La usano una volta a settimana quando pianificano la settimana dopo, e a brevi riprese quando qualcuno chiede di scambiare un turno.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«Tutti.»
Non indica nessun utente, nessun problema e nessuna occasione, e non è quasi mai vero.
Descrivi il valore che la tua app dà agli utenti
Parti dal risultato, poi indica le due o tre funzioni che lo producono. Per un gioco il valore è l’esperienza: il ciclo di gioco, che cosa lo rende diverso, quanto dura una partita e perché si torna a giocare.
Cosa serve in questo campo
- Il risultato, in una frase, prima di qualsiasi elenco di funzioni.
- Due o tre funzioni che producono quel risultato.
- Per un gioco: il ciclo, l’elemento distintivo, la durata di una partita.
Bozza di esempio (inventata)
Con Shiftly, chi gestisce un negozio riusa i turni della settimana scorsa, li pubblica per il personale e manda un promemoria prima di ogni turno. Il personale chiede i cambi nell’app invece che per messaggio.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Bozza di esempio (inventata)
I giocatori svuotano un tabellone incatenando abbinamenti di colore entro un timer di 90 secondi. Ogni tabellone completato riscrive il successivo, così due partite non sono mai uguali. Una partita dura circa tre minuti e si torna per il tabellone del giorno.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«La mia app è utile e ha buone funzioni.»
Nessun risultato, nessuna funzione e nessun utente, per di più in un campo che Google non pubblica.
La scheda Gioco è un secondo esempio di fantasia, non Shiftly. Se la usi, il resto delle risposte deve descrivere il tuo gioco, non un’app per i turni.
Quante installazioni ti aspetti nel primo anno?
Google dice che va bene una stima approssimativa e che le fasce sono volutamente ampie. Scegli la fascia che il tuo pubblico e la tua stima di lancio sostengono. Nessuna indicazione pubblicata segnala una fascia preferibile, e il consiglio diffuso di scegliere quella intermedia non ha alcun fondamento.
- 0-10.000
- 10.000-100.000
- 100.000-1 milione
- Oltre 1 milione
- Non lo so È un’opzione vera, e si difende meglio di un numero inventato.
Nessuna di queste opzioni è consigliata e nessuna di queste fasce dice alcunché sulla tua app. Le etichette e il testo delle fasce cambiano: leggi il tuo modulo.
Parte 3: pronti per la produzione
Questa sezione chiede che cosa ha prodotto il test e perché hai deciso di pubblicare. Entrambe le risposte devono leggersi come conclusioni tratte dal registro che hai costruito prima, non come affermazioni nuove che compaiono qui per la prima volta.
Quali modifiche hai fatto in base al tuo test chiuso?
Descrivi le modifiche che hai fatto davvero e come le hai verificate. Le indicazioni pubblicate non stabiliscono nessuna formula di punteggio per questo campo e nessun numero minimo di aggiornamenti. Questo non significa che la risposta non abbia effetto, e non giustifica un problema bloccante o di policy che già conosci. Tieni separato quello che hai completato da quello che hai in programma.
Cosa serve in questo campo
- Che cosa ha rilevato il test, con parole tue.
- Che cosa hai rilasciato in risposta, con il numero di versione se ce l’hai.
- Come l’hai verificato e che cosa resta aperto.
Bozza di esempio (inventata)
Due release durante il test. La 1.4.1 ha corretto i promemoria dopo una modifica dei turni; la 1.4.2 la pubblicazione su rete lenta. Chi aveva segnalato il problema ha confermato la correzione; ho ripetuto la pubblicazione su rete rallentata. La vista settimanale compressa resta aperta.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Bozza di esempio (inventata)
In questo test non ho rilasciato modifiche. I tester hanno verificato registrazione su Android 10, pubblicazione su rete lenta e promemoria su 3 build OEM. I risultati: nessun guasto segnalato, nessun arresto anomalo in Android vitals con dati sufficienti. Gli schermi piccoli non sono testati.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«Abbiamo migliorato l’app.»
Non indica nessun rilievo, nessuna release e nessuna verifica, quindi non si può far quadrare con la tua risposta sul feedback.
E se non hai fatto modifiche?
Le indicazioni non prescrivono nessun numero di aggiornamenti e un’app rimasta uguale non è automaticamente una richiesta debole. Quello che rende debole una risposta è un test non spiegato. Usa la scheda Nessuna modifica rilasciata qui sopra: quali flussi e quali condizioni hai verificato, quali risultati hai ottenuto e da dove arrivano, e che cosa resta irrisolto. Non inventare un difetto solo per avere una correzione da raccontare.
Come hai deciso che la tua app è pronta per la produzione?
Google chiede i tuoi criteri di decisione, non la tua sicurezza. Indica le due o tre cose che hai guardato e la prova che sta dietro a ciascuna. Tutto quello che scrivi qui dovrebbe già comparire prima nel modulo, con la stessa storia di verifiche.
Cosa serve in questo campo
- I criteri che hai usato, enunciati come criteri.
- La prova che sta dietro a ciascuno.
- I punti aperti e perché non bloccano la pubblicazione.
Bozza di esempio (inventata)
Tre criteri. La correzione dei promemoria è stata confermata dai tester coinvolti. Dopo la 1.4.2 ho ripetuto il test di pubblicazione dei turni su rete rallentata. La vista settimanale compressa resta aperta: è un problema estetico e i flussi principali testati sono utilizzabili.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«Mi sembrava che l’app fosse pronta.»
Una sensazione non è un criterio, quindi qui non c’è niente su cui essere d’accordo o in disaccordo.
Errori frequenti nelle risposte
Nessuno di questi è una regola pubblicata da Google. Sono i tratti ricorrenti che fanno dire a una risposta meno di quanto intendeva chi l’ha scritta.
«Molto coinvolti», «molto positivo», «testata a fondo». Ognuno occupa spazio in un campo corto senza indicare un flusso, un numero o un periodo.
«Non sono emersi problemi» in un campo e «ho corretto diversi bug» in quello dopo. Non possono essere vere tutte e due, e chi legge non ha modo di capire quale lo sia.
Se riporti del feedback, indica dove è arrivato: il feedback di test in Play Console, un modulo nell’app, un gruppo di chat, l’email. Senza questo, il riassunto resta senza fonte.
Un esempio incollato che descrive ancora l’app, il pubblico o il bug di qualcun altro non è una descrizione del tuo test. Ogni modello ha questo difetto di fondo, compresi quelli di questa pagina.
Una percentuale inventata per sembrare rigorosi è un’affermazione che non puoi sostenere. Un conteggio ricavato dalle segnalazioni dei tester va benissimo: basta scrivere che è così che lo hai ottenuto.
Scrivi quali correzioni sono state rilasciate e quali sono in programma. Se presenti un piano come una release, la cronologia delle tue versioni ti smentisce.
Scegliere l’opzione che suona meglio invece di quella che corrisponde ai fatti mette il menu in contrasto con il tuo testo libero, e nessuna indicazione pubblicata segnala una scelta preferibile.
Controlla le risposte prima di inviare
Il modulo viene letto come un unico documento. Quasi sempre a indebolirlo non è una frase scritta male, ma due frasi che non concordano. Fai questo passaggio con tutte e nove le risposte una accanto all’altra.
Niente in questa lista predice una decisione. È il passaggio che impedisce al tuo modulo di contraddirsi da solo.
Che cosa succede dopo la richiesta?
Vale la pena distinguere quattro esiti, perché due di essi vengono regolarmente scambiati l’uno per l’altro. Una revisione ancora in corso non è una richiesta di altri test, e l’accesso concesso non è un’app pubblicata.
Segui la revisione
Revisione in corsoGoogle dichiara che la revisione richiede di solito 7 giorni o meno, e a volte può richiedere più tempo. Tieni d’occhio Play Console e l’email dell’account, e rispondi a tutto quello che Google ti chiede. Un’attesa lunga, da sola, non è un motivo per inviare di nuovo la richiesta o per ricominciare il test.
Manca un passaggio
Accesso alla produzione concessoL’accesso e un’app online sono due cose diverse. Devi comunque preparare e distribuire una release di produzione, che ha una sua revisione. Vedi il flusso di pubblicazione di Google e i nostri tempi di revisione per accesso alla produzione e release.
Leggi il messaggio ricevuto
Altri test richiestiÈ una decisione sul tuo test, non solo su come lo hai scritto. Sotto trovi la guida completa.
Un problema dell’app, non di testo
Il revisore non è riuscito ad aprire l’appSe la tua app è dietro un login o è limitata in altro modo, il revisore ha bisogno di credenziali funzionanti. Inseriscile nei dati di accesso per la revisione. Nessuna risposta del questionario può sostituire l’accesso all’app.
Se Google ti chiede di continuare a testare
Non reinviare lo stesso modulo e non dare per scontato che il problema stia in come hai scritto le risposte. Procedi in questo ordine.
La notifica di solito indica un motivo: meno di 12 tester idonei, un’attivazione che si è interrotta durante i 14 giorni, oppure tester poco coinvolti. Considera quel messaggio più autorevole di qualunque guida generale, compresa questa.
Se ti mancavano tester, o se un’attivazione è decaduta, torna a 12 tester idonei con una cronologia recente senza interruzioni prima di ripresentare la richiesta: per i tester nuovi significa altri 14 giorni pieni. Riscrivere le risposte su un registro dei tester rimasto uguale non cambia le informazioni sull’idoneità.
Aggiorna i dati che sono cambiati e chiarisci ogni risposta incompleta o ambigua: una risposta può non riuscire a comunicare prove che avevi già. Quello che la riscrittura non può fare è risolvere un problema di test alla base. Un secondo test può produrre nuove osservazioni, nuovo feedback, modifiche o verifiche, ma niente di tutto questo è garantito e una nuova release non è obbligatoria.
Google richiede che negli ultimi 14 giorni consecutivi ci siano tester idonei, quindi non presentare mai la richiesta mentre sei sotto i 12. Oltre a questo, alcuni messaggi di rifiuto indicano un periodo aggiuntivo e altri no: Google non pubblica nessun intervallo universale per ripresentare la richiesta. La nostra guida su come ripresentare la richiesta dopo un rifiuto «More Testing Required» copre entrambi i casi, e spiega anche perché chiedere ai tester di disattivarsi e riattivarsi distrugge la cronologia che hai.
Se stai cercando di capire che cosa non ha funzionato nel test stesso, più che nel modulo, parti da come risolvere il rifiuto di un test chiuso.
Che cosa hai fatto di diverso questa volta?
Segnalata da sviluppatori che ripresentano la richiesta dopo essersi sentiti dire di continuare a testare. Il testo segnalato cambia e non tutti gli account riferiscono di averla vista: controlla il tuo modulo invece di dare per scontato che compaia o che non compaia.
Indica che cosa è diverso nel registro, non che cosa è diverso nel tuo atteggiamento. Se il secondo test è stato uguale al primo, è quello da sistemare prima di ripresentare la richiesta.
Cosa serve in questo campo
- Che cosa è cambiato nel test stesso.
- Che cosa ha prodotto: rilievi, release, conferme.
- Come le prove attuali rispondono alla decisione precedente.
Bozza di esempio (inventata)
Dopo la richiesta precedente ho svolto un altro test di 14 giorni con 12 tester e ho annotato che cosa ha fatto ciascuno. Sono emersi due difetti dei promemoria, corretti nella 1.4.3 e confermati dai tester che li avevano segnalati. Queste risposte descrivono quel test e quelle release.
Copia non disponibile. Seleziona e copia il modello qui sotto.
Una versione più debole, e cosa tralascia
«Questa volta mi sono concentrato sul raccogliere e applicare il feedback.»
Descrive un’intenzione invece di una differenza, che è l’unica cosa che questo campo chiede.
Questa bozza è uno scenario successivo: un secondo test con una release propria, la 1.4.3. Se è il tuo caso, il resto delle risposte descrive quel test attuale, non il registro precedente con la 1.4.1 e la 1.4.2.
Come PrimeTestLab sostiene il tuo test e la tua richiesta
Tutto quello che precede dà per scontato che tu abbia un registro da cui scrivere. Se l’ostacolo è proprio il registro, cioè trovare 12 persone che restino attivate per 14 giorni senza interruzioni, quella è la parte che facciamo noi. Persone vere su dispositivi reali, con avvio entro da 4 a 6 ore, per tutti i 14 giorni, e un avanzamento che vedi mentre succede.
Il nostro piano Starter mette a disposizione 12 tester a 19,99 USD, il piano Professional 20 tester a 29,99 USD e il piano Enterprise 25 tester a 27,99 USD, tutti con la garanzia dei 14 giorni completi.
Il requisito minimo, soddisfatto esattamente
Più copertura negli stessi 14 giorni
Più coinvolgimento negli stessi 14 giorni
Che cosa ti dà per il modulo
Tester con nome e cognome e una cronologia di attivazione senza interruzioni, un registro di quello che hanno fatto e il loro feedback per iscritto: la materia prima per la Q1, la Q3, la Q4 e la Q8. Le risposte le scrivi comunque tu, perché devono essere tue.
Che cosa non ti dà
Non inviamo il questionario al posto tuo, non possiamo influenzare una revisione e niente in questa pagina predice una decisione. Se un servizio ti dice il contrario, è quella l’affermazione da verificare per prima.
Confronta i piani per il test chiuso
Domande frequenti
Posso usare questi esempi come modello?
Come traccia sì, come testo da inviare no. Ogni dato che contengono appartiene a un’app di fantasia, quindi una risposta che conserva quei dati descrive il test di qualcun altro. Sostituisci ogni nome, numero, funzione e rilievo: il pulsante di copia ti consegna un modello con i segnaposto esattamente per questo motivo.
Che cos’è il questionario di accesso alla produzione?
È il modulo che compili quando richiedi l’accesso alla produzione dopo un test chiuso: riguarda il test che hai svolto, la tua app o il tuo gioco e la tua prontezza per la produzione. Lo raggiungi da «Richiedi l’accesso alla produzione» nella dashboard dell’app in Play Console e puoi leggerlo in anticipo dal link Anteprima delle domande.
Quanto può essere lunga ogni risposta?
Ogni esempio di questa pagina sta sotto i 300 caratteri e alcuni sviluppatori segnalano un limite vicino a quella cifra. Non è stato possibile verificare nessun limite universale attuale, quindi fa fede il contatore del tuo modulo. Nessuna prova pubblicata collega la lunghezza della risposta alle tue probabilità.
Devo dire che ho usato un servizio di test a pagamento?
Puoi rispondere in modo veritiero. Nessuna indicazione pubblicata suggerisce che nominare un fornitore influisca sull’esito, e un elenco di canali inventato è il rischio più grosso. Indica la fonte, poi scrivi chi ha definito gli scenari, chi ha letto il feedback, chi ha fatto le modifiche e chi le ha verificate.
E se non ho analytics per il test?
Se non hai raccolto analytics di sessione, riporta quello che sai e indica come lo sai. «Dieci tester su dodici mi hanno detto di aver completato la registrazione» è utilizzabile; una durata media di sessione inventata no. Un conteggio ricavato dalle segnalazioni dei tester è comunque un conteggio, purché lo dichiari.
E se durante il test chiuso non ho fatto modifiche?
Le indicazioni non prescrivono nessun numero di aggiornamenti e un’app rimasta uguale non è automaticamente una richiesta debole. Quello che rende debole una risposta è un test non spiegato. Scrivi quali flussi e quali condizioni hai verificato, quali risultati hai ottenuto e da dove arrivano, e che cosa resta irrisolto.
Quanto dura la revisione per l’accesso alla produzione?
Google dichiara che di solito richiede 7 giorni o meno e che a volte può richiedere più tempo. Una revisione ancora in corso non è un rifiuto. Tieni d’occhio Play Console e l’email dell’account, e rispondi a tutto quello che Google ti chiede.
Google mi ha chiesto di continuare a testare. Quando posso ripresentare la richiesta?
Leggi il messaggio che hai ricevuto: alcuni indicano un periodo aggiuntivo preciso e altri no, e Google non pubblica nessun intervallo universale per ripresentare la richiesta. In ogni caso, negli ultimi 14 giorni consecutivi servono almeno 12 tester idonei. Vedi i nostri passaggi di recupero qui sopra e la guida completa su che fare quando Google chiede altri test.
In sintesi
Riepilogo
Scrivi ogni risposta partendo dal tuo registro: chi ha testato, che cosa ha fatto, che cosa ha segnalato, che cosa hai rilasciato e come l’hai verificato. Sostituisci ogni dettaglio inventato di questa pagina, scegli nei menu le opzioni che corrispondono alla tua situazione, segui il testo e il contatore che mostra il tuo modulo, e rileggi le risposte tutte insieme perché siano coerenti.
Se il pezzo che manca è il registro, confronta i piani per il test chiuso.