Il test email transazionali è la disciplina di controllare la posta che il tuo prodotto invia per proprio conto, prima che persone reali la ricevano. Una conferma di registrazione, un ripristino password, un avviso d’ordine, una fattura: ciascuno è innescato da un evento, riempito con dati e ci si aspetta che arrivi esattamente una volta. Le modalità di guasto sono banali e costose — un trigger che non scatta mai, un modello che visualizza un nome vuoto, un link che punta all’ambiente sbagliato, un nuovo tentativo che produce tre ricevute identiche.
Cosa conta come posta transazionale
La posta transazionale viene inviata perché è successo qualcosa, a qualcuno che è parte di quell’evento. Non è una newsletter né una promozione, e la distinzione non è accademica: cambia quali contenuti sono appropriati, cosa si aspetta il destinatario e cosa significa una disiscrizione con un clic in ciascun caso.
Il confine diventa sfocato in pratica, e la sfocatura è dove iniziano i problemi. Inserire un blocco promozionale in un ripristino password è un modo collaudato di irritare le persone. Inviare una conferma d’ordine attraverso la pipeline di marketing significa che una soppressione o una preferenza di disiscrizione può fermare in silenzio un messaggio di cui il destinatario ha davvero bisogno.
Decidi a quale pipeline appartiene ciascun messaggio, e rendi quella decisione visibile nella configurazione anziché nella memoria di qualcuno.
Controllare la lista dei trigger prima del lancio
Parti dagli eventi, non dai modelli. Per ogni evento che dovrebbe produrre posta, conferma che venga effettivamente prodotto un messaggio, inviato all’indirizzo giusto e riconoscibile come appartenente a quell’evento.
- Account creato, conferma dell’indirizzo richiesta, indirizzo cambiato.
- Ripristino password richiesto e password cambiata.
- Ordine effettuato, pagamento saldato, rimborso emesso.
- Fattura o ricevuta generata.
- Avvisi programmati o rilevanti per la sicurezza che il prodotto promette.
Per ogni riga, le domande sono le stesse: scatta una volta, tiene il destinatario giusto e sopravvive a un nuovo tentativo? Una checklist che nomina l’evento vale più di una che nomina il modello, perché gli eventi sono ciò che effettivamente manca.
Le variabili vengono sempre rese?
La resa è dove un prodotto ben testato spedisce comunque difetti visibili, perché un modello che si rende correttamente con dati completi può rendere in modo molto diverso con dati parziali.
I casi che vale la pena provare sono quelli vuoti. Un utente con un solo nome, un utente senza alcun nome visualizzato, un ordine con una voce e un ordine senza voci, un valore che è una stringa vuota anziché mancante. Ciascuno di questi dovrebbe produrre qualcosa che una persona possa leggere, e nessuno dovrebbe produrre testo segnaposto grezzo o un vuoto dove una frase si aspettava un sostantivo.
Due abitudini aiutano. Dai a ogni variabile un valore di ripiego definito, così che l’assenza produca una frase sensata anziché nulla. E rendi nello stesso percorso di codice che usa il prodotto, così che il test eserciti il modello reale anziché una sua copia che diverge.
Cosa succede quando lo stesso evento scatta due volte?
Supponi che il fornitore di pagamenti chiami il tuo webhook due volte, o che una coda riconsegni perché una conferma è andata persa. L’utente non dovrebbe ricevere due ricevute per un solo ordine.
Questa è una proprietà del lato mittente più che del server di posta, e vale la pena testarla direttamente: consegna due volte lo stesso evento e afferma che ne risulta un solo messaggio. Il meccanismo abituale è un identificatore fornito dall’evento, registrato quando il messaggio viene accettato, così che la seconda consegna venga riconosciuta come ripetizione. Qualunque sia il meccanismo, il test dovrebbe esercitarlo anziché presumerlo, perché gli eventi duplicati sono normali nei sistemi distribuiti e la posta non ha modo di annullare l’invio di un messaggio.
Perché l’identità mittente conta per le caselle?
Perché i sistemi riceventi decidono se fidarsi di un messaggio in parte in base a da dove sembra provenire. Il dominio mittente è di norma configurato con record di autorizzazione e firma pubblicati nel sistema dei domini, e quei record sono il modo in cui il destinatario può capire che il messaggio proviene davvero dal dominio che dichiara. I meccanismi sono standardizzati in documenti dell’IETF; il punto operativo è che un dominio configurato per il normale traffico web non è automaticamente configurato per inviare posta, e un lancio che salta questo passo può produrre messaggi che sembrano spam dal primo giorno.
Configurarlo è un compito di chi possiede il dominio, e i dettagli dipendono dal fornitore di posta. Ciò che una checklist di test può fare è confermare che la configurazione sia stata effettivamente completata nell’ambiente in cui stai lanciando, anziché solo in quello in cui hai testato.
Localizzazione, formati di data e differenze tra paesi
Un prodotto che serve più di un mercato eredita due errori facili. Il primo è il testo: un messaggio localizzato nel corpo ma con oggetto e piè di pagina lasciati nella lingua originale. Il secondo è il formato: una data che si legge in modo inequivocabile in un mercato e in modo confuso in un altro, o un numero formattato con un separatore decimale diverso da quello che il destinatario si aspetta.
Il controllo concreto è innescare ogni messaggio in ogni lingua che il prodotto spedisce e leggere l’intero messaggio, oggetto incluso, come farebbe un destinatario. Se il contenuto fa riferimento a un dettaglio specifico di una giurisdizione — un formato di identificatore, un’etichetta fiscale, una convenzione postale — le pagine del mercato pertinente sono un utile riferimento per ciò che quel mercato si aspetta, come nel caso di Germania o Giappone.
Qualunque cosa tu invii in questo passaggio di test, dovrebbe andare a indirizzi che hai creato allo scopo. Nulla di ciò che è descritto qui è un’identità reale o un contatto di un cliente vero, e nessun modello dovrebbe essere spedito con l’indirizzo di una persona reale al suo interno.
Per gli sviluppatori: idempotenza, gestione dei guasti e log
Quattro proprietà meritano una copertura esplicita nella suite.
L’idempotenza per prima: un evento, un messaggio, indipendentemente da quante volte l’evento viene consegnato. Verificalo consegnando due volte.
La gestione dei guasti per seconda: decidi cosa succede quando il fornitore di posta rifiuta o va in timeout. Un invio fallito dovrebbe essere registrato, ritentato secondo un programma e segnalato — non inghiottito. Un guasto silenzioso significa scoprire il problema da un cliente.
I valori di ripiego dei modelli per terzi: definisci come ogni variabile viene resa quando è assente, e testa il caso assente. Questa è la classe di difetti che arriva più spesso in produzione, perché dati di test completi la nascondono.
I log per quarti: conservane abbastanza da diagnosticare un messaggio mancante e non così tanti da rendere il log un rischio per i dati. Registra l’identificatore dell’evento, la versione del modello e l’esito. Non registrare il corpo del messaggio e non registrare un link di ripristino, perché una riga di log contenente un link funzionante è una credenziale con una lunga scadenza.
Per la posta che i tuoi test stessi generano, un indirizzo creato per l’esecuzione mantiene ristrette le asserzioni e tiene le caselle altrui fuori dal giro; lo strumento di posta temporanea ne crea uno in un paio di secondi, e come funziona la posta temporanea spiega cosa succede ai messaggi in seguito.
Prossimi passi
Prendi la lista dei trigger qui sopra e segna ogni riga con l’ambiente in cui l’hai vista funzionare l’ultima volta e la persona che ha letto il messaggio per ultima. Tutto ciò che è non segnato è un rischio di lancio. Poi invia a te stesso ogni messaggio da un indirizzo creato per il test sulla pagina della posta temporanea, e leggilo come farebbe un destinatario — sull’oggetto oltre che nel corpo.