E-Mail-Adressen für Testkonten in der QA

Ein Szenario für Registrierung und Zugriffswiederherstellung gilt erst dann als geprüft, wenn es mit einer echten E-Mail samt echtem Code oder Link durchlaufen wurde. Ein Platzhalter statt der E-Mail prüft nur das Formular, nicht aber die gesamte Kette aus Zustellung, Code-Parsing und Klick auf den Link. Dafür braucht ein Tester nicht ein einziges Universalpostfach, sondern Adressen, die auf das jeweilige Szenario und die jeweilige Website abgestimmt sind. Wir erklären, warum das nötig ist, weshalb private und geschäftliche Postfächer hier nicht geeignet sind, wie Sie zwischen einer Einmaladresse und einer Miete wählen und was in der Testdokumentation festgehalten werden sollte.

Warum Tester eigene E-Mail-Adressen brauchen

Ein durchgängiges Registrierungsszenario besteht nicht nur aus dem Ausfüllen des Formulars: Die Website muss eine E-Mail versenden, der Tester muss sie empfangen, den Code extrahieren oder dem Link folgen und die Kette mit der Anmeldung im Konto abschließen. Ein Platzhalter, der lediglich einen festen Code in die Datenbank schreibt, überspringt alles, was zwischen Versand und Empfang der E-Mail passiert – die Zustellverzögerung, das E-Mail-Format der jeweiligen Website, das Verhalten beim Öffnen des Links in einem anderen Client. Dass die echte Zustellung nicht funktioniert – die E-Mail landet im Spam, verspätet sich um Stunden oder kommt mit abgeschnittenem Link an –, lässt sich nur an einer echten Adresse feststellen, die tatsächlich E-Mails empfängt.

Warum private und Firmen-E-Mail dafür nicht geeignet sind

Ein privates Postfach für Testregistrierungen zu nutzen, wirkt zunächst wie eine schnelle Lösung. Es füllt das Postfach jedoch mit E-Mails von Dutzenden Testkonten und erschwert später die Suche nach wichtigen Nachrichten in der privaten Korrespondenz. Bei der Firmen-E-Mail kommt ein Risiko anderer Art hinzu: Ein Testkonto, das auf eine geschäftliche Adresse registriert wurde, kann versehentlich in produktive Unternehmensprozesse hineingeraten – etwa in einen Verteiler gelangen oder Zugriff auf Integrationen erhalten, die domainbasiert eingerichtet sind. Eine separate Testadresse beseitigt beide Risiken auf einmal: Sie existiert für genau eine Aufgabe und überschneidet sich weder mit der privaten Korrespondenz noch mit den Produktivdaten des Unternehmens.

Einmalaktivierung oder Miete – was passt zum Szenario

Die Wahl hängt davon ab, wie viele E-Mails im Rahmen des Szenarios erwartet werden. Prüft der Test genau einen Schritt – Registrierung und Bestätigung mit einer E-Mail –, genügt eine Einmalaktivierung: ein temporäres Postfach für eine bestimmte Website, das 20 Minuten besteht und nach einem Timeout geschlossen wird, mit automatischer Rückerstattung, falls die E-Mail nicht ankommt. Ist das Szenario komplexer und erfordert wiederholte E-Mails an dieselbe Adresse – zum Beispiel Registrierung, dann Passwortwiederherstellung, dann erneute Anmeldung mit Bestätigung per E-Mail –, reicht eine Einmalaktivierung nicht aus, weil die Adresse unmittelbar nach der ersten E-Mail geschlossen wird. Hier ist die Miete eines Postfachs mit einer Mietdauer von 12 Stunden bis 60 Tagen und der Möglichkeit zur Verlängerung gefragt: Es gibt Voreinstellungen für 12, 24 und 48 Stunden, eine Woche, einen Monat und 60 Tage, die sowohl einen kurzen Regressionslauf als auch mehrtägige Release-Tests abdecken.

Trennung von Test- und Produktivdaten als Grundregel

Die Regel ist einfach: Testdaten dürfen sich weder bei Adressen noch bei Konten noch bei Benachrichtigungskanälen mit Produktivdaten überschneiden. Ein gemietetes Postfach hilft hier architektonisch – es nimmt nur E-Mails von den bei der Bestellung angegebenen Websites an, sodass dieselbe Testadresse physisch nicht versehentlich eine E-Mail eines fremden Dienstes erhalten und das Szenario durcheinanderbringen kann. Das ist besonders wichtig, wenn parallel mehrere Versionen eines Produkts oder mehrere Umgebungen getestet werden: Jedes Szenario sollte seine eigene Adresse haben, damit sich die E-Mails verschiedener Läufe nicht in einem Postfach vermischen und das Prüfergebnis nicht verfälschen.

Was in der Testdokumentation festgehalten werden sollte

Damit ein Testlauf reproduzierbar ist und einem Kollegen ohne Rückfragen erklärt werden kann, sollten in der Dokumentation zum Szenario drei Dinge festgehalten werden: welche Adresse genau verwendet wurde, für welche Website oder welchen Dienst sie bestellt wurde und welche Laufzeit sie hat – ob sie unmittelbar nach der E-Mail abgelaufen ist oder noch für eine erneute Prüfung aktiv ist. Ohne diesen Eintrag ist eine Woche später schwer nachzuvollziehen, warum sich der Lauf nicht wiederholen lässt: Die Adresse wurde gemäß den Regeln des Formats automatisch geschlossen und nicht, weil im Szenario selbst etwas defekt war.

Wann kostenlose Mittel genügen und wann Mieten einfacher ist

Wenn Sie bereits eine eigene Domain und ein E-Mail-Hosting mit Unterstützung für viele Adressen haben und die Zahl der Testregistrierungen gering ist, können Sie für einzelne Prüfungen damit auskommen – nicht jede Aufgabe erfordert eine kostenpflichtige Adresse. Sobald die Tests jedoch zahlreich werden und die Szenarien eine Trennung zwischen den Läufen sowie die Gewähr verlangen, dass keine E-Mail eines anderen Tests im selben Postfach landet, ist es einfacher, ein Postfach für eine bestimmte Aufgabe oder Website zu mieten: Das nimmt Ihnen die Administration ab und hält jedes Szenario getrennt. Eine ähnliche Abwägung zwischen Platzhalter und echtem Code in automatisierten Läufen wird im Artikel über Autotests mit echten Codes in der CI behandelt.

Häufig gestellte Fragen

Eignet sich eine Einmalaktivierung für den Test eines Passwort-Wiederherstellungsszenarios?

Nur dann, wenn die Wiederherstellung in einem separaten Lauf unmittelbar nach Erhalt der Adresse geprüft wird. Sieht das Szenario zuerst eine Registrierung und später als eigenen Schritt die Wiederherstellung vor, reicht eine Einmalaktivierung nicht aus: Die Adresse ist dann bereits geschlossen. Für eine solche Kette ist die Miete eines Postfachs auf Zeit erforderlich.

Was tun, wenn das Testszenario E-Mails von mehreren Diensten an dieselbe Adresse erfordert?

Bei der Bestellung der Miete müssen Sie sofort alle Websites angeben, von denen E-Mails erwartet werden – der Filter des Postfachs nimmt nur E-Mails von der angegebenen Liste an, und eine nachträgliche Ergänzung ist nicht möglich.

Was tun, wenn es viele Tests gibt und es unpraktisch ist, für jeden manuell eine Adresse anzulegen?

Wenn Miete und Einmalaktivierung über die API verfügbar sind, lässt sich die Bestellung der Adresse in die Vorbereitung der Testumgebung einbinden, sodass Sie die Adresse vor jedem Lauf programmatisch erhalten, ohne sie manuell über die Oberfläche anzufordern.

Eine Einmalaktivierung für die zu testende Website oder die Miete eines Postfachs für die Dauer des durchgängigen Szenarios können Sie im Bereich E-Mail-OTP abschließen.