Checkliste für Website-Tests

Eine Website-Testcheckliste unterstützt systematische Überprüfung, verspricht aber nicht, jeden Defekt zu finden. Ihr Wert liegt im gemeinsamen Verständnis von Umfang, erwarteten Ergebnissen und Restrisiken. Eine Liste kann Nachrichtenseite, Bankingportal und internes Verwaltungspanel nicht gleich gut abdecken.

Passen Sie die Punkte vor dem Lauf an Produkt und Release an. Eine Änderung am Bestellformular braucht eine andere Prüftiefe als eine Textkorrektur im Footer. Die folgenden Prüfungen bilden eine Grundlage: Wählen Sie passende Punkte und ergänzen Sie änderungsspezifische Risiken.

Testkontext vorbereiten

Dokumentieren Sie Build, Umgebung, Änderungen, Rollen, Testdaten und unterstützte Browser. Bestimmen Sie den kritischen Ablauf: Welches Ergebnis bringt Benutzer auf die Seite, und welcher Ausfall wäre besonders teuer?

Jeder Punkt benötigt Ergebnis und Beleg. Verwenden Sie „bestanden“, „Defekt“, „blockiert“, „nicht getestet“ und „nicht anwendbar“ mit Erläuterungen. Übersprungene Tests zählen nicht als bestanden. Bereiten Sie sichere Umgebung und Daten für Testzahlungen, E-Mails und Löschungen vor.

→Öffnen Sie Startseite und wichtige Seiten direkt per URL: Der richtige Inhalt lädt, erforderliche Ressourcen funktionieren.
→Laden Sie eine verschachtelte Seite neu: Server und Client erhalten die richtige Route ohne unerwarteten Fehler.
→Navigieren Sie zurück und vorwärts: Das UI stellt einen konsistenten Zustand wieder her und wiederholt keine Aktion versehentlich.
→Öffnen Sie eine nicht existierende Adresse: Eine verständliche Fehlerseite ermöglicht das Fortsetzen; die HTTP-Antwort passt zum Zweck der Ressource.
→Prüfen Sie Menüs, interne Links und Übergänge zu externen Diensten: keine Sackgassen, falschen Domains oder Redirectschleifen.

Berücksichtigen Sie neue und bestehende Sitzungen. Eine frisch geöffnete Seite und ein lange offener Tab können unterschiedliche Assetversionen und Zustände erhalten.

Das zentrale Geschäftsszenario prüfen

Durchlaufen Sie den gesamten Weg vom Einstieg zum Ergebnis und prüfen Sie anschließend dessen tatsächliche Speicherung. Eine Erfolgsmeldung allein bestätigt keine Datenänderung.

Bei einem Shop bedeutet das Produktsuche, Warenkorb, Checkout und Bestellansicht. Bei einer Wissensdatenbank sind es Artikelsuche und Lesen, verwandte Inhalte und eine korrekte URL zum Teilen. Nutzen Sie realistische Rollen und Daten: Administratoren umgehen möglicherweise Beschränkungen gewöhnlicher Benutzer.

Formulare und Daten prüfen

→Leere, gewöhnliche und Grenzwerte werden vertragsgemäß behandelt; Fehler helfen bei der Korrektur.
→Schaltfläche und Enter lösen konsistentes Absenden aus; wiederholte Klicks verdoppeln keine Operation.
→Nach Serverablehnung bleiben gültige Werte erhalten und ein klarer Wiederholungsweg besteht.
→Lange Texte, kyrillische Zeichen, verschiedene Sprachregionen und Datumsformate beschädigen keine Daten.
→Uploads und Downloads erfüllen Anforderungen an Typ, Größe, Dateiname und Zugriff.

Vergleichen Sie Eingaben, Anfrage, Antwort und anschließend gelesenen Zustand. Diese Kette hilft, Präzisionsverlust oder unbemerkte Normalisierung zu erkennen.

Anmeldung, Rollen und Sitzungen prüfen

Bestätigen Sie, dass Anmeldung, Abmeldung, Sitzungsablauf und erneute Authentifizierung der Produktrichtlinie folgen. Testen Sie eine geschützte URL ohne Anmeldung und eine Operation mit einer Rolle ohne nötige Berechtigung.

Prüfen Sie mit vorbereiteten Konten Zugriff auf ein fremdes Testobjekt über UI und API. Eine versteckte Schaltfläche ersetzt keine serverseitige Zugriffskontrolle. Nach Benutzerwechsel dürfen Daten des vorherigen Kontos weder aus Appzustand noch aus falsch verwendetem Cache erscheinen.

Fehler, Netzwerkverhalten und Wiederherstellung prüfen

Verlangsamen Sie das Netzwerk, unterbrechen Sie eine Anfrage, erzeugen Sie einen vorgesehenen Serverfehler und liefern Sie eine leere Antwort. Erwarten Sie einen klaren Zustand, endende Ladeanzeige und einen definierten Weg zur Fortsetzung.

Besonders wichtig ist ein ungewisses Ergebnis: Der Server kann eine Bestellung gespeichert haben, obwohl der Client keine Antwort erhielt. Ein Retry darf nicht still eine zweite Bestellung anlegen. Prüfen Sie Serverkonsistenz und vorgesehenen Duplikatschutz. Nutzen Sie Console und Network zur Diagnose, bewerten Sie das Ergebnis aber anhand von Produktverhalten und Daten.

Darstellung und Barrierefreiheit prüfen

Wählen Sie Browser und Größen aus der Unterstützungsmatrix. Führen Sie die kritische Aktion in schmalem Fenster, mit langem Inhalt und erhöhtem Zoom aus. Fixierte Flächen und Tastatur dürfen erforderliche Aktionen nicht verdecken.

Durchlaufen Sie den Ablauf mit der Tastatur; prüfen Sie sichtbaren Fokus, Feldbeschriftungen, verständliche Fehler und zugängliche Schaltflächennamen. Nutzen Sie bei Bedarf einen Screenreader. Automatische Prüfungen liefern zusätzliche Hinweise, beweisen aber nicht die Zugänglichkeit jedes Prozesses.

Öffentliche Sichtbarkeit und Releaseeinstellungen prüfen

Prüfen Sie bei öffentlichen Seiten Titel, Beschreibung, Canonical, Robots-Regeln, Sitemap und erwartete Weiterleitungen. Bei privaten Diensten sind korrekte Zugriffsbeschränkungen wichtiger. Wenden Sie Anforderungen zur Suchindexierung nicht auf private Kontobereiche an.

Prüfen Sie Produktionskonfiguration: API-Domains, Links, Assets sowie das Fehlen von Test-Stubs und Diagnosegeheimnissen. Führen Sie nach der Bereitstellung einen kurzen Smoke-Test mit autorisierten Daten aus. Last- und destruktive Tests bleiben auf vorher festgelegte Umgebung und vereinbarten Umfang beschränkt.

Praxisbeispiel: Checkout-Release

Angenommen, Adressformular und Versandberechnung wurden geändert. Priorisieren Sie Checkout-Abschluss, Adressgrenzen, Wechsel der Versandart und Wiederholung nach Timeout.

1.Erstellen Sie eine Testbestellung mit gewöhnlicher Adresse. Erwarten Sie einen Datensatz mit richtiger Adresse, Betrag und Versandart.
2.Geben Sie am Telefon eine lange Adresse ein und korrigieren Sie einen Fehler. Meldungen und Schaltfläche müssen bei geöffneter Tastatur erreichbar bleiben.
3.Ändern Sie die Adresse vor Abschluss der Berechnung. Die neueste Auswahl muss gelten, nicht eine verspätete Antwort.
4.Wiederholen Sie die Bestätigung nach simuliertem Antwortausfall. Erwarten Sie konsistenten Status ohne Duplikat.
5.Prüfen Sie die Bestellansicht unter einer anderen Testrolle. Zugriffsregeln müssen greifen.

Wählen Sie weitere Punkte anhand betroffener Abhängigkeiten und Fehlerhistorie statt lediglich die gesamte Liste abzuarbeiten.

Den Lauf abschließen

Verknüpfen Sie im Bericht Defekte mit Checklistenpunkten und nennen Sie abgedeckte Umgebungen, Blocker und ungetestete Bereiche. Unterscheiden Sie „keine bekannten Defekte gefunden“ von „kein Risiko vorhanden“: Letzteres kann Testen nicht beweisen.

Häufige Fehler sind gleiche Prüftiefe für jedes Release, fehlende erwartete Ergebnisse und grüne Markierung blockierter Prüfungen. Eine gute Checkliste unterstützt eine Releaseentscheidung anhand von Belegen und ausdrücklich genannten Grenzen.

Weiterführende Informationen

Ein beleggestütztes Arbeitsblatt für Web-Releases

Verwenden Sie eine konkrete Aufgabe wie das Absenden eines fiktiven Kontaktformulars. Vereinbaren Sie vorher Feldregeln, Erfolgsverhalten und unterstützte Browser. Die folgenden Zeilen legen Beobachtungen fest; sie bilden ein kompaktes Releasearbeitsblatt, keine vollständige Sicherheits- oder Barrierefreiheitsprüfung. Dokumentieren Sie tatsächliche Ergebnisse getrennt von Erwartungen.

plain text

Bereich	Aktion	Erwartete Beobachtung	Zu sammelnde Nachweise
Funktion	Ein gültiges Formular absenden	Ein akzeptierter Versand und klare Bestätigung	Anfrage-ID + UI
Validierung	Ohne erforderliche E-Mail-Adresse absenden	Konkreter Fehler; kein Erfolg; ungültige Anfrage vertragsgemäß behandelt	UI + Anfrageprotokoll
Tastatur	Aufgabe mit Tab/Shift+Tab/Enter abschließen	Sichtbarer Fokus; erreichbare Bedienelemente; keine Tastaturfalle	Video
Beschriftungen	Zugängliche Namen der Eingaben prüfen	Name beschreibt den Zweck; Fehler seinem Feld zugeordnet	Barrierefreiheitsbaum
Responsives Layout	Vereinbarte schmale/breite Viewports verwenden	Keine abgeschnittenen Bedienelemente; Inhalt nutzbar	Viewport + Screenshot
SEO	HTML der öffentlichen Seite abrufen	Korrekte Sprache, Titel, Canonical und Indexierungsregel	Header + HTML-Auszug
Netzwerk	Vor/nach dem Absenden unterbrechen	Kein falscher Erfolg; sichere Wiederherstellung ohne doppeltes Absenden	Netzwerkmitschnitt
Daten	Akzeptierte Eingabe wieder auslesen	Gespeicherte Werte entsprechen Eingabe und Zugriffsrichtlinie	Datensatznachweis ohne sensible Daten

Die Beispielbeobachtung ist hypothetisch: Zeigt die Schaltfläche „Gesendet“, während die Anfrage einen Serverfehler liefert, dokumentieren Sie Status, Zeitpunkt und UI-Zustand; behaupten Sie keine Speicherung. Umgekehrt beweist ein Timeout keine Ablehnung des Schreibvorgangs. Klären Sie das Ergebnis vor einer Wiederholung.

QA-Hub-Werkzeuge unterstützen konkrete Belege: URL-Parser erklärt Abfrageparameter, JSON-Formatter macht Antwortstrukturen lesbar, JSON-Diff vergleicht erwartete und tatsächliche Payloads, HTTP-Codes bietet eine Referenz. Sie entscheiden nicht, ob eine Produktanforderung erfüllt ist. Schließen Sie mit bekannten Fehlern, ungetestetem Umfang, Verantwortlichen und einer Release-Risikoentscheidung ab.