QA-Automation-Interviews prüfen Framework-Wissen, Automatisierungsmuster und vor allem, ob du Tests schreiben kannst, die aus einem anderen Grund als Glück grün bleiben. Hier sind häufige Fragen mit Musterantworten.
Zu jeder Frage gibt es eine Musterantwort, mit der du deine eigene vergleichen kannst.
Das Page Object Model kapselt jede Seite oder Komponente in einer Klasse, die Locators und High-Level-Aktionen bereitstellt, sodass Tests eine Absicht beschreiben statt einzelner Klicks. Das gelöste Problem ist die Wartbarkeit: Ändert sich die UI, aktualisierst du ein Page Object statt fünfzig Tests. Außerdem beseitigt es Duplizierung und macht Tests für Leute lesbar, die sie nicht geschrieben haben.
Ein implicit Wait ist eine globale Einstellung, die jede Elementsuche bis zu N Sekunden wiederholen lässt. Ein explicit Wait zielt auf genau eine Bedingung – Element klickbar, Text vorhanden – und wartet nur darauf. Ein fluent Wait ist ein explicit Wait mit konfigurierbarem Poll-Intervall und ignorierbaren Exceptions. Mischt man implicit und explicit, entstehen unvorhersehbare, sich addierende Timeouts, weshalb die meisten Teams implicit Waits komplett deaktivieren und nur explicit verwenden.
Die bevorzugte Reihenfolge ist ein dediziertes Testattribut wie data-testid, dann id, dann ein stabiler CSS-Selektor. XPath hat einen schlechten Ruf, weil absolute XPath-Ausdrücke bei jeder DOM-Änderung brechen und lange relative XPath-Ausdrücke schwer zu lesen sind. XPath selbst ist in Ordnung und manchmal notwendig – etwa um nach sichtbarem Text zu selektieren oder zu einem Elternelement zu navigieren –, das Problem ist brüchiges XPath, nicht die Sprache.
Ein flaky Test schlägt fehl und läuft grün, ohne dass sich der Code geändert hat. Übliche Ursachen sind Timing-Annahmen (feste Sleeps statt auf eine Bedingung zu warten), gemeinsam genutzte, veränderliche Testdaten, Abhängigkeit von der Ausführungsreihenfolge, Animationen sowie instabile Umgebungen oder Drittanbieterdienste. Lösungen: auf explizite Bedingungen warten, isolierte Daten pro Test erzeugen, Tests unabhängig und idempotent machen, externe Dienste stubben und flaky Tests unter Quarantäne stellen statt sie bis zum Grünwerden neu zu starten.
Parallelität wird auf Runner-Ebene konfiguriert und meist mit einem Selenium Grid oder Containern kombiniert. Die Probleme entstehen durch geteilten Zustand: Tests schreiben in denselben Benutzeraccount oder dieselben Datenbankzeilen, es kommt zu Port- und Dateikonflikten und zu Annahmen über die Ausführungsreihenfolge. Die Lösung ist, dass jeder Test seine eigenen Daten mit eindeutigen Kennungen erzeugt, kein globales Setup verwendet, das gemeinsame Ressourcen verändert, und nie davon ausgeht, allein zu laufen.
Playwright kommuniziert mit Browsern über das DevTools-Protokoll, wartet automatisch, bis Elemente ausführbar sind, und bringt Tracing, Netzwerk-Interception und parallele Isolation von Haus aus mit – dadurch braucht es deutlich weniger Wait-Logik. Selenium ist ein W3C-Standard mit der breitesten Unterstützung für Browser, Sprachen und Grids und tief in bestehender Enterprise-Infrastruktur verankert. Playwright eignet sich für ein neues Projekt mit Fokus auf moderne Browser, Selenium wählst du, wenn du breite Legacy-Unterstützung brauchst oder in ein bestehendes Selenium-Ökosystem passen musst.
Du prüfst Statuscodes, das Antwortschema, Werte im Body, Header und die Fehlerbehandlung bei ungültiger Eingabe sowie die Grenzen von Authentifizierung und Autorisierung. Typische Tools sind Postman oder Insomnia zum Explorieren sowie RestAssured, Playwright APIRequest, requests oder supertest für automatisierte Suiten. API-Tests sind günstiger und deutlich stabiler als UI-Tests, weshalb der Großteil der Abdeckung dort liegen sollte.
Die Pyramide besagt, dass du viele schnelle Unit-Tests, weniger Integrationstests und sehr wenige End-to-End-Tests haben solltest, weil Kosten und Flakiness nach oben hin steigen. Häufig wird eine Aufteilung von etwa 70/20/10 genannt, aber wichtiger als die Zahl ist das Prinzip: jede Prüfung auf der niedrigsten Ebene ansiedeln, die den Bug noch fangen kann. E2E-Tests sollten nur kritische Nutzerpfade abdecken, nicht die Geschäftslogik.
Tests laufen bei jedem Pull Request, meist aufgeteilt in eine schnelle Smoke-Suite bei jedem Commit und die volle Regression beim Merge oder nachts. Die Pipeline stellt eine saubere Umgebung bereit, führt Suiten parallel aus, veröffentlicht Reports und Artefakte wie Screenshots und Traces und lässt den Build bei Regressionen fehlschlagen. Damit das funktioniert, muss die Regel gelten, dass eine rote Pipeline den Merge blockiert – sonst verfällt die Suite.
Datengetriebenes Testen trennt Testlogik von Testdaten, sodass ein Test gegen viele Eingabesätze aus einer CSV, JSON oder einem parametrisierten Provider läuft. Es vervielfacht die Abdeckung, ohne den Code zu vervielfachen, und macht das Hinzufügen eines neuen Falls zu einer Datenänderung statt einer Codeänderung. Die Falle sind unlesbare Fehlermeldungen – nimm die Eingabedaten immer in den Testnamen auf, damit ein Fehlschlag zeigt, welcher Fall gebrochen ist.
Automatisiere stabile, wiederkehrende, wertvolle Prüfungen: Regressionssuiten, Smoke-Tests, API-Contracts und datenintensive Szenarien. Automatisiere nicht sich schnell änderndes UI, einmalige Prüfungen, explorative Arbeit, Usability- und visuelle Beurteilungen oder alles, bei dem Schreiben und Pflegen des Tests mehr kostet als das manuelle Ausführen. Die entscheidende Frage ist, wie oft die Prüfung laufen wird, bevor sie sich ändert.
Jeder Test sollte die Daten, die er braucht, selbst erzeugen und danach aufräumen, idealerweise über API-Aufrufe oder Datenbank-Seeding statt über das UI, weil das schneller und weniger fragil ist. Gemeinsam genutzte Fixture-Daten führen zu Reihenfolgeabhängigkeiten und rätselhaften Fehlschlägen. Bei Umgebungen sorgen Container oder ephemere Instanzen pro Pipeline-Lauf für Isolation; ist eine gemeinsame Umgebung unvermeidbar, versieh alle Daten mit einer eindeutigen Run-Kennung.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
QA Automation-Interview üben →