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)
- Aufzeichnungstool und Konvention festlegen (Bug-Vorlage: test case template)
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
- Chrome (neueste Version)
- Firefox (neueste Version)
- Safari (macOS + iOS)
- Edge (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, ein 12-spaltiges Excel lässt sich mit einem Klick exportieren, und installationsfreie Share-Links lassen sich an Entwickler oder Kunden senden. Details findest du auf der Produktseite zur Diagnose; die vollständige Report-Struktur beschreibt How to Export Bug Reports to Excel.
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