Come testare la tua app creata con l'IA quando non hai mai testato software prima d'ora
Una guida pratica per testare un'app creata con l'IA quando non hai un background da QA. Dove cliccare, cosa rompere di proposito e come capire quando è abbastanza buona da condividere.
Hai creato un’app con l’IA. Funziona nel percorso felice — digiti il tuo nome, clicchi il pulsante, vedi la schermata di successo. E adesso? È pronta da mandare ai tuoi tre beta tester? Al tuo team? Ai tuoi clienti?
Se non hai un background nel software, il testing sembra una di quelle cose che fanno i “veri sviluppatori” — con framework, asserzioni e pipeline di CI. La buona notizia: non è questo che è davvero la maggior parte del testing. La maggior parte del testing, soprattutto quando pubblichi qualcosa di piccolo e nuovo, è una persona che clicca in giro con intenzione. Questo lo sai fare. Questo post parla di farlo di proposito, così trovi i bug prima che li trovino i tuoi utenti.
L’obiettivo non è testare la tua app creata con l’IA come un professionista. È testarla come un amico paranoico che vuole davvero che funzioni.
Il trucco delle due liste
Prima di cliccare qualsiasi cosa, siediti per dieci minuti con un documento vuoto e scrivi due liste.
Lista A — i percorsi felici. Quali sono le tre o quattro cose che un utente dovrebbe fare con quest’app? Per un tipico SaaS, potrebbero essere: iscriversi, creare il primo progetto, invitare un collega, esportare un risultato. Per un’app stile directory: cercare, filtrare, cliccare su un elemento, salvarlo. Tre o quattro flussi reali, in parole semplici.
Lista B — i percorsi infelici. E se l’utente facesse qualcosa di quasi giusto ma non del tutto? Digita la sua email con un refuso. Preme il pulsante indietro a metà flusso. Apre due schede e modifica la stessa cosa in entrambe. Invia un modulo vuoto. Incolla il contenuto di un documento Word — formattazione e tutto — in un campo di testo. Chiude il portatile e lo riapre dieci minuti dopo. Prova a invitare un collega usando un indirizzo email che esiste già nel sistema.
La lista dei percorsi felici è ciò per cui il tuo creatore di app con IA ha ottimizzato. È ciò che l’IA ha testato mentalmente mentre scriveva il codice. La lista dei percorsi infelici è dove vivono i bug, perché quasi nessuno — né l’IA, né tu mentre scrivevi i prompt — stava pensando a quei casi.
Quando testi davvero, percorri prima la Lista A per confermare che le basi funzionino. Poi passa la maggior parte del tempo sulla Lista B. La Lista B è dove sta il valore. La Lista B è anche dove scopri cosa vuoi davvero che faccia l’app quando le cose vanno storte, il che spesso costringe a una conversazione chiarificatrice con il creatore di app con IA (“quando il modulo è compilato a metà, deve avvisare o salvare in automatico?”).
Tre cose da rompere di proposito
Una volta che hai le tue liste, ecco tre categorie che intercettano la maggior parte dei bug reali nelle app create con l’IA.
Input vuoti e strani. Invia il modulo senza compilare nulla. Invialo con un solo campo compilato. Invia un nome lungo 500 caratteri. Invia un nome con un’emoji. Incolla un URL in un campo che si aspetta un nome. Prova il campo email con “test”, con “test@”, con “test@example”, con l’indirizzo “a@b.co” — accetta email corte ma legittime? I creatori di app con IA aggiungono spesso la validazione, ma la validazione può essere sbagliata in entrambe le direzioni — troppo severa (rifiuta utenti reali) o troppo permissiva (accetta spazzatura).
Andare indietro e di lato. La maggior parte delle app funziona benissimo se le percorri come un gruppo di turisti obbedienti. Si rompono nel momento in cui qualcuno esplora. Clicca il pulsante indietro. Clicca di nuovo avanti. Ricarica la pagina a metà di un flusso. Apri la stessa pagina in due schede e modifica in entrambe. Fai logout e rientra. Se hai un pulsante “annulla”, cliccalo tre volte di fila. Questi non sono casi limite. È così che le persone reali usano il software.
I dati a posteriori. Crea la cosa che la tua app crea. Un progetto, un post, un record, qualunque cosa. Poi torna domani. C’è ancora? La formattazione è sopravvissuta? Se la modifichi, la modifica si salva? Se la cancelli, è davvero sparita, o ritorna quando ricarichi? I creatori di app con IA spesso azzeccano il flusso di “creazione” e dimenticano che tutto ciò che crei deve persistere ed essere modificabile più avanti.
Che aspetto ha “abbastanza buono”
Non testerai mai la tua app creata con l’IA alla perfezione. Il software è troppo aggrovigliato e il tuo tempo è troppo prezioso. La domanda non è “è perfetta” — è “è abbastanza buona per il prossimo gruppo di persone a cui la metterò davanti”.
Ecco una gerarchia approssimativa che puoi prendere in prestito.
Abbastanza buona per una demo: il percorso felice funziona senza crash. I pulsanti vanno dove dovrebbero. Puoi mostrare una registrazione dello schermo senza tagliare nulla.
Abbastanza buona per utenti amici: i percorsi infelici non perdono dati. I moduli ti dicono cosa c’è che non va invece di fallire in silenzio. Ricaricare la pagina non rompe le cose. Tre amici possono usarla senza scriverti per chiedere aiuto.
Abbastanza buona per utenti paganti: l’app gestisce utenti che non hai mai conosciuto. I loro browser, i loro dati, le loro abitudini. Hai un modo per vedere quando le cose si rompono (un tracciamento di base degli errori basta — non ti serve una dashboard sofisticata). Sai correggere e ripubblicare senza rompere le cose per chi la sta già usando.
La maggior parte dei creatori pubblica al livello “utenti amici” e poi migliora man mano che arriva il feedback. È corretto. L’errore è provare a saltare da “abbastanza buona per una demo” direttamente a “abbastanza buona per utenti paganti” senza il passaggio intermedio. Gli utenti amici trovano cose che troverebbero anche quelli reali — ma non si arrabbiano. Sfrutta quel margine.
Quando chiedere all’IA di testare per te
Il tuo creatore di app con IA può aiutarti con il testing, ma devi essere specifico su cosa vuoi. “Aggiungi dei test” è un brutto prompt. Genererà codice che sembra fatto di test e probabilmente passa, senza controllare davvero nulla che ti interessi. La maggior parte di quei test generati in automatico conferma che 1+1 fa ancora 2.
Un prompt migliore: “Ho appena provato a inviare il modulo di iscrizione con il campo email vuoto e ha fatto crash. Trova dove viene gestito e aggiungi un controllo che mostri un errore comprensibile invece di crashare.” Bug specifico, correzione specifica, esito specifico. L’IA è brava in questo. È pessima a “assicurati che la mia app non abbia bug” perché quello non è un compito — è un desiderio.
L’altra cosa in cui i creatori di app con IA sono bravi è riprodurre il tuo bug. Se descrivi cosa hai fatto, cosa ti aspettavi e cosa è successo, il creatore di solito riesce a ripercorrere il codice e proporre una correzione. La disciplina che ti serve è quella di mettere per iscritto quelle tre cose in modo chiaro. La maggior parte delle segnalazioni di bug dei principianti è una qualche versione di “non funziona”. La maggior parte delle segnalazioni risolvibili è “ho cliccato X, mi aspettavo Y, ho ottenuto Z”.
Testare è leggere, non solo cliccare
Un’ultima cosa. Non devi capire ogni riga di codice della tua app creata con l’IA per testarla bene. Ma dovresti almeno dargli un’occhiata. Apri il file che l’IA ha appena modificato. Leggi la funzione che ha aggiunto. Non ti serve sapere cosa significa ogni parola chiave — ti serve sapere se la funzione sembra fare ciò che hai chiesto.
Molti bug delle app create con l’IA non sono “il codice è rotto”. Sono “il codice fa qualcosa di leggermente diverso da quello che volevi”. Un campo si salva nel posto sbagliato. Un pulsante aggiorna una cosa ma non quella collegata. Un pulsante “cancella” nasconde invece di cancellare. Non puoi intercettarli senza leggere ciò che è stato effettivamente costruito.
Tratta il codice come qualcosa che puoi controllare, non come qualcosa che devi scrivere. È questa la differenza tra un’app creata con l’IA di cui ti fidi e una che speri soltanto funzioni.
La versione semplice
Se non ricordi nient’altro: scrivi le due liste, rompi le cose di proposito e decidi a quale livello di “abbastanza buona” stai pubblicando. La maggior parte dei bug in un’app creata con l’IA non è sottile. Se ne sta lì sulla lista dei percorsi infelici che nessuno si è preso la briga di scrivere.
Se vuoi un piccolo compito a casa: scegli un’app che hai costruito e prova quattro cose — invia un modulo vuoto, ricarica a metà flusso, modifica un record e ricontrollalo domani, e chiedi a un amico di usarla senza che tu guardi. Qualunque cosa si rompa è la tua vera lista di bug. Tutto il resto è procrastinazione.