In questa guida
Un emulatore è un buon primo passaggio. È veloce e gratuito, e puoi tenerlo nella stessa finestra dell'editor. Ma è un modello di telefono, e i dettagli che un modello tralascia sono proprio quelli che incontrano gli utenti reali. Vale per ogni app, comunque sia stata fatta. Conta un po' di più quando non hai scritto ogni riga, perché hai meno idea di dove possa essere fragile.
Cosa mostra un telefono reale
- Velocità e calore. Una schermata fluida sul computer può scattare su un telefono più vecchio o più economico. Scorri liste lunghe, apri la schermata più pesante e usa l'app per dieci minuti.
- Permessi. Fotocamera, posizione, notifiche, archiviazione: tocca "Consenti", poi "Non consentire", poi disattivalo più tardi nelle impostazioni di sistema. L'app si spiega e funziona ancora?
- La tastiera. Copre il campo di input? Compare il tipo di tastiera giusto per email o numeri? Cosa succede quando la chiudi con il gesto indietro?
- Interruzioni. Una chiamata, una notifica, il cambio di app, la rotazione dello schermo, il timeout della schermata di blocco. Torni all'app: il tuo input c'è ancora?
- Connessioni reali. Segnale debole, passaggio da Wi-Fi a dati mobili, modalità aereo. Vedi testare il comportamento offline.
- Tocco e dimensioni. I pulsanti si colpiscono facilmente con il pollice? Il testo entra su uno schermo piccolo e con font di sistema grandi?
- Installazione e aggiornamento. Installa da zero la build di rilascio, poi aggiorna sopra una build più vecchia. I dati sopravvivono?
Nulla di tutto questo si verifica in modo convincente dal desktop.
Un breve piano dei dispositivi
Non ti serve un cassetto pieno di telefoni. Copri le differenze, non la quantità. Questa tabella non contiene dati di quota di mercato di proposito; scegli tra quelli a cui puoi accedere.
| Slot | Perché | Dove trovarlo |
|---|---|---|
| Il tuo telefono | Uso quotidiano, abitudini reali | Ce l'hai già |
| Un telefono più vecchio o più economico | Mostra i limiti di velocità e memoria | Un amico, la famiglia, uno di seconda mano |
| Un telefono con uno schermo di dimensione diversa | Problemi di layout | Come sopra |
| Una versione di sistema diversa | Comportamento e finestre di permesso cambiano tra versioni | Come sopra, o un tester |
| Una persona che non è sviluppatrice | Trova i passi che hai smesso di vedere | Chiedi |
Quali modelli e versioni dare priorità è trattato in quali dispositivi Android dovresti testare davvero.
Quando non riesci a procurarti i dispositivi
Chiedi ai tester. Il feedback privato e strutturato di persone sui propri telefoni ti dà dispositivi che non possiedi, e il report include modello e versione del sistema. Chiedilo esplicitamente nel tuo brief di test.
Per Google Play, il requisito del test chiuso mette già la tua app davanti ai telefoni di altre persone. Vedi i requisiti del test chiuso (DE) e cosa conta come 14 giorni (DE). Usa quei giorni per feedback reali, non solo come contatore.
Un controllo di 30 minuti
- Installa la build di rilascio su un telefono reale.
- Primo avvio, registrazione, flusso principale, dall'inizio alla fine.
- Nega ogni permesso una volta, concedilo una volta.
- Interrompi l'app in tre modi: chiamata o notifica, cambio di app, rotazione.
- Attiva la modalità aereo a metà di un flusso.
- Annota ogni problema con passi, risultato atteso, risultato effettivo e dispositivo. Poi usa il template di prompt se correggi con un assistente.
Dove si inserisce AppReviewX
AppReviewX ti dà feedback privati e strutturati da altri sviluppatori sui loro telefoni. Un feedback che scrivi vale un credito, i crediti servono a ottenere feedback sulla tua app, e i nuovi account partono da 0 crediti. Per Android ci sono gruppi di test con 12 tester per 14 giorni consecutivi, come richiesto da Google Play.
Correlati: hub sul vibe coding, come testare prima del lancio, checklist di lancio.