Selenium-Interviewfragen

Du hast Tests geschrieben, die lokal bestehen und in der Pipeline fehlschlagen, und vermutest, dass die Antwort mit Waits zu tun hat, ohne es klar formulieren zu können. Interviewer wissen das, weshalb Waits die meisten Selenium-Runden eröffnen. Dieser Abschnitt zeigt, wie eine vollständige Antwort klingt.

• Impliziter versus expliziter Wait. Ein impliziter Wait ist eine globale Einstellung, die bei jeder Suche auf das Vorhandensein eines Elements pollt. Ein expliziter Wait zielt auf ein einziges Element und eine einzige Bedingung, etwa klickbar oder sichtbar. Explizit wird bevorzugt, weil klar wird, worauf genau gewartet wird.
• Warum sollte man sie nicht mischen? Kombiniert man beide, können sich Timeouts auf schwer vorhersehbare Weise summieren, weshalb die meisten Teams den impliziten Wait auf null setzen und durchgängig explizite Waits nutzen.
• Was ist ein Fluent Wait? Ein expliziter Wait mit konfigurierbarem Polling-Intervall und ignorierten Exception-Typen.
• Warum ist Thread.sleep falsch? Es ist bedingungslos. Es verlangsamt einen eigentlich bestehenden Test und lässt einen langsamen Test trotzdem fehlschlagen.
• CSS-Selektor oder XPath? Bevorzuge ein stabiles, testspezifisches Identifikationsattribut, dann CSS wegen der Lesbarkeit. XPath verdient seinen Platz, wenn du zu einem Elternelement navigieren oder nach Text matchen musst.
• Was macht einen Locator brüchig? Automatisch generierte Klassennamen, absolute XPath-Pfade und indexbasierte Auswahl. Sag, was du stattdessen von einem Entwickler ergänzt haben möchtest.

Interviewer hören auf den Grund hinter jeder Wahl. Eine Präferenz zu nennen, ohne die Kosten zu erwähnen, klingt wie eine auswendig gelernte Antwort.

Flaky Tests sind das eigentliche Thema der meisten Senior-Automatisierungsinterviews, denn eine Suite, der niemand vertraut, ist schlimmer als keine Suite.

• Was verursacht eine StaleElementReferenceException? Die Elementreferenz zeigt auf einen Knoten, der nicht mehr angehängt ist, meist weil das Framework diesen Teil der Seite neu gerendert hat. Suche das Element neu, statt die gespeicherte Referenz wiederzuverwenden.
• Und die ElementNotInteractableException? Das Element existiert, kann aber nicht bedient werden: versteckt, deaktiviert, von einem Overlay verdeckt oder außerhalb des Bildschirms.
• Wie gehst du mit NoSuchElementException um? Unterscheide ein Timing-Problem von einem tatsächlich fehlenden Element und kaschiere es nicht mit einem längeren Sleep.
• Warum schlagen Tests nur in der Pipeline fehl? Andere Viewport-Größe, langsamere Umgebung, fehlende Testdaten, später abgeschlossene Animationen und parallele Tests, die um gemeinsamen Zustand konkurrieren.
• Wie behebst du einen flaky Test? Diagnostiziere zuerst die Kategorie, behebe dann die Ursache. Auto-Retry versteckt Fehlschläge und ist ein letztes Mittel, das du auch so benennen solltest.
• Wie gehst du mit Frames, neuen Fenstern und Alerts um? Den Kontext explizit wechseln und danach wieder zurückwechseln.

Ein QA-Engineer, der sich auf eine Automatisierungsstelle im mittleren Level bewarb, wurde gefragt, warum eine Suite zweimal pro Woche ohne Codeänderung fehlschlug. Die überzeugende Antwort war kein Selenium-API-Detail, sondern dass die Tests ein einziges vorbereitetes Konto teilten und sich gegenseitig ausbremsten. Interviewer honorieren genau diese Diagnosereihenfolge: zuerst Umgebung und Daten, dann die API.

Weitere Fragenpools nach Rolle und Tool findest du unter Interviewfragen nach Rolle.

Über die API hinaus wollen Panels wissen, ob du eine Suite eigenverantwortlich betreuen kannst. Diese Fragen zählen bei Senior-Rollen am meisten.

• Erkläre das Page Object Model. Page-Klassen legen Aktionen offen und verstecken Locators, sodass eine UI-Änderung nur eine Datei betrifft. Sag, welches Problem es löst; nur die Ordnerstruktur zu beschreiben, verfehlt den Punkt.
• Was geht bei Page Objects schief? Sie wachsen zu tausendzeiligen Klassen heran und beginnen, innerhalb von Page-Methoden zu assertieren. Assertions gehören in Tests.
• Wie führt dein Framework Tests parallel aus? Thread-sicheres Driver-Management, sodass Instanzen nicht über Threads hinweg geteilt werden, plus unabhängige Testdaten pro Test.
• Wofür ist Selenium Grid da? Um Tests auf mehrere Maschinen und Browserversionen zu verteilen, mit einem Hub und Nodes, oder ein Cloud-Anbieter übernimmt dieselbe Rolle.
• Was hat sich in Selenium 4 geändert? Das W3C-WebDriver-Protokoll wurde zum Standard und das alte JSON wire protocol wurde entfernt, relative Locators kamen hinzu, und der Zugriff auf das Chrome DevTools Protocol wurde freigelegt.
• Wann solltest du Selenium nicht verwenden? API-Level-Prüfungen, unit-testbare Logik und alles außerhalb des Browsers. Diese Grenze zu kennen, ist ein Senior-Signal.
• Wie entscheidest du, was automatisiert wird? Stabile, wertvolle, wiederkehrende Pfade. Nicht alles, und keinen Screen, der noch neu gestaltet wird.

Antworten zu Selenium sind ungewöhnlich leicht zu wissen und schwer auszusprechen. Besonders die Wait-Frage hat eine zweiteilige Antwort, Definition und Grund, und Kandidaten, die das nur gelesen haben, liefern die erste Hälfte und verlieren dann den Faden.

Nimm die fünf Fragen hier, denen du am wenigsten begegnen willst, und beantworte jede laut in neunzig Sekunden ohne geöffneten Editor. Lass dann jemanden nachfragen, fast immer warum. Dieselben Prompts gegen einen KI-Interviewer zu üben, der nachhakt, kommt einer echten Runde näher als eine Liste erneut zu lesen, und genau dafür existiert der Mock-Interview-Modus.

Aaron Cao, Gründer von SubcueAI, hat die Übung um diese Sprechlücke herum aufgebaut statt um mehr Fragen. In einem Live-Interview können die Desktop-App und das Side Panel der Browser-Erweiterung Struktur anzeigen, während der Interviewer spricht, was am meisten bei bereits geübtem Material hilft. Was das Produkt tut und welche Grenzen es nicht überschreitet, steht auf der Security-Seite.