Verificare percorsi completi, non singole risposte
Un test utile non raccoglie soltanto alcune risposte riuscite, ma segue percorsi completi: prima sessione, account di ritorno con cronologia, cambio di lingua e modalità, dispositivo condiviso, collegamento interrotto, blocco e segnalazione, acquisto, esportazione, cancellazione e comportamento dopo un aggiornamento. Ogni percorso parte da un limite atteso e termina con una verifica del recupero. Il programma ARIA del NIST distingue test del modello, red teaming e test sul campo: una risposta è quindi solo un livello del prodotto. Usa contenuti fittizi neutrali, account dedicati e controlli ordinari. Non inserire dati altrui e non cercare risultati pericolosi. Registra ciò che è successo, ciò che resta sconosciuto e se l’utente può tornare a uno stato comprensibile.
Preparare una scheda in sette campi
Scrivi contesto, stato account, variazione dell’input, limite atteso, risultato osservabile, percorso di recupero e prova conservata. Il contesto contiene dispositivo, versione, lingua, rete e piano. Lo stato distingue nuovo utente, ritorno con cronologia, restrizione, uscita o cancellazione in attesa. Cambia lunghezza, tono, ortografia, lingua e modalità mantenendo lo stesso compito. L’attesa descrive un comportamento concreto, non “funziona bene”. Registra messaggi, visibilità dei dati, azioni esterne e cambi di stato. Verifica annullamento, ripetizione, blocco, segnalazione, cancellazione del pagamento, uscita e assistenza. Elimina password, token e contenuti di terzi dalle prove. Ripetere la scheda dopo una versione crea un confronto reale.
Coprire identità, memoria e passaggi tra dispositivi
Verifica registrazione, recupero account, elenco sessioni, uscita e rientro da un secondo dispositivo. Confronta una sessione nuova, un account con cronologia e lo stesso account dopo averla eliminata. Su un dispositivo condiviso controlla anteprime delle notifiche, schermata delle app recenti, riempimento automatico, media scaricati e accesso locale dopo l’uscita. Cambia separatamente lingua dell’interfaccia e dell’input; una traduzione visiva non prova che controlli e risposte rispettino gli stessi limiti. Interrompi bozza, caricamento, acquisto o cancellazione con modalità aereo, passaggio in background, riavvio o sessione scaduta. Cerca duplicazioni, perdite e stati ambigui, difficili da vedere in una conversazione continua.
Provare testo, voce, immagini e contenuti esterni
Ogni superficie ha autorizzazioni, trasformazioni, archiviazione ed errori diversi. Esprimi un compito fittizio innocuo con frasi brevi, lunghe, con refusi, citazioni, ipotesi e lingue miste. Per la voce osserva momento del permesso, indicatore di registrazione, trascrizione, eliminazione e alternativa all’errore. Per l’immagine usa materiale neutro creato da te e controlla caricamento, anteprima, rimozione, metadati dichiarati e interruzione. Se l’app apre link, file, pagine o strumenti, includi testo esterno innocuo ma in conflitto con la richiesta e controlla che l’intento dell’utente resti prioritario. I rischi OWASP mostrano che manipolazione degli input e divulgazione di informazioni si verificano ai confini dell’applicazione, non soltanto nella formulazione.
Seguire i controlli di interazione fino alla fine
Se sono possibili messaggi, follow, commenti, regali o spazi, verifica impostazioni di scoperta, pubblico, silenziamento, blocco, segnalazione, conservazione delle prove, informazioni sul ricorso e stato su entrambi gli account. Il blocco non è convalidato se cambia una schermata ma lascia notifiche, vecchi link, gruppi o un altro canale. Usa due account di prova chiaramente nominati e non coinvolgere persone inconsapevoli. Per la segnalazione impiega contenuto innocuo e fermati prima dell’invio se caricaria una coda reale senza percorso di test. Distingui il controllo funzionante dalla risoluzione verificata: tempo e risultato possono rimanere sconosciuti e vanno registrati in questo modo.
Aggiungere denaro, uscita e regressione dopo gli aggiornamenti
Controlla livello gratuito, fine della prova, avviso di rinnovo, autenticazione, pagamento fallito, annullamento, scadenza dei diritti e differenza tra eliminare l’account e fermare la fatturazione dello store. Usa strutture di prova sicure quando disponibili ed evita acquisti inutili. Verifica esportazione, eliminazione singola, richiesta di cancellazione account, conferme dichiarate e visibilità durante l’attesa. Dopo cambi di app, modello, politica, permessi o pagamento, ripeti i percorsi importanti. Google raccomanda dati propri del prodotto e input diversi, perché i benchmark generici non descrivono ogni configurazione. Mantieni una breve regressione con dispositivo condiviso, upload interrotto, utente bloccato, abbonamento terminato e cronologia eliminata.
Valutare la copertura attraverso il recupero
Una risposta elegante non compensa una cancellazione persa, una visibilità inattesa, un costo incerto, un caricamento fermo o un controllo irreversibile. Raggruppa le schede in confermato, condizionato, contraddetto e sconosciuto. Dai priorità agli sconosciuti che uniscono dati, azioni esterne, denaro o stato difficile da invertire. Un errore deve indicare stato iniziale, riproduzione minima, risultato visibile, tentativo di recupero e versione; “l’AI ha fallito” è troppo generico. Anche un superamento dichiara il proprio ambito. La regola pratica è che, quando il percorso ideale si rompe, una persona comune possa vedere lo stato, capire l’evento e raggiungere un passo successivo documentato. In caso contrario, il test resta aperto.
Domande frequenti
Quanti input bisogna provare?
Non esiste un numero universale. Copri percorsi, variazioni, limiti e recupero, aggiungendo casi da modifiche ed errori reali.
Un utente deve tentare attacchi al modello?
No. Le prove specialistiche richiedono un ambiente autorizzato e controllato.
Un buon benchmark del modello basta?
No. L’app comprende account, cronologia, permessi, strumenti, interazioni, pagamenti, archiviazione e recupero.