Internal Testing: cos'è, come funziona e come configurare il track

Cos'è Internal Testing?

Internal Testing è un track di test in Google Play Console e TestFlight progettato per distribuire build tra i membri del team di sviluppo. A differenza dei test beta aperti, l'accesso a Internal Testing è limitato a un elenco di indirizzi email approvati dal proprietario dell'account sviluppatore.

Il vantaggio principale è il tempo di consegna minimo del build ai tester. In Google Play, Internal Testing non richiede moderazione — il build appare ai partecipanti entro 5–15 minuti dal caricamento. Nell'App Store tramite TestFlight, il build viene consegnato senza App Review preliminare, ma è soggetto a una verifica automatica dei requisiti di sicurezza di base.

Come Internal Testing si differenzia dagli altri track

Google Play ha tre track di test: Internal Testing, Closed Beta (Open Beta) e Produzione. Internal Testing è il più veloce e limitato nel numero di partecipanti (fino a 100 persone). Closed Beta consente fino a 10.000 partecipanti e richiede la configurazione di una pagina di test. La Produzione è la fase finale con moderazione completa.

Quando utilizzare Internal Testing

Internal Testing viene utilizzato per la verifica iniziale dei build prima di passarli ai track beta. Gli sviluppatori caricano build giornalieri per il team QA, verificano l'integrazione di nuovi SDK, testano la compatibilità con diverse versioni del SO e identificano errori di regressione prima che il build venga visto da tester esterni.

Internal Testing in Google Play

In Google Play Console, Internal Testing è un track separato disponibile nella sezione Release → Testing. Per aggiungere un tester, basta inserire il suo indirizzo email — il partecipante riceve un invito e un link per partecipare tramite Google Play. I build vengono caricati attraverso la stessa interfaccia delle versioni di produzione.

Processo di pubblicazione nel track Interno

Lo sviluppatore carica un App Bundle o APK nella sezione Internal Testing di Google Play Console. Il sistema verifica i requisiti di base: firma, versione del codice e compatibilità API. Dopo 5–15 minuti di elaborazione, il build diventa disponibile per i tester. Lo stato viene monitorato nella console: Bozza, In revisione, Pronto per il test.

// Fastlane — pubblicazione nel track Internal Testing
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

Gestione dei tester

L'aggiunta dei partecipanti avviene tramite la sezione Testers in Google Play Console. È supportato il caricamento di gruppo tramite file CSV. Ogni tester riceve un'email con un invito e le istruzioni di installazione. Per revocare l'accesso, basta rimuovere il partecipante dal gruppo — l'app installata continua a funzionare, ma i nuovi aggiornamenti non arrivano.

Internal Testing nell'App Store tramite TestFlight

Nell'ecosistema Apple, il ruolo di Internal Testing è svolto da TestFlight — una piattaforma per distribuire versioni beta. TestFlight supporta fino a 100 tester interni, aggiunti via email tramite App Store Connect. La pubblicazione di un build non richiede un App Review completo, ma il build viene verificato automaticamente per i requisiti minimi.

Caratteristiche di TestFlight Internal Testing

A differenza di Google Play, dove Internal Testing non richiede alcuna moderazione, Apple esegue una revisione di base automatica. La verifica richiede 30–60 minuti e include la scansione del codice binario per API dannose e la conformità ai requisiti di base. Dopo una verifica riuscita, il build è disponibile per i tester entro 24 ore. Il build è valido per 90 giorni.

Configurazione di Internal Testing in App Store Connect

In App Store Connect, Internal Testing viene configurato nella sezione TestFlight → Internal Testing. Il proprietario dell'account aggiunge i tester via email e assegna i ruoli. Dopo il caricamento di un build tramite Xcode o Transporter, il sistema notifica i partecipanti della disponibilità di una nuova versione. I tester installano l'app tramite l'app TestFlight sul proprio dispositivo.

Come configurare un track Internal Testing

La configurazione di Internal Testing per entrambe le piattaforme richiede da 10 a 30 minuti. Di seguito sono riportate le istruzioni passo passo per Google Play e App Store. Il processo non richiede modifiche al codice dell'app — è sufficiente una configurazione una tantum della console sviluppatore.

Integrazione con sistemi CI/CD

Entrambi gli store supportano la pubblicazione in Internal Testing tramite API. Per l'automazione si utilizzano Gradle Play Publisher (Google Play) e Fastlane (entrambe le piattaforme). La pipeline CI/CD può caricare build nel track Interno dopo ogni esecuzione riuscita di test unitari e test UI.

Configurazione degli account di test

Per le app con autenticazione, è necessario preparare account di test e fornirli al team QA. Gli account devono avere accesso all'ambiente di test (staging/development) e non devono influenzare i dati di produzione. Si consiglia di creare una configurazione Firebase di test separata per il track Interno.

Flusso di lavoro QA con Internal Testing

Internal Testing viene integrato nella pipeline QA dopo aver superato i controlli automatici in CI. Lo sviluppatore o l'ingegnere DevOps carica il build nel track Interno, dopo di che gli ingegneri QA ricevono una notifica e installano l'aggiornamento sui dispositivi di test tramite lo store delle app.

Frequenza di pubblicazione ottimale

Si consiglia di pubblicare build in Internal Testing quotidianamente o dopo ogni modifica significativa nella base di codice. Il team QA testa gli scenari critici: autenticazione, flusso utente principale, integrazione API e operazioni di archiviazione locale. I test di regressione vengono eseguiti ogni terzo o quarto build.

Strumenti per la raccolta di feedback

Per raccogliere segnalazioni di bug, utilizzare l'integrazione con sistemi di tracciamento: Jira, YouTrack, Trello o GitHub Issues. I tester inviano screenshot, log e passaggi di riproduzione. TestFlight supporta nativamente la raccolta di screenshot e log del dispositivo tramite scuotimento — i dati vengono inviati allo sviluppatore tramite App Store Connect.

Integrazione con pipeline CI/CD

Per pubblicare automaticamente i build nel track Internal Testing, configurare una pipeline CI/CD. Dopo aver superato i test unitari e i test UI, lo script carica il build nel track Interno e invia una notifica al team QA. Fastlane fornisce l'azione pronta all'uso upload_to_play_store con il parametro track: internal. Per iOS, utilizzare Fastlane Pilot per caricare su TestFlight.

Limitazioni e vincoli di Internal Testing

Internal Testing ha limiti rigorosi sul numero di partecipanti: fino a 100 persone in Google Play e fino a 100 tester interni in TestFlight. Google Play limita inoltre il numero di gruppi — massimo 1 gruppo per il track Interno. L'App Store non limita il numero di build, ma ogni build ha una validità di 90 giorni.

Differenze nei limiti tra le piattaforme

Google Play non limita il numero di build caricati nel track Interno, ma dopo 90 giorni di inattività, il track può essere sospeso automaticamente. TestFlight ha limiti più severi: fino a 30 build attivi contemporaneamente, fino a 10.000 tester esterni (non Interni). Per rimuovere le restrizioni, è necessaria la partecipazione al programma Apple Developer Enterprise.

Migrazione da Interno a Open Beta

Dopo aver stabilizzato il build nel track Interno, viene spostato in Closed o Open Beta per il test con un pubblico esterno. Google Play consente di copiare le impostazioni del track e trasferire il build senza ricaricarlo. TestFlight richiede la creazione di un track esterno separato con nuovi gruppi di tester.

Sicurezza del track Internal Testing

I build nel track Interno sono protetti da accessi esterni: solo i partecipanti autorizzati tramite Google Play Console o App Store Connect possono scaricare l'app. Anche se qualcuno conosce il link dell'app, un utente non autorizzato non può installare il build. Ciò garantisce la riservatezza delle nuove funzionalità e protegge la proprietà intellettuale durante la fase di sviluppo.