Come testare la tua app prima del lancio: un piano pratico

Per testare la tua app prima del lancio, elenca i pochi percorsi che un utente deve poter completare, eseguili come utente completamente nuovo su computer e telefono, poi prova i modi in cui possono andare storti: dati vuoti, input errati, un secondo account, una connessione lenta. Testa con particolare cura tutto ciò che riguarda denaro o dati privati, e ripeti i percorsi principali sull’URL live dopo la pubblicazione. Concludi osservando qualcuno che non ha mai visto l’app provare a usarla.

Non ti servono un team di QA né un framework di test per questo. Ti servono una lista, un’ora o due e la disciplina di percorrerla davvero.

Passo 1: scrivi i percorsi che contano

Un percorso è un’attività completa, dall’inizio alla fine, che un utente viene a svolgere. La maggior parte delle app ne ha tre-sei che contano davvero. Per un’app di prenotazioni:

Registrarsi e confermare l’account
Trovare una lezione e prenotarla
Cancellare una prenotazione
Pagare un abbonamento alle lezioni
Staff: vedere le prenotazioni di oggi

Se hai scritto le user story, i loro criteri di accettazione sono già i tuoi casi di test. Se no, scrivi una riga per percorso con ciò che significa «successo».

Dagli una priorità. I percorsi che generano denaro o che ogni utente percorre (registrazione, login, l’azione principale) si testano per primi e con più attenzione.

Passo 2: testa il percorso ideale come nuovo utente

Il «percorso ideale» è il percorso che va esattamente come previsto. Testalo come lo vivrebbe un estraneo:

Usa una finestra di navigazione privata, così non sei loggato e non hai dati salvati.
Usa un account nuovo con un’email vera a cui puoi accedere.
Parti dalla home page o da un link, non da una pagina salvata nei preferiti mentre costruivi l’app.

Gli utenti nuovi non hanno dati. Molti bug compaiono solo quando una lista è vuota, un profilo non ha foto o non è stato ancora acquistato nulla. Il tuo account, pieno di dati di test, nasconde questi problemi.

Passo 3: prova a romperla

Ora ripeti ogni percorso e fai di proposito la cosa sbagliata.

Prova questo	Cosa verifichi
Invia moduli vuoti o con solo spazi	I campi obbligatori sono imposti, con un messaggio chiaro
Testi molto lunghi, emoji, nomi con accenti	Il layout regge, i dati si salvano correttamente
Formati errati: lettere in un campo telefono, una data passata	Validazione sia nella pagina sia sul server
Doppio clic sul pulsante di invio	Nessun ordine o prenotazione duplicata
Pulsante indietro del browser a metà percorso	Nessuno stato rotto o dato perso
Ricarica su ogni pagina	I dati restano; nessuna pagina bianca o 404
Esci, poi premi indietro	Le pagine private non si vedono più
Due schede che modificano la stessa cosa	L’ultimo salvataggio non cancella in silenzio il primo

La ricarica merita un’attenzione particolare: se l’app funziona quando clicchi, ma ricaricando una pagina più profonda compare un 404, consulta come risolvere gli errori 404 dopo il deploy.

Passo 4: testa i permessi con due account

È il test più importante per ogni app con account, e quello più spesso saltato.

Crea due utenti normali, A e B, e (se l’app li prevede) un amministratore.

Come A, crea un record. Accedi come B. B può vederlo, modificarlo o eliminarlo? Non dovrebbe, a meno che non sia questa l’intenzione.
Come A, copia l’URL di uno dei tuoi record. Accedi come B e apri quell’URL direttamente.
Come utente normale, apri le pagine di amministrazione digitando i loro URL.
Esci del tutto e prova gli stessi URL.

Se trovi un problema qui, non lanciare finché non è risolto. Il controllo deve avvenire sul server, non solo nascondendo un pulsante. La nostra checklist di sicurezza per le app create con l’IA approfondisce.

Passo 5: testa su dispositivi reali

Apri l’app su un telefono vero, non solo in una finestra stretta del browser.

Riesci a toccare ogni pulsante senza ingrandire?
La tastiera copre il campo in cui stai scrivendo?
Tabelle e contenuti larghi scorrono o vanno a capo, invece di spingere la pagina di lato?
Il testo è leggibile senza pizzicare?

Prova almeno un iPhone (Safari) e un telefono Android (Chrome), se riesci a prestarli. Safari in particolare ha alcune peculiarità con date, video ed elementi a posizione fissa.

Passo 6: testa denaro ed email dall’inizio alla fine

Tutto ciò che addebita carte o invia email richiede una verifica completa.

Pagamenti. Usa la modalità test del tuo fornitore di pagamenti e i numeri di carta di prova. Verifica un pagamento riuscito, una carta rifiutata e un checkout annullato. Conferma che l’ordine o l’abbonamento compaia nella tua app dopo il pagamento, non solo nella dashboard del fornitore. Se la tua app dipende da webhook (messaggi che il fornitore di pagamenti invia al tuo server), verifica che arrivino sull’app pubblicata, non solo in sviluppo. Poi, prima del lancio, passa alle chiavi live e fai un piccolo acquisto reale che rimborserai.

Email. Registra due o tre indirizzi reali presso fornitori diversi. Verifica che le email arrivino, non finiscano nello spam, e che ogni link punti al dominio live, non a un indirizzo di anteprima.

Passo 7: controlla velocità ed errori

Apri gli strumenti per sviluppatori del browser (clic destro → Ispeziona) e guarda la scheda Console di ogni pagina principale. Gli errori in rosso meritano di essere corretti anche se nulla sembra rotto.
Carica il sito su un telefono usando la rete dati, non il Wi-Fi. Se la prima schermata impiega diversi secondi, controlla prima le dimensioni delle immagini.
Esegui un audit gratuito come Lighthouse negli strumenti di Chrome per una lettura rapida di prestazioni e accessibilità.

Passo 8: testa l’app pubblicata, non solo l’anteprima

Anteprima e app pubblicata non sono lo stesso ambiente. Prima di parlarne a qualcuno, ripeti i percorsi principali sull’URL live:

Tutte le variabili d’ambiente e i segreti sono impostati per l’app pubblicata?
Usa il database giusto, con i dati che ti aspetti?
I reindirizzamenti dopo il login e i link nelle email usano il dominio live?
Una ricarica su una pagina profonda si carica correttamente?

Passo 9: osserva qualcun altro usarla

Dai a una o due persone un obiettivo («prenota una lezione di yoga per sabato»), non istruzioni. Osserva senza aiutare e annota dove esitano. È il modo più rapido per trovare formulazioni confuse e pulsanti nascosti. Per una versione più ampia, vedi come fare un beta test.

Quando trovano un bug, scrivilo in modo corretto, con i passaggi, il risultato atteso e quello ottenuto. La nostra guida su come scrivere una buona segnalazione di bug mostra il formato.

Usare l’IA per aiutarti a testare

Se costruisci con l’IA, puoi chiederle di aiutarti a pianificare ed eseguire i test:

Elenca i principali percorsi utente di questa app e, per ciascuno, i casi limite più probabili a rompersi: stati vuoti, input non validi, permessi e ricarica. Mettili in una checklist che posso seguire.

Accedi con due utenti di prova diversi e verifica se l’utente B può vedere o modificare qualcosa creato dall’utente A, anche aprendo direttamente gli URL dei record di A. Segnala ciò che trovi prima di correggere qualsiasi cosa.

Considera il report di test dell’IA come una prima verifica. Percorri comunque tu, di persona, i percorsi legati a denaro e permessi.

Testare in Mythex

In Mythex, il comando /test avvia App Testing: l’agente guida un browser sulla tua anteprima live, naviga le pagine, cattura screenshot e segnala in chat i flussi rotti. Funziona meglio con un percorso specifico, come «testa la registrazione e la prenotazione di una lezione». Correggi ciò che trova con /fix o con un normale messaggio, poi esegui di nuovo /test. App Testing usa l’anteprima, quindi dopo la pubblicazione controlla tu i percorsi principali sull’URL pubblicato. Vedi App Testing nella documentazione e la nostra guida su come fare debug di un’app creata con l’IA per quando qualcosa fallisce.

Errori comuni

Testare solo come te stesso. Il tuo account admin con molti dati nasconde i bug legati agli stati vuoti e ai permessi.
Testare solo su computer. Per molti siti la maggior parte dei visitatori arriva da telefono.
Saltare il secondo account. La fuga di dati tra utenti è il bug più grave con cui un’app possa essere lanciata.
Fidarsi dell’anteprima. L’app live ha impostazioni diverse; testa anche quella.
Correggere bug senza ritestare ciò che è vicino. Una correzione a un modulo può rompere un altro che condivide lo stesso codice.

Checklist pre-lancio

Percorsi principali elencati e ordinati per priorità
Ogni percorso supera come nuovo utente in una finestra privata
Input vuoti, non validi, lunghi e duplicati gestiti
La ricarica funziona su ogni pagina
Gli utenti non possono vedere o modificare i dati degli altri, nemmeno tramite URL
Pagine di amministrazione bloccate per utenti normali e visitatori non connessi
Funziona su un iPhone reale e un telefono Android reale
Pagamenti testati: successo, rifiuto, annullamento, e l’app si aggiorna dopo
Le email arrivano, evitano lo spam e linkano al dominio live
Nessun errore rosso in console nelle pagine principali
Percorsi principali ripetuti sull’URL pubblicato
Almeno una persona esterna l’ha provata mentre la osservavi

Domande

Quanto test serve a una app piccola prima del lancio?

Abbastanza da essere sicuri che i percorsi principali funzionino per un utente completamente nuovo su telefono e computer, che gli utenti non possano vedere i dati degli altri e che tutto ciò che riguarda il denaro funzioni dall’inizio alla fine. Per la maggior parte delle app piccole bastano poche ore mirate, non settimane.

Per un MVP servono test automatici?

Non necessariamente. Il test manuale dei percorsi principali individua la maggior parte dei bug che bloccherebbero il lancio. I test automatici diventano utili quando cambi spesso l’app e vuoi sapere in fretta se hai rotto qualcosa che prima funzionava.

Devo testare l’anteprima o l’app live?

Entrambe. Testa a fondo l’anteprima, poi ripeti i percorsi principali sull’app pubblicata, perché variabili d’ambiente mancanti, un database diverso o impostazioni di routing possono far comportare la versione live in modo diverso.

Chi, oltre a me, dovrebbe testare l’app?

Almeno una persona che non l’ha mai vista. Dalle un obiettivo, non istruzioni, e osservala senza aiutarla. Chi costruisce l’app evita inconsciamente i percorsi che si rompono.