TestFlight e beta test: provare l'app prima della pubblicazione

La tua app funziona perfettamente sul tuo telefono. La pubblichi, e il giorno dopo arriva la prima recensione da una stella: "si chiude appena la apro". Su un modello che non hai mai visto, con una versione del sistema che non hai mai provato. In questo articolo vediamo come si fa un beta test serio su iOS e su Android, prima che siano gli utenti a trovare i bug al posto tuo.

Cos'è un beta test

Un beta test è la distribuzione di una versione quasi finale dell'app a un gruppo ristretto di persone reali, attraverso i canali ufficiali degli store, per scoprire bug e problemi di usabilità prima della pubblicazione: su iOS lo strumento si chiama TestFlight, su Google Play si usano i canali di test della Play Console.

Non sostituisce i test automatici: quelli verificano che il codice faccia ciò che hai deciso. Il beta test verifica che quello che hai deciso abbia senso per chi usa l'app, e che funzioni in condizioni che non puoi riprodurre sulla tua scrivania.

Perché i tuoi bug non sono quelli degli utenti

Quando provi l'app tu, la provi in condizioni ideali, spesso senza accorgertene:

• Un solo dispositivo, di solito recente e veloce.
• Una sola versione del sistema operativo, aggiornata.
• Una rete stabile, il Wi-Fi di casa o dell'ufficio.
• Conosci già il percorso giusto: sai dove toccare, non sbagli mai ordine.

Gli utenti reali hanno telefoni vecchi con poca memoria, schermi piccoli, caratteri di sistema ingranditi, connessioni che cadono in metropolitana, lingue del sistema diverse dalla tua. E soprattutto non sanno come "dovrebbe" funzionare l'app, quindi fanno cose che non avevi previsto.

Su Android il problema è amplificato dalla varietà di produttori e dispositivi. Su iOS i modelli sono meno, ma le versioni del sistema e le dimensioni dello schermo bastano a creare sorprese.

TestFlight su iOS

TestFlight è il servizio di Apple per distribuire build di prova. Lo gestisci da App Store Connect, e i tester installano l'app tramite l'app TestFlight sul loro dispositivo.

Tester interni ed esterni

La distinzione più importante è questa:

	Tester interni	Tester esterni
Chi sono	Membri del tuo team in App Store Connect	Chiunque tu inviti
Revisione Apple	Non serve	Serve una revisione beta
Velocità	La build è disponibile appena elaborata	Devi attendere l'esito della revisione
Uso tipico	Sviluppatori, QA, colleghi	Utenti reali, clienti, community

La revisione beta per i tester esterni è più leggera di quella per la pubblicazione sull'App Store, ma esiste: Apple controlla che la build rispetti le linee guida di base. Di norma serve per la prima build di una versione, mentre le build successive possono avere un iter più rapido. I numeri massimi di tester per ciascun gruppo li trovi nella documentazione ufficiale di Apple.

Come inviti i tester

Due modalità:

• Invito via email: aggiungi gli indirizzi, ogni tester riceve un invito personale.
• Link pubblico: generi un link da condividere dove vuoi (newsletter, community, social). Chi lo apre può unirsi al test, fino al limite che imposti. Comodo per raccogliere tester fuori dalla tua cerchia.

Le build scadono

Una cosa da sapere prima di iniziare: le build TestFlight hanno una durata limitata. Dopo un certo periodo smettono di funzionare e i tester non possono più aprirle. La durata esatta è indicata nella documentazione di Apple: verificala alla fonte. In pratica significa che un beta test lungo richiede di caricare build nuove con regolarità, e questo è un ottimo motivo per automatizzare il caricamento con una pipeline di CI/CD, per esempio con GitHub Actions.

Quando la beta è conclusa, la stessa build può essere inviata alla revisione per la pubblicazione: i passaggi sono nella guida su come pubblicare un'app sull'App Store.

I canali di test di Google Play

Su Google Play il beta test si fa dalla Play Console, con tre canali diversi. Ciascuno è un "binario" su cui carichi una build, separato dalla produzione.

Canale	A chi serve	Caratteristiche
Test interno	Il team e pochi fidati	Il più rapido, pensato per le verifiche veloci, con un numero limitato di tester
Test chiuso	Un gruppo scelto da te	I tester si aggiungono con liste di indirizzi email o gruppi, e ricevono un link per partecipare
Test aperto	Chiunque voglia	L'app compare nello store con la possibilità di unirsi al programma di test

La progressione tipica è questa: prima il test interno per controllare che la build si installi e parta, poi il test chiuso con utenti veri, eventualmente il test aperto per una platea ampia prima della pubblicazione.

Il requisito per i nuovi account personali

Questo è un punto pratico che sorprende molti sviluppatori indipendenti. Per i nuovi account sviluppatore personali, Google richiede un periodo di test chiuso con un numero minimo di tester prima di poter chiedere l'accesso alla produzione. Non puoi caricare l'app e pubblicarla subito, come succedeva in passato.

Il numero di tester richiesto e la durata minima del test sono stabiliti da Google e sono cambiati nel tempo: verificali nella documentazione ufficiale della Play Console prima di pianificare il lancio. Il requisito non riguarda gli account aziendali allo stesso modo, e anche questo va controllato alla fonte.

La conseguenza pratica: se hai un account personale, il beta test non è opzionale e va messo in calendario. Servono persone reali disposte a installare l'app e usarla per un periodo, quindi conviene cercarle prima di avere la build pronta. Per i costi e i tipi di account, vedi quanto costa l'account Google Play Developer. Per i passaggi successivi, la guida su come pubblicare un'app su Google Play.

Cosa chiedere ai tester

"Provala e fammi sapere" produce una sola risposta: "bella!". Per ottenere feedback utili devi dare una direzione.

Dai compiti precisi. "Crea un account, aggiungi tre spese, prova a esportarle in PDF". Poi osserva dove si bloccano.

Fai domande specifiche. Invece di "ti piace?", chiedi:

• C'è stato un momento in cui non sapevi cosa fare?
• Qualcosa è stato più lento di quanto ti aspettassi?
• Cosa ti aspettavi che succedesse quando hai toccato quel pulsante?
• La useresti ancora la settimana prossima? Perché?

Chiedi il contesto. Modello del telefono, versione del sistema, tipo di connessione. Molti di questi dati li raccogli in automatico, ma il tester sa cose che il sistema non sa: "ero in treno", "avevo la modalità risparmio energetico".

Scrivi nelle note della build cosa testare. Sia TestFlight sia la Play Console permettono di aggiungere una descrizione a ogni build. Usala per dire cosa è cambiato e su cosa ti serve attenzione.

Come raccogliere feedback e crash

I feedback

In TestFlight il tester può fare uno screenshot dentro l'app e inviarlo con un commento: tu lo ritrovi in App Store Connect, associato alla build e al dispositivo. È il canale più comodo, perché il feedback arriva nel momento in cui il problema si presenta, invece che a memoria due giorni dopo.

Su Google Play i tester del programma possono lasciare un feedback privato, che vedi nella Play Console e non compare come recensione pubblica. Per feedback più strutturati, un modulo con domande precise o un canale di chat dedicato funzionano meglio.

I crash

Un tester raramente ti scrive "si è chiusa". Più spesso smette di usarla. Per questo devi raccogliere i crash in automatico:

• TestFlight fornisce i report dei crash delle build di test in App Store Connect.
• La Play Console mostra crash e blocchi dell'app, e offre un rapporto di pre-lancio che prova l'app su dispositivi reali prima che tu la distribuisca.
• Uno strumento di crash reporting integrato nell'app, come Firebase Crashlytics, ti dà lo stack trace e il contesto del dispositivo per entrambe le piattaforme in un unico posto.

Senza questi dati, un beta test ti dice che "qualcosa non va" ma non cosa.

Errori comuni

Beta test solo con amici che dicono "bello". Amici e familiari vogliono farti piacere, non trovarti i difetti. Cerca almeno qualche tester che corrisponda al tuo utente reale e che non ti conosca.

Nessun modo di raccogliere i crash. Se l'app si chiude sul telefono di un tester e non hai un sistema di crash reporting, quel bug lo scoprirai dalle recensioni pubbliche.

Testare solo sul proprio telefono di fascia alta. Le prestazioni su un dispositivo vecchio o economico possono essere un'altra app. Procurati almeno un dispositivo datato, o assicurati che tra i tester ci sia varietà.

Nessuna istruzione per i tester. Senza compiti e domande, ricevi impressioni vaghe e inutilizzabili.

Iniziare il test chiuso troppo tardi. Se hai un account personale su Google Play, il periodo di test obbligatorio può spostare la data di lancio. Pianificalo dall'inizio.

Dimenticare che le build TestFlight scadono. I tester aprono l'app dopo qualche settimana e non funziona più: pensano che l'hai abbandonata.

In sintesi

Il beta test serve a trovare i bug che tu non puoi trovare, perché nascono da dispositivi, versioni del sistema, reti e abitudini diverse dalle tue. Non sostituisce i test automatici, li completa.

Su iOS si usa TestFlight, con tester interni senza revisione e tester esterni che richiedono una revisione beta di Apple, invitati via email o con un link pubblico. Le build hanno una durata limitata: verificala nella documentazione ufficiale.

Su Google Play ci sono tre canali: interno, chiuso e aperto. Per i nuovi account personali il test chiuso con un numero minimo di tester è un requisito per arrivare in produzione, quindi va pianificato.

Un beta test vale quanto le informazioni che raccogli: compiti precisi, domande specifiche, feedback con screenshot e crash report automatici.

Dopo il test viene la scheda dello store: come farla trovare e scaricare è spiegato nella guida all'ASO, e se devi ancora scegliere lo stack parti da come scegliere la tecnologia per un'app mobile. Per imparare a costruire e rilasciare un'app con metodo trovi i corsi.