Web-Application-Testing bezeichnet die systematische Prüfung von Anwendungen, die im Browser laufen — etwa SaaS-Backends, E-Commerce-Systeme oder Online-Tools — in acht Dimensionen: Funktionslogik, Formularvalidierung, browserübergreifende Kompatibilität, Responsive Design, Performance, Sicherheit und Barrierefreiheit. Dieser Artikel enthält eine direkt kopierbare Checkliste mit über 40 Prüfpunkten für die Abnahme vor dem Release, Regressions-Tests und Smoke-Tests neuer Builds.
Web-App-Test ≠ Website-Test
| Dimension |
Website-Test |
Web-App-Test |
| Typische Objekte |
Unternehmenswebsite, Landingpages, Blog |
SaaS-Systeme, Admin-Backends, Online-Editoren |
| Interaktionstiefe |
überwiegend Browsen und Formular-Submit |
Login-Sitzungen, komplexe Statusflüsse, Berechtigungen, Nebenläufigkeit |
| Testschwerpunkt |
Inhalte, SEO, visuelle Gestaltung, Conversion-Pfade |
Geschäftslogik, Datenkorrektheit, Fehlerbehandlung |
| Zustandskomplexität |
niedrig (weitgehend zustandslos) |
hoch (Sitzungen, Cache, mehrere Rollen) |
Wenn dein Ziel eine Marketing-Website ist, ist diese Checkliste zu umfangreich — nimm stattdessen die Website QA Checklist. Dieser Artikel richtet sich an „Anwendungen" mit Login und Geschäftslogik.
Vorbereitung vor dem Test
- Testumfang und Version festlegen (Commit-Hash oder Build-Nummer dokumentieren)
- Umgebungsmatrix vorbereiten: mindestens 1 Staging-Umgebung + eine Umgebung für den Produktions-Vorabcheck
- Kontomatrix vorbereiten: Normalnutzer / Admin / ausgeloggt — je mindestens 1 Konto
- Testdaten vorbereiten: Normalwerte + Grenzwerte (sehr lange Strings, Sonderzeichen, Leerwerte, große Dateien)
Die Web-Application-Testing-Checkliste
A. Funktionstest (Kerngeschäftsprozesse)
- Kompletten Ablauf Registrierung → E-Mail-Verifizierung → Login durchtesten
- Passwort vergessen → Zurücksetzen → Login mit dem neuen Passwort prüfen
- Jeden Kerngeschäftsprozess (Bestellung, Erstellen, Speichern) einmal im positiven Fall durchlaufen
- Ausnahmezweige jedes Kernprozesses prüfen: Abbruch mittendrin, Doppel-Submit, Erholung nach Netzausfall
- Rechte-Trennung prüfen: Normalnutzer erreichen Admin-Funktionen nicht (auch nicht per direkter URL)
- Datenkonsistenz prüfen: Liste, Detailseite und Statistiken werden nach Aktionen synchron aktualisiert
- Sicherstellen, dass geschützte Seiten nach dem Logout nicht erreichbar sind (der Zurück-Button umgeht die Authentifizierung nicht)
B. Formular- und Eingabevalidierung
- Klare Fehlermeldung zeigen und Submit blockieren, wenn Pflichtfelder leer sind
- Formate prüfen: E-Mail, Telefonnummer, Datum, Zahlenbereiche
- Grenzwerte testen: Maximallänge, Minimalwert, 0, negative Zahlen, sehr lange Eingaben (1000+ Zeichen)
- Sicherstellen, dass Sonderzeichen und Skript-Eingaben (
<script>, Emoji, SQL-Fragmente) sicher verarbeitet werden
- Schutz vor Doppel-Submit prüfen: schnelles Doppelklicken erzeugt genau einen Datensatz
- Datei-Uploads testen: Typbeschränkung, übergroße Dateien, 0-Byte-Dateien, abgebrochene Uploads
- Prüfen, ob der Formularzustand nach Browser Zurück/Vorwärts sinnvoll bleibt
C. Browserübergreifende Kompatibilität
- Firefox (neueste Version)
- Bekannte Unterschiede im Blick behalten: Datumspicker, Datei-Downloads, Scrollverhalten, CSS-Layout
D. Responsive Design und Mobile
- Breakpoints durchgehen: 1920 / 1366 / 768 / 375 Pixel Breite
- Navigation, Modals und Tabellen auf dem Smartphone bedienen (kein horizontaler Scroll-Overflow)
- Touch-Ziele groß genug gestalten; Hover-Funktionen durch Touch-Alternativen ersetzen
- Hoch- und Querformat wechseln (falls zutreffend)
- Sicherstellen, dass Eingabefelder bei geöffneter Bildschirmtastatur sichtbar bleiben
E. API und Fehlerbehandlung
- DevTools-Konsole und Netzwerk-Panel öffnen, Kernprozesse durchlaufen — keine roten Fehler
- Bei fehlgeschlagenen Requests (offline/500) eine verständliche Meldung zeigen statt weißem Bildschirm oder Einfrieren
- Ladezustände für langsame Requests anzeigen; doppelte Requests entprellen oder abbrechen
- Nach dem Sitzungsablauf klar zur Anmeldung führen (statt stillem Fehlschlag)
- Konsole frei von unbehandelten Ausnahmen halten (Uncaught Error)
F. Performance
- Ladezeiten-Ziele einhalten (empfohlen < 3s, LCP < 2.5s)
- Große Listen/Datenmengen ohne Ruckler (mit realistischen Datenmengen testen)
- Bilder komprimieren und Lazy-Loading einsetzen
- Auf Memory-Leaks achten (spürbares Verlangsamen nach längerer Nutzung)
G. Sicherheitsgrundlagen
- Geschützte Ressourcen ohne Login/Rechte weder per URL noch per API erreichbar machen
- Sensible Daten durchgängig über HTTPS übertragen
- Passwortfelder nie im Klartext anzeigen
- Keine sensiblen Tokens in Seiten-URLs (oder maskieren und ablaufen lassen)
- Fehlermeldungen ohne Stacktraces und technische Details für Endnutzer halten
H. Barrierefreiheit und Details
- Kernaktionen allein per Tastatur abschließen (Tab-Reihenfolge, Enter zum Absenden)
- Alt-Texte für Bilder ergänzen und Labels mit Formularfeldern verknüpfen
- Farbkontrast mindestens WCAG AA (4.5:1) einhalten
- Leere-, Lade- und Fehlerzustände gestalten (nie ein weißer Bildschirm)
Testergebnisse dokumentieren und nachverfolgen
| Vorgehen |
Bedeutung |
| Jedem Defekt Belege beifügen |
Screenshot annotieren, um die Fundstelle zu markieren; Interaktionsprobleme als Video aufnehmen |
| Technischen Kontext automatisch erfassen |
Console-/Network-Fehler per Tool mitschneiden lassen (z. B. BugCapturer) statt manuell abzutippen |
| Strukturiert ablegen |
Defektliste als Excel exportieren (Nr./Modul/Schritte/Soll/Ist/Schweregrad/Status) |
| Ergebnisse teilbar machen |
Bei teamübergreifender Abstimmung einen Share-Link erzeugen statt Dateien zu verschicken |
Die Diagnosefunktion von BugCapturer löst die mittleren drei Punkte in einem Schritt: Beim Screenshot oder Screen-Recording werden Console- und Network-Fehler automatisch miterfasst, und es entstehen installationsfreie Share-Links – oder der Bericht geht direkt in Lark Bitable bzw. einen Webhook. Details findest du auf der Produktseite zur Diagnose.
Für die finale Freigabe vor dem Release empfiehlt sich eine Runde User-Acceptance-Testing nach dem UAT Complete Guide — mit dieser Checkliste als Ausführungsunterlage.
FAQ
Wie lange dauert das Testen einer Webanwendung?
Das hängt vom Umfang ab. Ein Smoke-Test für einen neuen Build dauert 0,5–1 Tag, eine vollständige Regression 2–5 Tage; für große Releases sind meist 1–2 Wochen eingeplant (inkl. Fix-Verifikation). Alle 8 Gruppen dieser Checkliste durchzugehen kostet etwa 1–2 Personentage.
Wie verteilt man manuelles und automatisiertes Testen?
Faustregel: A/B/C/D zuerst manuell abdecken (besonders beim ersten Release) und nach der Stabilisierung die häufigen Regressionspfade (Login, Kernprozesse) automatisieren. Gruppe E (Console-/Network-Prüfung) lässt sich toolgestützt erfassen; Sicherheit (G) sollte durch professionelle Scanner und Code-Audits ergänzt werden.
Wie verhält sich diese Checkliste zu einem Testplan?
Die Checkliste beantwortet „was testen"; das Test Plan Template beantwortet „wer testet wann in welcher Umgebung und nach welchen Kriterien". Lege zuerst den Plan fest, dann führe die Checkliste aus — beide Dokumente gehören zusammen.
Wie nutzt ein Team ohne QA diese Checkliste?
Aufteilen: Entwickler testen selbst A/B/E (das Technische), das Produktteam nimmt A/D ab (Geschäft und Erfahrung), und vor dem Release läuft ein 2-stündiger Bug Bash mit allen (Organisation siehe Bug Bash Guide). Alles mit einer Vorlage inklusive Screenshots und Diagnoseinfos festhalten, um Abstimmungsaufwand zu senken.
Fazit
Entscheidend beim Web-App-Test ist nicht „so viel Anstrengung wie möglich", sondern volle Dimensionsabdeckung + nachvollziehbare Ergebnisse: die acht Dimensionen — Funktion, Formulare, Kompatibilität, Responsive, Fehlerbehandlung, Performance, Sicherheit, Barrierefreiheit — entlang der Checkliste abarbeiten und jeden Fund als „annotierter Screenshot + Console-/Network-Diagnose + strukturierter Eintrag" ablegen. Diese Checkliste lässt sich direkt als Ausführungsunterlage in den Testplan übernehmen.
Weiterlesen: Website QA Checklist · Test Plan Template · UAT Complete Guide