DevTools gehört zu den nützlichsten Werkzeugen für Web-QA. Es zeigt, was hinter der sichtbaren Seite im Browser geschieht: gesendete Anfragen, Serverantworten, JavaScript-Fehler, Cookies und Storage, Gründe für nicht klickbare Elemente und überlagernde UI-Schichten.
Viele Anfänger öffnen DevTools erst bei Fehlern. Das hilft, doch bei Routinetests offen zu bleiben ist die bessere Gewohnheit. Ungewöhnliche Signale fallen früher auf; Untersuchungen beginnen mit mehr Belegen als „wirkt irgendwie kaputt“.
Warum DevTools für QA wichtig ist
Der Hauptwert von DevTools liegt darin, die verantwortliche Fehlerschicht schnell zu finden.
Dasselbe Symptom „Formular speichert nicht“ kann sehr Unterschiedliches bedeuten:
- →Die Schaltfläche ist aufgrund des DOM-Zustands inaktiv.
- →Ein Event-Handler wurde nicht ausgeführt.
- →Es wurde keine Anfrage gesendet.
- →Die Anfrage wurde gesendet, aber der Server antwortete mit einem Fehler.
- →Die Antwort war erfolgreich, das UI wurde jedoch nicht aktualisiert.
- →Die Daten wurden gespeichert, die Seite zeigt aber einen alten Zustand.
- →In der Konsole erscheint ein für Benutzer unsichtbarer Fehler.
Ohne DevTools wirkt alles wie derselbe Defekt. Mit DevTools kann ein QA-Engineer innerhalb einer Minute eine Untersuchungsrichtung bestimmen.
Die nützlichsten Panels für QA
Nicht jeder Teil von DevTools muss gleich tief bekannt sein. Einige Panels liefern den größten Alltagsnutzen.
- →Elements: DOM, Attribute, Klassen, versteckte Elemente, deaktivierte Zustände, Layout und Styles untersuchen.
- →Network: Anfragen, Antworten, Header, Payloads, Zeitverhalten, Weiterleitungen und Caching untersuchen.
- →Console: JavaScript-Fehler, Warnungen und Laufzeitprobleme erkennen.
- →Application: Cookies, localStorage, sessionStorage, Service Worker und Appzustand im Browser untersuchen.
- →Sources: Fehler in JavaScript-Logik lokalisieren, Breakpoints setzen oder Source Maps ansehen.
Schon diese Auswahl kann Webtests deutlich verbessern.
Elements: Warum ein Element existiert, aber nicht funktioniert
Das Elements-Panel zeigt die tatsächliche Seitenstruktur. Das hilft besonders, wenn die visuelle Oberfläche täuscht.
Prüfen Sie damit:
- →Ob das Element tatsächlich im DOM existiert oder nur vorhanden zu sein scheint
- →Ob CSS es versteckt
- →Ob es deaktiviert ist
- →Ob eine andere Schicht es überdeckt
- →Ob es außerhalb des Bildschirms liegt
- →Welche Klassen und Attribute es tatsächlich besitzt
- →Ob sich das DOM nach einer Benutzeraktion ändert
Das hilft bei Formularen, Modals, Tooltips, Dropdowns, Tabellen, dynamischen Bereichen sowie Lade-, Fehler- und Leerzuständen.
Network: Die Verbindung zwischen UI und Backend
Wenn Sie nur einen DevTools-Tab beherrschen, sollte es fast immer Network sein.
Er zeigt:
- →Welche Anfrage gesendet wurde
- →An welche URL sie ging
- →Welche Methode verwendet wurde
- →Welche Header und welcher Body gesendet wurden
- →Welcher Status zurückkam
- →Was die Antwort enthielt
- →Wie lange die Anfrage dauerte
- →Ob eine Weiterleitung auftrat
- →Ob doppelte oder unnötige Aufrufe stattfanden
- →Ob Caching das Ergebnis beeinflusste
Network hilft schnell, UI- und Backendprobleme zu unterscheiden. Wurde keine Anfrage gesendet, liegt die Ursache fast sicher im Frontend. Liefert der Server 403, das UI aber „unbekannter Fehler“, ist die Antwortbehandlung fehlerhaft. Bei zwei statt einer Anfrage prüfen Sie Doppelsenden, Retries oder unnötiges Rendern.
Für QA-Engineers verbindet Network die Benutzeraktion mit dem tatsächlichen technischen Systemverhalten.
Console: Fehler, die auf der Seite unsichtbar bleiben
Console hilft besonders, wenn sich die Oberfläche seltsam verhält, ohne Benutzern einen ausdrücklichen Fehler zu zeigen.
- →Eine Schaltfläche lässt sich klicken, aber nichts passiert.
- →Ein Seitenteil wird nicht neu gerendert.
- →Ein Modal öffnet sich nicht.
- →Ein Filter hängt.
- →Ein Szenario funktioniert, ein anderes scheitert unerwartet nach dem vorherigen Schritt.
Oft steht dann bereits ein JavaScript-Fehler in Console. Das verbessert die Untersuchung erheblich. Statt „öffnet sich manchmal nicht“ können Sie einen konkreten Laufzeitfehler samt Kontext in den Fehlerbericht aufnehmen.
Trennen Sie nützliche Signale vom Rauschen. Große Projekte erzeugen viele Warnungen und Konsolenmeldungen Dritter. Achten Sie besonders auf neue Meldungen, die genau während Ihres Szenarios erscheinen.
Application: Benutzerzustand im Browser
Das Application-Panel ist besonders wichtig bei Szenarien mit:
- →Sitzungen
- →Autorisierung
- →Angemeldet bleiben
- →Storage
- →Feature-Flags
- →Service Workern
- →Caching und Offlineverhalten
Untersuchen Sie damit:
- →Welche Cookies tatsächlich gesetzt sind
- →Was localStorage und sessionStorage enthalten
- →Was nach der Abmeldung verbleibt
- →Ob alte Zustände über Sitzungen hinweg erhalten bleiben
- →Ob ein Service Worker das Appverhalten beeinflusst
- →Ob die Seite einen veralteten Cache verwendet
Viele scheinbar unerklärliche Webfehler sind tatsächlich Clientzustandsprobleme. Ohne dieses Panel werden sie leicht für zufällige Instabilität gehalten.
Nützliche DevTools-Gewohnheiten für QA
- →Öffnen Sie Network vor Beginn des Szenarios.
- →Leeren Sie das Protokoll und konzentrieren Sie sich auf Anfragen der aktuellen Aktion.
- →Vergleichen Sie erfolgreiche und erfolglose Szenarien.
- →Prüfen Sie neben dem Statuscode auch Antwort und Zeitverhalten.
- →Kontrollieren Sie Console nach ungewöhnlichem UI-Verhalten.
- →Nutzen Sie Application bei Problemen mit Login, Tabs, Neuladen und Logout.
- →Verwenden Sie Elements, wenn eine Schaltfläche vorhanden ist, aber nicht funktioniert.
Diese einfachen Gewohnheiten verbessern die Testqualität oft schnell.
Praxisbeispiel
Stellen Sie sich folgenden Fehler vor: Der Benutzer klickt „Bezahlen“, und die Anzeige bleibt im Ladezustand hängen.
Hilfreiche DevTools-Prüfungen sind:
- →In Network prüfen, ob überhaupt eine Anfrage gesendet wurde.
- →Falls ja, Status, Antwort und Dauer untersuchen.
- →In Console prüfen, ob das Frontend nach Empfang der Antwort scheiterte.
- →In Elements prüfen, ob ein Lade-Overlay die Oberfläche dauerhaft blockiert.
- →In Application prüfen, ob der Sitzungszustand beschädigt ist oder notwendige Daten fehlen.
Ohne DevTools lautet der Bericht vielleicht „hängt manchmal“. DevTools unterscheidet Backend-Timeout, JavaScript-Fehler, doppelte Anfrage, veralteten Zustand oder defektes Lade-Overlay.
Wichtig für QA-Engineers
- →DevTools macht das tatsächliche Browserverhalten zusätzlich zum sichtbaren Ergebnis erkennbar.
- →Die nützlichsten QA-Panels sind Elements, Network, Console und Application.
- →Die meisten Webfehler sind leichter einzugrenzen, wenn neben dem Bildschirm DOM, Anfragen, Fehler und Browserzustand untersucht werden.
- →Öffnen Sie DevTools bei Routinetests ebenso wie bei Fehlern.
- →Je sicherer Sie DevTools verwenden, desto schneller unterscheiden Sie Frontend- und Backendprobleme und schreiben präzise Fehlerberichte.
Weiterführende Informationen
- →In dieser Wissensdatenbank: Cookies, SessionStorage, LocalStorage
- →In dieser Wissensdatenbank: HTTP und HTTPS
- →Externe Ressource: Chrome-DevTools-Dokumentation
- →Externe Ressource: Überblick über Chrome DevTools
- →Externe Ressource: Firefox-DevTools-Benutzerdokumentation