E-Mail-Verifizierung testen ist der Teil eines Registrierungsablaufs, den die meisten Teams einmal auf dem geraden Weg durchspielen und dann für erledigt erklären. Die interessanten Fehler liegen woanders: ein Link, der zweimal geöffnet wird, ein Link in einem anderen Browser, ein Code, der eintrifft, nachdem der Nutzer bereits verifiziert ist, eine Nachricht, die überhaupt nie ankommt. Dieser Artikel geht die Zustände durch, die ein Verifizierungsablauf wirklich hat, und die Fälle, die in jedem davon abgedeckt gehören.
Die Zustände, die ein Verifizierungsablauf durchläuft
Bevor Sie einen Test schreiben, schreiben Sie die Zustände auf. Ein Ablauf, der als verifiziert oder nicht verifiziert beschrieben wird, verbirgt mindestens vier verschiedene Lagen, und jede hat ihr eigenes korrektes Verhalten.
| Zustand | Was das System annimmt | Was der Nutzer tun kann |
|---|---|---|
| Unverifiziert, keine Mail versandt | Das Konto existiert, ist aber unbewiesen | Eine weitere Nachricht anfordern |
| Unverifiziert, Nachricht unterwegs | Ein Token existiert und hat eine Lebensdauer | Warten oder erneut anfordern |
| Verifiziert | Die Adresse wurde durch ein gültiges Token bewiesen | Das Konto normal nutzen |
| Änderung offen | Eine neue Adresse ist vorgeschlagen, die alte gilt weiter | Bestätigen oder abbrechen |
Die meisten Fehler sitzen in den Übergängen, nicht in den Zuständen. Fragen Sie, was geschieht, wenn ein Nutzer eine zweite Nachricht anfordert, während die erste noch unterwegs ist, oder wenn er die neue Adresse bestätigt, während er noch mit der alten angemeldet ist.
Was bricht, wenn ein Bestätigungslink zweimal geöffnet wird?
Nichts sollte brechen, und genau deshalb lohnt der Test. Ein Bestätigungslink wird über einen Kanal zugestellt, den der Nutzer nicht vollständig kontrolliert: Mailprogramme laden Links vor, Sicherheitsscanner folgen ihnen, und Nutzer klicken aus Ungeduld ein zweites Mal.
Gewünscht ist, dass die erste gültige Verwendung den Ablauf verbraucht und jede spätere Verwendung ein klares, harmloses Ergebnis liefert – eine Seite mit dem Hinweis, dass bereits verifiziert wurde, oder eine Anmeldeaufforderung – statt eines Fehlers, den der Nutzer nicht deuten kann. Nicht gewünscht ist ein zweites Verifizierungsereignis, das ein Passwort zurücksetzt, eine Sitzung neu ausstellt oder mit einer Meldung scheitert, die ein defektes Konto nahelegt.
Ein verwandter Fall erwischt Teams regelmäßig: zwei Konten, eine Adresse. Wenn Ihr Produkt dieselbe Adresse auf zwei Konten zulässt, darf eine einzelne Bestätigungsnachricht nicht beide verifizieren. Prüfen Sie das absichtlich.
Die Pfade für Adressänderung und Reset prüfen
Eine Adresse zu ändern und ein Passwort zurückzusetzen nutzen dieselbe Maschinerie mit einer anderen Folge, und dort beginnt eine gemeinsame Umsetzung zu lecken.
Wenn ein Nutzer eine Adresse ändert, existieren eine Zeit lang beide. Die alte sollte das Konto weiterhin wiederherstellen können, und die neue sollte erst wirksam werden, wenn sie bewiesen ist. Wenn ein Nutzer ein Passwort zurücksetzt, sollte die Bestätigung nicht zugleich als Verifizierung dienen und umgekehrt. Diese Pfade zu prüfen heißt nachzusehen, dass ein Token, das für einen Zweck ausgestellt wurde, vom anderen abgelehnt wird – eine kleine Prüfung, die eine große Fehlerklasse verhindert.
Ein nützliches Testmittel ist hier ein Postfach, das kein anderer Fall benutzt, damit die Nachricht, die Sie öffnen, sicher die ist, die der Ablauf gerade versandt hat. Das Werkzeug für temporäre E-Mail erzeugt genau solche Adressen, und der Artikel zum OTP-Test in End-to-End-Suiten behandelt das Auslesen des Codes, sobald er eingetroffen ist.
Was soll geschehen, wenn die Mail nie ankommt?
Das ist der Pfad, den Teams überspringen, und der, dem Nutzer am häufigsten begegnen, weil Mail aus Gründen scheitert, die niemand kontrolliert: ein Tippfehler in der Adresse, ein Anbieter, der die Nachricht still verwirft, ein Absender, der kurz gedrosselt wird.
Der Ablauf sollte die Nichtankunft als normales Ergebnis behandeln. Der Nutzer sollte eine weitere Nachricht anfordern können, ohne unangemessen lange zu warten, die Oberfläche sollte klar sagen, dass die Nachricht einen Moment brauchen kann, und das Konto sollte nicht in einem Zustand bleiben, in dem der Nutzer nicht erneut fragen kann, weil eine Anfrage bereits offen ist. Hinter all dem steht keine bestimmte Sekundenzahl und keine feste Zahl von Versuchen; der Punkt ist, dass das Design überhaupt eine Antwort hat.
Einen Code aus einem Wegwerf-Postfach lesen
Wenn ein Ablauf einen kurzen Code statt eines Links versendet, braucht der Test den Code aus der Nachricht. Ihn aus einem für den Lauf erzeugten Postfach zu lesen hält die Prüfung eng: Die Nachricht, die Sie finden, kann nur zu dem Fall gehören, der gerade läuft, was die häufigste Ursache eines Tests beseitigt, der aus dem falschen Grund besteht.
Außerdem hält es echte Postfächer vollständig aus dem Test heraus. Die Adresse einer Kollegin sollte niemals Empfängerin Ihrer Regressionstests sein, sowohl weil sie den Verkehr erhält als auch weil Ihre Prüfungen dann von einem Postfach abhingen, das Sie nicht kontrollieren.
Für Entwickler: Token, Idempotenz und der unerfreuliche Pfad
Modellieren Sie das Token, nicht nur das Formular. Drei Eigenschaften verdienen ausdrückliche Abdeckung.
Die einmalige Verwendung steht an erster Stelle. Ein Token sollte einmal verbraucht werden können, und der zweite Versuch sollte ein harmloses Ergebnis liefern statt eines Serverfehlers. Wo der Übergang etwas Folgenreiches ändert, machen Sie die Operation idempotent, damit eine Wiederholung denselben Endzustand erzeugt und nicht eine zweite Wirkung.
Der Ablauf steht an zweiter Stelle. Abgelaufene Token sollten in Ihren Protokollen und aus Sicht des Nutzers von ungültigen unterscheidbar sein, denn die Abhilfen unterscheiden sich: Ein abgelaufenes Token bedeutet, neu zu beginnen; ein ungültiges Token kann bedeuten, dass der falsche Link kopiert wurde. Was ein abgelaufenes Token nicht tun darf, ist das Konto in einem halb geänderten Zustand zu lassen.
Die Nebenläufigkeit steht an dritter Stelle. Zwei gleichzeitig eintreffende Klicks oder ein in zwei Tabs geöffneter Link dürfen denselben Ablauf nicht zweimal verifizieren können. Das ist eine Eigenschaft der Datenschicht und nicht des Knopfes, prüfen Sie es also, indem Sie beide Anfragen auslösen, statt zweimal langsam zu klicken.
Halten Sie schließlich die Grenze in Ihren Testdaten und in Ihren Notizen klar: Diese Adressen existieren, um für einen Moment Testmail zu empfangen; sie sind keine echten Identitäten, und keine Testdatei sollte etwas anderes nahelegen.
Nächste Schritte
Nehmen Sie den Verifizierungsablauf, den Sie zuletzt ausgeliefert haben, und gehen Sie die Zustandstabelle oben durch, wobei Sie die Übergänge markieren, die Sie tatsächlich geprüft haben. Führen Sie anschließend die ungeprüften aus, mit einer Adresse, die für jeden Fall frisch über die Seite für temporäre E-Mail erzeugt wurde. Wenn Sie einen größeren Start vorbereiten, deckt die Checkliste für Transaktions-E-Mail die umgebende Mail ab, die ein verifiziertes Konto zu erhalten beginnt.