Transaktions-E-Mail testen beginnt bei der Frage, welche Nachrichten überhaupt transaktional sind. Eine Transaktionsmail wird durch ein Ereignis ausgelöst, und ihr Empfänger ist eine Partei dieses Ereignisses: die Person, die gerade ein Konto angelegt, ein Passwort zurückgesetzt, eine Bestellung aufgegeben oder eine Zahlung geleistet hat. Sie ist keine Werbung, keine Produktankündigung und keine Newsletter-Ausgabe, und in dieser Unterscheidung liegt fast jeder Fehler, den dieser Bereich kennt.
Was als Transaktionsmail zählt
Die Grenze verläuft nicht am Inhalt, sondern am Anlass. Wer definiert, dass Transaktionsmail eine Geschäftstransaktion betrifft, landet in einer Debatte. Wer dieselbe Mail so definiert, dass sie nur existiert, weil der Empfänger eine Handlung ausgeführt hat, hat die Antwort meist schon.
Unklar wird es genau dort, wo Produktteams Umsatz suchen. Ein Rabattblock in einer Passwort-zurücksetzen-Nachricht verwandelt eine Service-Mitteilung in Werbung und setzt sie Regeln aus, für die sie nicht gebaut wurde. Eine Bestellbestätigung über den Marketingweg zu senden klingt effizient, bis sich herausstellt, dass eine Abmeldung oder eine Unterdrückungsliste den Versand stillschweigend beendet. Die Mail verliert dann nicht an Qualität, sie verschwindet.
Deshalb gehört die Zuordnung in die Konfiguration und nicht ins Gedächtnis. Jede Nachricht, die Ihr System versendet, sollte einer Angabe zugeordnet sein, die sagt, ob sie transaktional ist, und niemand sollte diese Einordnung beim Schreiben eines neuen Ablaufs improvisieren müssen.
Die Auslöserliste vor dem Start prüfen
Ein Testplan, der nach Vorlagen geordnet ist, übersieht genau die Fälle, die zählen. Ordnen Sie ihn nach Auslösern, denn verloren geht ein Ereignis und nicht ein Text.
- Die Kontoerstellung, samt der Bitte um Adressbestätigung und jeder späteren Adressänderung.
- Die Anforderung eines Passwort-Resets und, getrennt davon, die vollständige Änderung des Passworts.
- Die Bestellung, die abgeschlossene Zahlung und die Rückerstattung.
- Eine erzeugte Rechnung oder Quittung, besonders wenn sie nachträglich verfügbar sein soll.
- Planmäßige und sicherheitsrelevante Mitteilungen zu einem Produkt, das der Nutzer bereits abonniert hat.
Für jeden Auslöser gehören drei Fragen in die Liste, und sie sind nicht verhandelbar. Löst das Ereignis genau eine Nachricht aus, wenn es einmal geschieht? Geht sie an die richtige Adresse – auch dann, wenn der Nutzer die Adresse erst kürzlich geändert hat? Und hält sie einen erneuten Versuch aus, ohne dem Nutzer zwei Exemplare zu hinterlassen?
Eine Auslöserliste findet außerdem Lücken, die eine Vorlagenliste nicht sieht: Ereignisse, für die niemand je eine Nachricht geschrieben hat. Eine Adressänderung ohne Bestätigung an die alte Adresse ist so ein Fall – der Nutzer erhält nie die Gelegenheit zu bemerken, dass jemand anderes sein Konto angepasst hat.
Werden die Variablen immer gefüllt?
Eine Vorlage, die mit vollständigen Daten korrekt aussieht, kann mit unvollständigen Daten sehr Verschiedenes erzeugen. Prüfen Sie deshalb ausdrücklich die leeren und die halben Fälle und nicht nur den glücklichen.
Die nützlichen Beispiele sind unangenehm konkret: ein Nutzer, der nur einen Namen hinterlegt hat; ein Nutzer ohne Anzeigename; eine Bestellung mit einer Position und eine Bestellung ohne Positionen; und ein Feld, das Ihnen als leerer Text statt als fehlender Wert ankommt. Jeder dieser Fälle sollte etwas Menschenlesbares ergeben. Keiner sollte dem Empfänger einen rohen Platzhalter zeigen oder ein Loch, an dem ein Substantiv stehen sollte.
Zwei Gewohnheiten lösen diese Klasse fast vollständig. Definieren Sie für jede Variable, was gerendert wird, wenn sie fehlt, und rendern Sie mit derselben Funktion, die das Produkt verwendet. Eine Testvorlage oder ein Testpfad, der anders rendert als die Produktion, misst nicht dasselbe.
Was geschieht, wenn dasselbe Ereignis zweimal auslöst?
Wenn ein Zahlungsdienst sein Ereignis wiederholt zustellt oder eine Warteschlange eine Nachricht erneut liefert, weil die Bestätigung verloren ging, sollte der Nutzer nicht zwei Quittungen für eine Bestellung erhalten. Für einen Vorgang mit einer Wirkung gehört genau eine Nachricht – und das ist eine Eigenschaft des versendenden Systems, nicht des Mailservers.
Weil es eine Eigenschaft eigenen Codes ist, lässt es sich direkt prüfen: Stellen Sie dasselbe Ereignis zweimal zu und behaupten Sie, dass genau eine Nachricht erzeugt wurde. Der übliche Mechanismus ist, den Bezeichner des Ereignisses zum Zeitpunkt der Annahme festzuhalten, sodass die zweite Zustellung als Wiederholung erkannt und verworfen wird.
Dieser Test hat einen besonderen Wert, weil er sich nicht mit Geduld reparieren lässt. Doppelte Ereignisse sind in verteilten Systemen normal, und Mail lässt sich nicht zurücknehmen. Die Wiederholung gar nicht erst entstehen zu lassen, ist die einzige echte Antwort.
Warum spielt die Absendeidentität für Postfächer eine Rolle?
Weil empfangende Systeme zum Teil entscheiden, ob sie Ihnen glauben. Eine Domain, die Mail sendet, muss die dafür vorgesehenen Autorisierungs- und Signaturangaben veröffentlichen, über die ein empfangendes System prüfen kann, dass die Nachricht wirklich von dieser Domain stammt. Die Verfahren sind in Dokumenten der Standardisierungsgremien festgehalten, und die Einzelheiten ändern sich mit der Zeit; die Betriebsregel dahinter ist stabil.
Die Regel lautet, dass eine Domain, die für gewöhnlichen Webverkehr sauber konfiguriert ist, deshalb noch nicht für den Mailversand konfiguriert ist. Wer diesen Schritt überspringt, schickt am ersten Tag Mail, die wie Werbung aussieht, und findet seine Nachrichten später in dem Ordner, den niemand liest.
Diese Konfiguration ist Arbeit des Domaininhabers und lässt sich nicht von außen erledigen. Ein Checklistenpunkt kann höchstens verlangen, dass Sie bestätigen, dass sie in der Umgebung, die Sie ausliefern, tatsächlich erledigt wurde – eine Zusage, die nur prüfbar ist, wenn jemand sie geprüft hat.
Lokalisierung, Zeitformate und Länderunterschiede
Lokalisierung ist ein Bereich, in dem sich Mängel zuverlässig sammeln, weil sie beim Durchsehen der Ausgangssprache unsichtbar sind. Die beiden häufigsten sind, dass der Inhalt übersetzt wurde und der Betreff samt Fußzeile in der Ausgangssprache blieb, und dass ein Datum oder ein Dezimaltrennzeichen in einem Markt etwas anderes bedeutet als in einem anderen.
Das Gegenmittel ist unangenehm handfest: Lösen Sie jede Nachricht in jeder Sprache aus, die das Produkt unterstützt, und lesen Sie das Ergebnis wie ein Empfänger – mit dem Betreff. Wann immer eine Nachricht auf Einzelheiten eines Rechtsraums Bezug nimmt, sollte die Referenz auf die Seite des Marktes zeigen, zum Beispiel Deutschland oder Japan, statt auf eine allgemeine Übersicht.
Für Entwickler: Idempotenz, Fehlerbehandlung und Protokolle
Vier Zusagen gehören in diesen Bereich, und alle lassen sich prüfen.
Eine Wirkung pro Ereignis ist die erste, und der Test dafür lautet, dasselbe Ereignis zweimal zuzustellen und genau eine Nachricht zu erwarten. Ohne diese Zusage erzeugt jede Wiederholung im Rest Ihres Systems Verwirrung im Postfach eines Kunden.
Die Behandlung von Fehlern ist die zweite. Eine Ablehnung oder ein Zeitüberschreitung sollte protokolliert, nach einem erkennbaren Plan erneut versucht und sichtbar gemacht werden. Sie ohne Meldung zu schlucken ist die eine Entscheidung, die garantiert, dass Sie von einem Problem erst durch einen Kunden erfahren.
Rückfallwerte für Vorlagen sind die dritte. Definieren Sie, was jede Variable rendert, wenn sie fehlt, und prüfen Sie den fehlenden Fall. Eine Vorlage, die nur mit vollständigen Daten geprüft wurde, ist nicht geprüft.
Die Protokollierung ist die vierte. Halten Sie fest, welches Ereignis die Nachricht ausgelöst hat, welche Fassung der Vorlage verwendet wurde und welches Ergebnis erzielt wurde. Halten Sie den Inhalt nicht fest, und ganz besonders keine Links zum Zurücksetzen eines Passworts – eine Protokollzeile mit einem funktionierenden Link ist ein Zugangsmittel mit langer Lebensdauer.
Wenn Ihre Tests selbst Mail erzeugen, geben Sie jedem Lauf eine eigene Adresse, damit die Behauptungen eng bleiben. Die Seite für temporäre E-Mail erzeugt eine auf Anforderung, und wie temporäre E-Mail funktioniert erklärt, warum eine langsame oder doppelte Nachricht normal ist.
Nächste Schritte
Nehmen Sie die Auslöserliste oben und haken Sie ab, was Sie in der Umgebung, die Sie ausliefern wollen, tatsächlich geprüft haben. Für alles Übrige gilt: Lösen Sie das Ereignis aus, lesen Sie die Nachricht wie ein Empfänger, und wiederholen Sie es einmal. Eine Adresse für diesen Lauf erzeugt die Seite für temporäre E-Mail in wenigen Sekunden; niemand sonst muss daran beteiligt sein.