Führ mich durch, wie du eine Login-Seite testen würdest.

Deck vier Dimensionen ab: funktional (gültige und ungültige Zugangsdaten, Groß- und Kleinschreibung, Trimmen von Leerzeichen), Sicherheit (Rate Limiting, Sperrung, generische Fehlermeldungen, Session-Handling, TLS-Zwang), Usability und Barrierefreiheit (Tastaturnavigation, Screenreader-Labels, Passwortmanager-Unterstützung) und plattformübergreifendes Verhalten. Dann die umliegenden Flows: Passwort zurücksetzen, Angemeldet bleiben, abgelaufene Sessions und gleichzeitige Logins.

Ich würde es ordnen statt nur Fälle aufzuzählen, also funktional, Sicherheit, Usability und Kompatibilität. Funktional: gültige Zugangsdaten, falsches Passwort, unbekannter Nutzer, leere Felder, Groß- und Kleinschreibung bei der E-Mail, Trimmen von Leerzeichen und ob das Passwortfeld wirklich maskiert ist. Bei Sicherheit würde ich die meiste Zeit verbringen. Ich prüfe, dass die Fehlermeldung identisch ist, egal ob der Account existiert, denn eine abweichende Meldung für unbekannte Nutzer ist ein geschenktes Werkzeug zur Account-Enumeration. Dann Rate Limiting und Sperrverhalten, ob das Session-Cookie HttpOnly und Secure gesetzt ist, ob die Session-ID nach dem Login rotiert, um Fixation zu verhindern, ob Logout die Session serverseitig invalidiert statt nur das Cookie zu löschen, und ob Login über einfaches HTTP funktioniert. Dann Barrierefreiheit: Tab-Reihenfolge, Labels, die ein Screenreader ansagt, Fehler, die ihrem Feld zugeordnet sind, und ob ein Passwortmanager ausfüllen kann. Dann Kompatibilität über Browser und Mobilgeräte. Zuletzt die angrenzenden Flows, denn dort verstecken sich Bugs: Ablauf und Wiederverwendung des Reset-Tokens, Angemeldet bleiben über Neustarts hinweg, und was passiert, wenn eine Session mitten in einer Aktion abläuft.