Email temporanea per i test: come sviluppatori e team QA verificano i flussi di registrazione

Ogni prodotto che invia email ha bisogno di qualcuno che si registri, ancora e ancora, con un indirizzo nuovo. Gli sviluppatori usano il proprio Gmail con un'etichetta dopo il più, i tester QA tengono un foglio di calcolo di account usa e getta e i product manager si fanno prestare la casella di un collega. Un indirizzo email temporaneo per i test è più veloce di tutte queste soluzioni per un compito preciso: vedere esattamente cosa riceve un nuovo utente dalla tua configurazione di posta di produzione o di staging.

Gestiamo i server di posta di PureTempMail, quindi i limiti indicati qui sotto sono le nostre impostazioni reali, non supposizioni. Questa guida spiega dove si colloca una casella temporanea pubblica in un piano di test, un test manuale che puoi fare in cinque minuti, la checklist che useremmo per le nostre email di registrazione e i casi in cui conviene usare un altro strumento.

Dove si colloca una casella temporanea tra le opzioni di test

Ci sono cinque modi comuni per dare un indirizzo a un account di test. La maggior parte dei team finisce per usarne due o tre in fasi diverse dello stesso rilascio.

Una casella temporanea si guadagna il suo posto in un vuoto lasciato dalle altre: un messaggio reale, inviato dal tuo vero provider di posta, che arriva su un dominio che non controlli e che vedi in un browser in pochi secondi. È quanto di più vicino puoi ottenere a ciò che vede un nuovo cliente, senza creare l'ennesimo account da qualche parte.

Un test manuale con PureTempMail

Questo è il procedimento che consigliamo per verificare a mano un flusso di registrazione. Richiede circa cinque minuti per ogni passata.

1. 1

   Apri una casella nuova per ogni utente di test

   Apri PureTempMail in una finestra del browser separata. Al caricamento viene creato un nuovo indirizzo. La casella viene ricordata per browser, quindi premi Nuovo per ogni utente di test, oppure usa una finestra privata quando due tester condividono la stessa macchina.

2. 2

   Annota l'indirizzo accanto al caso di test

   Incolla l'indirizzo nel caso di test o nel ticket prima di usarlo. Se più tardi un tester chiede perché l'email di reimpostazione non è mai arrivata, devi sapere in quale casella è finita.

3. 3

   Esegui la registrazione e fai partire tutte le email possibili

   Compila il modulo, poi richiedi le email che un nuovo utente può generare nella sua prima sessione: nuovo invio della verifica, password dimenticata, accesso con link magico, richiesta di cambio email. Ognuna è un modello separato che può rompersi per conto suo.

4. 4

   Tieni d'occhio la casella senza aggiornare

   La nuova posta viene inviata alla pagina tramite una connessione attiva nel momento in cui il nostro server la accetta, quindi l'istante in cui compare un messaggio è vicino al suo reale momento di consegna. Annota quanto ha impiegato ciascuno. Come funziona spiega il percorso di consegna.

5. 5

   Apri ogni messaggio in entrambe le viste

   Leggilo in HTML, poi passa a Testo semplice. La vista testuale è quella su cui ripiegano alcuni client e lettori di schermo, ed è lì che emergono per primi una parte di testo mancante o un codice illeggibile. Clicca ogni link e verifica dove porta.

6. 6

   Prolunga se il flusso è lento

   Sequenze drip, approvazioni in differita e promemoria del secondo giorno richiedono più tempo. Premi +1 ora per riportare il timer a un'ora piena. Puoi continuare a farlo fino a 24 ore dalla creazione della casella.

7. 7

   Lasciala scadere, poi testa il bounce

   Dopo la scadenza, il nostro server rifiuta la posta per quell'indirizzo già nella fase SMTP con un errore permanente "No such mailbox". Inviale un'altra email e verifica che la tua app o il tuo provider di posta registrino un hard bounce e smettano di scrivere a quell'utente.

La checklist per testare le email di registrazione

Questi sono i controlli che faremmo sulle email di registrazione di qualsiasi prodotto prima di un rilascio. Ognuno è facile da notare in una casella reale e facile da perdere in una code review.

• Codice o link di verifica. Arriva, il codice è leggibile in testo semplice, il link funziona una volta e un secondo clic mostra un messaggio chiaro invece di una pagina di errore.
• Link magici e codici monouso. Un nuovo link invalida quello vecchio, un link scaduto spiega cosa fare dopo e aprire il link in un altro browser si comporta come previsto.
• Reimpostazione della password. L'email dice a quale account si riferisce, il link scade e chiedere un reset per un indirizzo non registrato non rivela se quell'indirizzo ha un account.
• Email di benvenuto e drip. La prima arriva dopo la verifica, non prima, e i passaggi successivi non partono per gli utenti che non hanno mai confermato.
• Parti HTML e testo semplice. Esistono entrambe, dicono la stessa cosa e niente di importante sta solo in un'immagine. Le immagini remote si caricano nella nostra vista HTML, quindi puoi controllarle lì e usare Testo semplice per vedere il messaggio senza di esse.
• Allegati. Fatture e PDF arrivano con nomi di file e tipi di contenuto sensati. Mantieni i file di test sotto 1 MB per messaggio, oppure invia un link per il download, che comunque è più gentile verso gli utenti reali.
• Destinazioni dei link. Nessun link in un'email di produzione punta a localhost, a un hostname interno o a un dominio di staging, e i redirect di tracciamento portano alla pagina giusta.
• Intestazioni di disiscrizione. Le email di marketing e drip contengono un link di disiscrizione funzionante e, per i mittenti di massa, l'intestazione one-click List-Unsubscribe descritta in RFC 8058, che le linee guida per i mittenti di Google richiedono ai mittenti di massa. Le email transazionali come i reset non dovrebbero essere bloccate da una disiscrizione.
• Tempi di consegna. Le email di verifica che impiegano più di un minuto o due fanno perdere utenti. Se una è lenta, controlla se la tua app mette la posta in coda dietro altri job o se il provider limita i nuovi mittenti.
• I tuoi limiti di frequenza. Premi ripetutamente il pulsante di nuovo invio. L'app dovrebbe porre un limite e dire all'utente di aspettare, invece di inviare dieci codici o fallire in silenzio.
• Riutilizzo di un indirizzo. Registrati due volte con lo stesso indirizzo nella stessa sessione e controlla il secondo tentativo: un percorso chiaro "già registrato" e nessun secondo account.
• La tua regola sui domini usa e getta. Se il tuo prodotto blocca gli indirizzi temporanei, verifica che il messaggio di errore sia chiaro e che per sbaglio non blocchi anche provider reali. Ne parliamo più avanti.

I nostri limiti e cosa significano per un test

Queste sono le impostazioni effettive dei nostri server. Pianifica i test tenendone conto.

Durata

Un'ora dalla creazione. +1 ora la riporta a un'ora piena, fino a 24 ore dalla creazione. Basta per una sessione, non per un account di test da riutilizzare nel prossimo sprint.

Messaggi

Fino a 50 messaggi e 5 MB per casella. Raggiunto uno dei due limiti, la nuova posta viene respinta, quindi un test di carico rivolto a un solo indirizzo smette presto di contare. Apri una nuova casella per ogni utente di test.

Dimensione dei messaggi

Fino a 1 MB per email, allegati inclusi. Vengono conservati solo i primi 10 allegati.

Solo ricezione

L'indirizzo non può inviare né rispondere. I flussi in cui l'utente deve rispondere via email, come le conversazioni dei ticket di assistenza, non si possono testare qui da cima a fondo.

Dominio

Un solo dominio per tutti gli indirizzi. Se il tuo prodotto blocca i domini temporanei noti, bloccherà anche il nostro, il che è utile quando è proprio quel comportamento che vuoi testare.

Nuove caselle

Cinque nuove caselle al minuto da un singolo indirizzo IP. Un team QA dietro un'unica connessione d'ufficio condivide questo budget.

Eliminazione

Dopo la scadenza, una pulizia che gira ogni cinque minuti elimina la casella, i suoi messaggi e gli allegati. Fai degli screenshot prima che il timer si esaurisca se ti servono prove per una segnalazione di bug.

Automazione

Non esiste un'API pubblica per accedere alle caselle tramite script. PureTempMail è pensato per una persona che guarda un browser, ed è per questo che le suite automatiche vanno sugli strumenti indicati più avanti.

Controllare SPF, DKIM e DMARC nelle email di test

Un messaggio che si visualizza bene può comunque non superare l'autenticazione e finire nello spam per gli utenti reali. Per verificarlo, invia la stessa email a una casella che mostra il sorgente grezzo, ad esempio con Mostra originale di Gmail, e incolla le intestazioni nel nostro analizzatore di intestazioni email. Mostra se SPF, DKIM e DMARC sono stati superati, segnala un Reply-To su un dominio diverso e indica dove la consegna è stata lenta. L'analisi avviene nel tuo browser, quindi le intestazioni non ci vengono inviate.

Testare il tuo blocco dei domini usa e getta

Molti team aggiungono un controllo sulle email usa e getta al modulo di registrazione e non lo testano mai con un vero indirizzo temporaneo. Una casella temporanea è il dato di test più ovvio.

• Controlla il testo. Il rifiuto dovrebbe dire alle persone cosa usare al suo posto, ad esempio "Usa un indirizzo personale o di lavoro". Un semplice "Email non valida" manda gli utenti onesti a cercare un errore di battitura che non c'è.
• Controlla i falsi positivi. Prova indirizzi di piccoli provider regionali e di domini aziendali personalizzati. Le blocklist basate su schemi a volte li intercettano.
• Controlla ogni punto di accesso. La stessa regola dovrebbe valere per il modulo di registrazione, l'impostazione di cambio email, gli inviti e l'API, altrimenti le persone useranno semplicemente il percorso che hai dimenticato.
• Decidi se il blocco ti serve davvero. Il nostro articolo sul perché i siti bloccano le email usa e getta illustra i costi che lo giustificano e i casi in cui ti fa solo perdere utenti onesti.

Quando una casella temporanea pubblica è lo strumento sbagliato

In questi casi usa qualcos'altro.

• Qualsiasi cosa contenga segreti reali o dati dei clienti. Token di produzione, fatture vere, inviti da amministratore. Usa una sandbox che solo il tuo team può leggere.
• Test automatici e CI. Collega l'app a un catcher locale come Mailpit in sviluppo e in CI, e a una sandbox ospitata come Mailtrap o Mailosaur quando i test devono girare su un ambiente pubblicato. MailHog, il vecchio catcher locale, non è più mantenuto e Mailpit è il sostituto abituale.
• Ambienti di staging con copie di dati reali degli utenti. Lì il bug sono i dati copiati. Ripuliscili e instrada la posta di staging verso un catcher, così un test non scrive mai a un cliente reale.
• Account di test da conservare. Un account demo per il commerciale o un account di revisione per un app store ha bisogno di un indirizzo che funzioni anche il mese prossimo. Usa l'indirizzamento con il più su una casella del team o un catch-all su un dominio di test di tua proprietà.
• Fixture che non devono mai essere consegnate. Per i dati di seed e gli unit test usa i domini riservati come example.com e il dominio di primo livello .test previsti da RFC 2606. La posta diretta lì non va da nessuna parte, per progettazione.

Fonti

• Mailpit su GitHub, lo strumento di test delle email e la relativa API per sviluppatori, con le sue note sulla sostituzione di MailHog.
• Documentazione di Mailtrap Email Sandbox.
• Librerie client di Mailosaur su GitHub.
• RFC 8058, Signaling One-Click Functionality for List Email Headers.
• Google, linee guida per i mittenti di email.
• RFC 2606, Reserved Top Level DNS Names.
• Durata delle caselle, limiti di dimensione e numero, limiti di frequenza, rifiuto SMTP dopo la scadenza e tempi di pulizia provengono dalla configurazione dei server di PureTempMail, riassunta anche nelle FAQ.