1) Vorbereitung: Test-Setup, Daten und Zuständigkeiten

1.1 Testumgebung & Feature Flags

• Environment klar benennen: Staging, QA, Pre-Prod – inklusive Base-URL und Build-Version.
• Konfiguration dokumentieren: OTP-Lifetime, Resend-Cooldown, Max-Resends, Rate-Limits, Captcha/Challenge.
• Feature Flags prüfen: Social Login an/aus, Magic Link an/aus, „Email required“ vs. optional.
• Mail-Provider/Domain-Regeln: Blocklisten, Allowlist, MX-Checks, Disposable-Domain-Detection.

1.2 Testdaten & Identitäten

• Testkonten: Mindestens ein „frischer“ User, ein „bereits registrierter“ User, ein „gesperrter“ User.
• Mehrere Wegwerf-Adressen: Für Paralleltests und Reproduzierbarkeit (z. B. gleiche Domain vs. wechselnde Domain).
• Geräte/Browser-Matrix: iOS/Android + mindestens zwei Browser (Chrome/Safari) und ein langsames Netzprofil.
• Uhrzeit/Zeitzone: Serverzeit vs. Clientzeit; OTP-Ablauf darf nicht vom Client-Clock-Drift abhängen.

1.3 Logging & Debug-Hilfen vorab aktivieren

• Correlation ID (Request-ID) pro Signup/OTP-Versuch in Client & Backend sichtbar.
• Email Event Tracking: „queued“, „sent“, „delivered“, „bounced“, „blocked“, „complaint“ (falls verfügbar).
• OTP Audit: Generiert, gesendet, verifiziert, invalidiert; ohne den OTP-Wert im Klartext zu loggen.
• Frontend Telemetrie: Screen-State, Button-Disabled, Timer, Fehlermeldungs-Codes.

2) Basisszenarien: Der „Happy Path“ muss boring sein

2.1 Signup mit Wegwerf-E-Mail (E-Mail-Verifizierung)

1. Neue Wegwerf-Adresse erzeugen und in der Registrierung verwenden.
2. Form validieren: Pflichtfelder, Passwortregeln, DSGVO/AGB Checkboxen, Captcha (falls aktiv).
3. Submit: Ladezustand, Doppelklick-Schutz, Retry-Verhalten bei Netzwerkfehler.
4. Wechsel zum Postfach: E-Mail kommt an, Betreff/Absender korrekt, keine leeren Inhalte.
5. Verifizierungslink öffnen: Deep Link (Mobile) oder Browser-Flow (Web) funktioniert.
6. Nach Verifizierung: Login-Status, Redirect, Profilstatus („verified=true“), Onboarding-Schritte.

2.2 OTP per E-Mail (Code-Eingabe statt Link)

1. OTP anfordern und sicherstellen, dass UI einen klaren „Code gesendet“-Zustand zeigt.
2. OTP aus der E-Mail übernehmen: Copy/Paste, Autofill (iOS/Android), manuelle Eingabe.
3. Verifikation: Erfolgsmeldung, Weiterleitung, Session-Token/Refresh-Token korrekt gesetzt.
4. Falscher Code: Fehlermeldung verständlich, keine Information-Leaks (z. B. „User exists“).
5. Mehrfachversuch: Nach x Fehlversuchen Lockout oder Challenge (wenn vorgesehen).

2.3 Resend-Button & Cooldown

• Cooldown sichtbar: Timer läuft stabil, bleibt beim Screen-Refresh konsistent.
• Resend begrenzt: Max-Resends eingehalten; UI zeigt sinnvolle Hinweise.
• Alte Codes invalidieren: Nach Resend darf nur der neueste Code gültig sein.
• Mehrere Mails: Eindeutige Kennzeichnung (Timestamp/Reference), damit User nicht den falschen Code nehmen.

3) Zustellbarkeit & Timing: Der häufigste reale Fehler

3.1 Verzögerte Zustellung simulieren

• Test mit langsamer Verbindung (z. B. „Slow 3G“) und zusätzlicher Server-Latenz.
• OTP-Lifetime vs. typische Mail-Latenz: Code darf nicht regelmäßig ablaufen, bevor er ankommt.
• UI muss „Noch nichts angekommen?“ sauber erklären und Resend nicht zu früh erzwingen.

3.2 Timeouts & Ablauf

• OTP abgelaufen: Fehlermeldung eindeutig, UI bietet direkt „Neuen Code senden“.
• Link abgelaufen: Fallback-Flow vorhanden, z. B. erneute Verifizierungs-Mail anfordern.
• Client Clock Drift: Ablaufberechnung serverseitig; der Client zeigt nur Countdown basierend auf Serverwerten.

3.3 Disposable-Domain-Blocker

• Wenn Wegwerf-Domains blockiert werden: Fehlertext ohne Moral, mit klarer Handlung („Bitte andere E-Mail verwenden“).
• Block sollte konsistent sein: Schon im Input validieren, nicht erst nach Submit.
• Wenn erlaubt: Kein „Shadow Ban“ (Mail wird angeblich gesendet, kommt aber nie).

4) Sicherheits- und Missbrauchstests (ohne Overkill)

4.1 Enumeration verhindern

• Existiert User? Fehlermeldungen dürfen nicht verraten, ob E-Mail registriert ist.
• Passwort-Reset und Signup sollten ähnliche Antworten geben, ohne interne Zustände preiszugeben.
• Response-Timing nicht verräterisch: gleiche „shape“ und ähnliche Latenz bei Exists/Not-Exists.

4.2 Rate-Limits & Abuse Controls

• OTP-Request Rate-Limit pro IP, pro E-Mail, pro Device prüfen.
• Resend-Spam verhindern: Cooldown + Max-Resends + ggf. Captcha nach Schwellenwert.
• Lockout-Policy: Nach zu vielen falschen Codes temporäre Sperre oder Challenge.

4.3 Replay & Token-Sicherheit

• Verifizierungslink darf nur einmalig nutzbar sein; Wiederverwendung führt zu sauberem Hinweis.
• OTP darf nicht mehrfach akzeptiert werden; nach Erfolg invalidieren.
• Session: Token-Rotation, Secure Cookies, HttpOnly, SameSite; auf Mobile: Keychain/Keystore.

5) UX-Checks: Der Flow muss verständlich und „stressfrei“ sein

5.1 Fehlermeldungen & Microcopy

• Fehlertexte auf Deutsch klar, kurz, ohne technische Codes.
• Konkrete Handlungsanweisung: „Neuen Code senden“, „E-Mail prüfen“, „Spam-Ordner prüfen“.
• Keine Überwältigung: Nicht fünf Hinweise auf einmal, lieber kontextbezogen.

5.2 Eingabe & Accessibility

• OTP-Felder: Auto-Advance, Backspace-Verhalten, Paste eines gesamten Codes funktioniert.
• Keyboard-Type numerisch, Fokus korrekt, Screenreader Labels vorhanden.
• Kontrast & Button-States: Disabled, Loading, Error-State sichtbar.

5.3 State-Management (Web/Mobile)

• Refresh/Back/Foreground: Timer und „Code gesendet“-Status bleiben konsistent.
• Deep Link Handling: App nicht in einen kaputten Zwischenzustand fallen lassen.
• Abbruch & Restart: Nutzer kann den Flow sauber neu starten, ohne „Zombie“-Sessions.

6) Edge-Cases: Hier entscheidet sich Robustheit

6.1 Mehrfach-Submit & Race Conditions

• Doppelklick auf „Registrieren“ erzeugt keine doppelten Accounts.
• Resend + Code-Eingabe parallel: Backend muss eindeutig definieren, welcher Code gültig ist.
• Mehrere Tabs/Devices: OTP nur im erwarteten Kontext akzeptieren (optional, je nach Produkt).

6.2 Mail-Inhalt & Rendering

• Plaintext & HTML-Version vorhanden; Links funktionieren ohne Tracking-Breakage.
• Betreff eindeutig („Dein Code:“ oder „Verifizierung“), Absender-Domain konsistent.
• Kein „From“-Spoofing: DMARC/SPF/DKIM idealerweise korrekt (zumindest in Prod).

6.3 Internationalisierung & Formatfallen

• Deutsche Umlaute/ß in Namen/Betreff – keine kaputten Encodings.
• Datum/Zeit in Mails nachvollziehbar (am besten relativ: „gerade eben“ oder klare Zeitzone).
• Telefonnummern/Region-Inputs: Validierung nicht zu streng, aber korrekt.

6.4 Bounce/Block-Fälle

• Wenn die Mail nicht zugestellt wird: System erkennt es (wenn möglich) und zeigt alternative Schritte.
• Kein endloser Spinner: UI muss nach sinnvoller Zeit reagieren und Optionen anbieten.
• Support-CTA: Bei wiederholtem Scheitern „Kontakt“ oder „Alternative Methode“ anzeigen.

7) Debugging-Leitfaden: Wenn QA etwas findet, muss Dev es reproduzieren können

7.1 Minimaler Bug-Report für OTP/Signup

• Build/Version: App-Version, Commit, Environment, Feature Flags.
• Schritte: Exakt, nummeriert, inklusive „Resend geklickt“, „Tab gewechselt“, „App in Hintergrund“.
• Erwartet vs. Tatsächlich: Was sollte passieren, was ist passiert?
• Timing: Uhrzeiten, Wartezeiten, ob Mail verspätet kam.
• IDs: Correlation ID, User-ID (falls erstellt), OTP-Request-ID, Mail-Event-IDs.
• Screenshots: UI-State + Postfach-Ansicht (sensible Infos unkenntlich machen).

7.2 Typische Ursachen schnell eingrenzen

• Mail nie angekommen: Domain geblockt, Provider bounct, Rate-Limit, Queue-Problem, Template-Fehler.
• Code immer „falsch“: Whitespace, Copy/Paste trimming, falsches OTP-Format, Locale-Parser.
• Code abgelaufen: Lifetime zu kurz, Zustellung zu langsam, UI zeigt falschen Countdown.
• Resend wirkt kaputt: Cooldown-UI und Backend-Regeln nicht synchron, alte Codes nicht invalidiert.
• Deep Link bricht: Link-Handling, Universal Links/App Links, Session nicht vorhanden.

8) Abnahme-Kriterien: „Ready for Release“ für Signup + OTP

• Happy Path ist stabil: mindestens 10 Wiederholungen ohne intermittierende Fehler.
• Resend/Timeout/Expired sind sauber: eindeutige UI, klare nächste Schritte, kein Dead-End.
• Rate-Limits greifen: Missbrauch wird gebremst, legitime Nutzer:innen werden nicht unnötig blockiert.
• Keine Enumeration: Antworten verraten keine Account-Existenz; keine verräterischen Statuscodes.
• Logging reicht aus: Ein QA-Fall kann in Logs nachverfolgt werden, ohne sensitive Daten zu leaken.
• Barrierefreiheit & Usability sind okay: Fokus, Autofill, Paste, verständliche Texte.

Wenn du diese Liste konsequent abarbeitest, findest du die klassischen OTP-Probleme früh: zu kurze Timeouts, schlechte Resend-UX, unklare Fehlermeldungen, inkonsistente States und fehlende Observability. Und genau das sind die Punkte, die später in Reviews und Support-Tickets am teuersten werden.