Perché i test chiusi falliscono: note dal campo sulla finestra di 14 giorni

La maggior parte delle richieste di accesso in produzione non si perde nel modulo. Si perde da qualche parte a metà finestra, quando il conteggio scivola silenziosamente sotto la soglia e nessuno se ne accorge finché Google non rimanda indietro la richiesta.

Il requisito è facile da enunciare: 12 tester, iscritti, in modo continuativo per 14 giorni. Gli account personali creati dopo il 13 novembre 2023 non possono distribuire un'app finché quella serie non è completa e la richiesta non è stata esaminata.

Gli sviluppatori lo leggono come un problema di reclutamento, quindi tutta l'energia va al primo giorno. La chat di gruppo, il server Discord, i cugini. Il resto della finestra viene trattato come un periodo di attesa. È in quella cornice che i test muoiono. Il requisito non sono dodici tester il primo giorno. Sono dodici tester ogni giorno della finestra, compresi i giorni in cui nessuno pensa alla tua app.

I tre modi in cui muore un test

1. Il conteggio scivola

Le iscrizioni arrivano tutte all'inizio. Quasi tutti quelli che avrai mai dicono sì nei primi giorni, quando stai ancora chiedendo. Le disdette vanno nella direzione opposta, lentamente, per due settimane: un tester si disiscrive, disinstalla l'app durante una pulizia del telefono, perde interesse. Ogni partenza è piccola. La soglia no. A undici sei sotto la soglia e la serie smette di contare.

I giorni non tornano nemmeno. Le indicazioni di Google sono esplicite: il periodo deve essere consecutivo. Un tester che si disiscrive e poi rientra più tardi inizia una nuova serie, non ne riprende una. Un calo che lasci stare al sesto giorno può costarti l'intera finestra.

2. L'installazione che non si apre mai

Il conteggio non è tutto il requisito. Google indica l'insufficiente coinvolgimento dei tester come motivo dichiarato per rimandare indietro un'app per test successivi, proprio accanto al calo sotto il minimo. Il numero può essere giusto e la richiesta torna comunque.

È il fallimento che si nasconde meglio. Un link di iscrizione mette un nome nella lista; non mette una sessione nelle tue analytics. I tester che installano e non aprono mai l'app tengono la dashboard verde mentre il vero segnale si degrada sotto. Niente diventa rosso.

Ti raggiunge anche al modulo. La richiesta chiede cosa hanno fatto i tester: se hanno usato tutte le funzioni disponibili, se il loro uso corrispondeva al comportamento in produzione, che feedback hai ricevuto e come lo hai raccolto. Un test senza attività non ha risposta a quelle domande, e una risposta vuota non è una risposta neutra.

3. L'account era già nei guai

Alcune serie sono perdute prima di iniziare. Una precedente richiesta di accesso in produzione rifiutata. Un elenco store incompleto. Un problema di policy mai risolto. I quattordici giorni scorrono, i report arrivano, il modulo parte, e Google rifiuta per un motivo che non c'entra niente con i tuoi tester. Controlla l'account prima di avviare l'orologio, non dopo che è tornato.

Perché l'ossessione per il reclutamento iniziale è sbagliata

La regola dell'iscrizione continua cambia i conti. I tester non valgono lo stesso a ogni giorno della finestra.

Perdere il tuo dodicesimo tester al dodicesimo giorno costa più che guadagnarne cinque al giorno zero. I reclutamenti iniziali sono economici ed abbondanti: il link di iscrizione accetta fino a 100 nomi, quindi il tetto non è mai stato il limite. I tester della fine della finestra sono quelli che tengono insieme la serie.

Quindi il numero da ottimizzare non è il picco. È il minimo nel giorno peggiore. Recluta con un margine comodo sopra la soglia, poi passa le due settimane successive a difendere la soglia.

Come appare davvero il calo

Un test che fallisce ha una forma, e la vedi nel conteggio giornaliero:

• Giorni 1 a 3. Il conteggio salta al suo massimo. Tutti quelli che hai invitato si presentano. Sembra un successo ed è la parte meno informativa del grafico.
• Giorni 4 a 9. La fase tranquilla. Uno o due tester si allontanano, il conteggio è ancora sopra la soglia, quindi niente sembra sbagliato. È qui che le serie iniziano ad andare male, ed è la parte che smetti di controllare.
• Giorni 10 a 14. Dove le serie si perdono davvero. Il conteggio si sta erodendo da una settimana, lo sviluppatore non apre la console da tre giorni, e una singola partenza ora riavvia tutto.

Il controllo quotidiano è noioso: apri la console e confronta oggi con ieri. Venti tester che scendono verso dodici è una posizione peggio di quattordici che restano fermi.

Come appare un test sano

Tre cose, in ordine:

1. La tendenza. La direzione ti dice come sarà la settimana prossima. Il totale ti dice solo dove sei oggi.
2. Se i tester aprono l'app. Le iscrizioni sono il requisito; le sessioni sono il motivo per cui il requisito esiste. Se non vedi attività, stai tenendo una lista, non un test.
3. La data su cui ripartire. Tienila visibile per tutti i quattordici giorni. Ogni giorno che il conteggio regge, quella data si allontana, ed è l'unico tabellone che conta.

Quando il numero cala, sostituisci il tester nello stesso giorno, da una fonte di cui già ti fidi. Un calo che ripari in ventiquattro ore non ti costa niente. Un calo che ripari al tredicesimo giorno costa due settimane. Aspettare per vedere se tornano è la scelta più costosa.

La fase che nessuno può falso

Tenere il conteggio richiede qualche minuto al giorno. La parte difficile è l'offerta: tester verificati che restano iscritti per tutta la finestra, invece di persone che installano al secondo giorno e spariscono.

È la parte che gestisce Console Testers. Mettiamo 30 tester verificati sulla tua traccia e li teniamo lì per l'intera finestra e oltre, con i report di test generati alla fine per il modulo di accesso in produzione. Il conteggio non dipende dal fatto che la tua chat di gruppo sia ancora viva all'undicesimo giorno.

Il punto onesto

Il reclutamento avviene al primo giorno. Il test avviene negli altri tredici giorni, e sono quelli che non finiscono mai nel calendario.

Un'attenzione quotidiana per quattordici giorni ti porta al modulo. Un rifiuto ti rimanda per altri quattordici prima che tu possa compilarlo di nuovo.

Fonti

1. Guida di Google Play Console: requisiti di test per i nuovi account personali di sviluppatore, per il minimo di tester, la regola dell'iscrizione continua, il coinvolgimento come motivo di test prolungati, il modulo di richiesta e i tempi della revisione.