1) Preparazione dell’ambiente di test

1.1 Dati e configurazioni

• Ambiente: definisci chiaramente se stai testando su staging, pre-prod o prod con feature flag.
• Provider email: prepara almeno due scenari: email temporanea e email “classica” per confronto.
• Clock/Time: verifica se l’ambiente usa un NTP affidabile. I bug su scadenze OTP spesso derivano da drift.
• TTL OTP: annota durata OTP, finestra di resend, limite tentativi, e policy lockout.
• Template: controlla che i template dell’email includano il codice, scadenza, e istruzioni chiare.

1.2 Strumenti utili

• Browser con profili separati (per simulare più utenti/gestire cookie e sessioni in modo pulito).
• Un metodo per simulare rete lenta o intermittente (throttling) per testare UX e idempotenza.
• Accesso ai log applicativi e ai log del provider email (o almeno agli eventi di delivery/bounce, se disponibili).
• Un identificatore di correlazione (request_id / trace_id) visibile in UI o copiabile per debugging.

2) Checklist “Happy Path” (flusso ideale)

2.1 Registrazione base

1. Apri una nuova email usa-e-getta e copia l’indirizzo senza errori (spazi, caratteri invisibili, newline).
2. Compila la form di signup con dati validi e invia.
3. Verifica che la UI indichi chiaramente che è stata inviata una mail con OTP (senza rivelare se l’email esiste già).
4. Attendi la ricezione e controlla:
   • presenza del codice OTP o del link magic;
   • oggetto e mittente coerenti;
   • testo leggibile e non troncato su mobile;
   • assenza di contenuti confusi o eccessivamente tecnici.
5. Inserisci OTP e completa la verifica. Verifica che:
   • si arrivi allo stato “account verificato”;
   • si mantenga la sessione;
   • si applichino redirect corretti (dashboard, onboarding, home, ecc.).

2.2 Post-verifica

• Prova login/logout immediato (se previsto) per confermare che l’account è attivo.
• Verifica che il sistema non richieda OTP “di nuovo” senza motivo (loop di verifica).
• Controlla la pagina profilo: email salvata correttamente, status verificato coerente.

3) Deliverability e tempi: ritardi, retry, e resilienza

Le email temporanee possono introdurre ritardi o filtrare alcune tipologie di messaggi. Per questo, il test non deve limitarsi a “arriva/non arriva”. Devi capire come reagisce il prodotto quando l’OTP è lento, duplicato o non consegnato.

3.1 Ritardo di consegna

• Misura il tempo tra submit del signup e arrivo dell’OTP (più tentativi, diversi orari).
• Verifica che la UI mostri un messaggio utile se l’email non arriva entro un tempo ragionevole (senza allarmismi).
• Controlla che “Resend OTP” abbia:
  • cooldown visibile (timer);
  • messaggio chiaro su quando puoi riprovare;
  • accessibilità (screen reader, focus management).

3.2 Duplicati e ordering

• Premi “Resend” più volte rispettando il cooldown e osserva:
  • arrivano più email? in che ordine?
  • gli OTP precedenti diventano invalidi subito o restano validi fino a scadenza?
• Prova a inserire un OTP vecchio dopo aver richiesto un nuovo OTP:
  • l’errore deve essere preciso (codice non valido o scaduto), senza rivelare dettagli sensibili;
  • la UI deve guidare al passo successivo (richiedi nuovo codice).

3.3 Mancata consegna

• Se l’OTP non arriva, verifica che esista un percorso alternativo (resend, cambio email, supporto) senza dead-end.
• Controlla che il backend gestisca bounce/blocked senza bloccare indebitamente l’utente legittimo.

4) Validazione input e casi limite sulla form

4.1 Email e formattazione

• Email con maiuscole/minuscole: normalizzazione coerente (di solito case-insensitive).
• Spazi prima/dopo l’email: trimming lato client e server.
• Caratteri non ASCII o formati borderline: gestione corretta, messaggi comprensibili.
• Dominio usa-e-getta: se blocchi alcuni domini, verifica:
  • messaggio chiaro e rispettoso;
  • assenza di false positive;
  • fallback consigliato (usa un indirizzo alternativo).

4.2 OTP input

• Lunghezza OTP: accetta solo la lunghezza prevista, rifiuta valori parziali con feedback immediato.
• OTP con spazi: se copiato da email, spesso include spazi o newline; la UI deve gestire paste pulito.
• Inserimento da mobile: tastiera numerica, auto-advance tra campi (se multi-field), backspace intuitivo.
• Accessibilità: focus visibile, aria-labels, supporto a lettori di schermo.

5) Scadenze e stati: cosa succede quando il tempo passa

La scadenza OTP è un punto dolente tipico. Non basta verificare che “scade”: bisogna verificare che lo faccia bene, in modo coerente con UI e backend.

5.1 OTP scaduto

• Richiedi OTP e aspetta oltre TTL. Inserisci il codice: deve essere rifiutato con messaggio “scaduto”.
• Verifica che la UI proponga subito “Invia nuovo codice” e non costringa a tornare indietro.
• Controlla che non si creino stati fantasma: utente “mezzo registrato” senza percorso di recupero.

5.2 Link magic / deep link (se usati)

• Apri il link su stesso device e su device diverso: comportamento definito e sicuro.
• Apri il link due volte: il secondo tentativo deve essere gestito (già usato / non valido) senza crash e senza loop.
• Apri il link dopo scadenza: messaggio chiaro e azione successiva (nuovo link).

6) Resend, rate limit e anti-abuse

I flussi OTP sono una superficie d’attacco. Il QA deve verificare che le difese non distruggano la UX e che la UX non distrugga le difese.

6.1 Resend e cooldown

• Cooldown visibile e coerente: se il backend impone 30s, la UI non deve mostrare 10s.
• Durante il cooldown, il pulsante deve essere disabilitato e spiegare il motivo.
• Quando il resend riesce, feedback immediato e non ambiguo.

6.2 Rate limit e lockout

• Troppe richieste OTP in poco tempo: verifica risposta e copy (senza rivelare regole precise sfruttabili).
• Troppe verifiche OTP errate: verifica lockout temporaneo e percorso di recupero.
• Comportamento per IP condivisi o NAT: evita falsi blocchi massivi, specialmente in reti aziendali.

6.3 Enumerazione account

• Inserisci un’email già registrata: il messaggio non deve rivelare direttamente “email esistente” (a meno che sia una scelta consapevole).
• Inserisci un’email inesistente: risposta coerente e simile, per non permettere enumerazione.

7) UX: microcopy, errori, e guidare l’utente

7.1 Messaggi di errore

• Errore OTP errato: testo breve, non colpevolizzante, con azione successiva.
• Errore OTP scaduto: spiega che serve un nuovo codice e offri resend immediato.
• Errore rete: conserva lo stato e consenti retry senza perdere l’email inserita.

7.2 Navigazione e stato

• Ricarica pagina nella schermata OTP: lo stato resta coerente (o viene ripristinato correttamente).
• Torna indietro e avanti: non deve creare sessioni duplicate o OTP invalidati senza spiegazione.
• Multi-tab: apri due tab e prova a verificare in entrambi; uno deve vincere in modo prevedibile.

7.3 Mobile e “copia/incolla”

• Paste del codice dall’email: il flusso deve essere naturale, senza richiedere formattazioni manuali.
• Auto-fill (se supportato): non deve rompersi con OTP appena inviati o aggiornati.

8) Sicurezza: verifiche minime ma decisive

8.1 Trasporto e contenuto dell’email

• Il codice OTP non deve essere riutilizzabile oltre la finestra prevista.
• Evita di includere informazioni sensibili nell’oggetto (meglio non mettere OTP nel subject se non necessario).
• Se ci sono link, devono usare HTTPS e non includere token in chiaro in contesti rischiosi.

8.2 Sessione e token

• Verifica che l’OTP sia legato alla sessione o almeno al contesto previsto (email + challenge).
• Se cambi email in corso, vecchi OTP devono essere invalidati in modo coerente.
• Protezione CSRF e mitigazioni base dove applicabile (soprattutto su endpoint critici).

8.3 Brute force

• Prova OTP casuali ripetuti: verifica che esista un limite tentativi e un comportamento graduale (delay, lock temporaneo).
• Verifica che gli errori non rivelino “quasi giusto” o dettagli che aiutano l’attaccante.

9) Osservabilità: logging, metriche, e diagnosi rapida

Un flusso OTP in produzione fallisce spesso “a metà”: l’email viene inviata ma non arriva, oppure arriva ma l’utente non riesce a verificare. Senza osservabilità, il team brancola nel buio. QA dovrebbe controllare anche questo.

9.1 Eventi da tracciare

• Signup requested / OTP generated / OTP sent / OTP delivered (se disponibile) / OTP verified / OTP failed.
• Resend requested, rate-limited, denied, successful.
• Bounce/blocked/spam signals dal provider (se integrati).

9.2 Correlazione

• Ogni flusso dovrebbe avere un identificatore per correlare UI ↔ backend ↔ provider.
• In caso di errore, la UI dovrebbe mostrare un codice di supporto copiabile (senza dati sensibili).

9.3 Metriche utili

• Tempo medio di consegna OTP e percentili (p95/p99).
• Tasso di resend per signup (se alto, qualcosa non va).
• Tasso di fallimento verifica OTP e motivi principali.

10) Test automatizzabili (idee pratiche)

Non tutto è automatizzabile senza accesso a inbox controllate, ma molte parti sì: validazione form, rate limit, scadenze, stati, copy degli errori e idempotenza. Se hai un endpoint interno o un “test mailbox” in staging, puoi spingerti oltre.

10.1 Suite minima

• Signup valido → richiesta OTP → verifica con OTP corretto.
• OTP errato → errore coerente → tentativo successivo con OTP corretto.
• OTP scaduto → rifiuto → resend → verifica riuscita.
• Resend durante cooldown → negato → dopo cooldown → ok.
• Troppi tentativi OTP → lock temporaneo → recupero dopo attesa.

10.2 Edge case importanti

• Doppio submit del form (click multipli): un solo account/challenge deve essere creato (idempotenza).
• Multi-tab: verifica una volta e assicurati che l’altro tab gestisca lo stato aggiornato.
• Ricarica pagina durante verifica: nessun crash, stato recuperabile.

11) Checklist finale “pronta per release”

• UX: messaggi chiari per OTP errato/scaduto/ritardo, resend con cooldown, nessun dead-end.
• Affidabilità: gestione ritardi e duplicati, stati coerenti con refresh/back, idempotenza su submit.
• Sicurezza: rate limit e lockout ragionevoli, mitigazione enumerazione, OTP non riutilizzabile.
• Accessibilità: focus corretto, input OTP usabile su mobile, testi leggibili.
• Osservabilità: eventi tracciati, correlazione disponibile, metriche di consegna e fallimento.
• Compatibilità: test su browser principali e su mobile (almeno iOS Safari e Chrome Android).