Was wird in QA-Engineer-Interviews wirklich geprüft?

Wer im Raum sitzt und worauf geachtet wird

Bei einer QA-Engineer-Position leitet meist der QA-Lead oder Test-Manager das Interview, manchmal sitzt ein Entwickler oder der Engineering-Manager in mindestens einer Runde dabei. Hat das Unternehmen ein eigenes Automatisierungs-Team, kommt eventuell eine separate Runde mit einem Senior-SDET hinzu, dessen einzige Aufgabe ist zu prüfen, ob Ihr Code etwas taugt, nicht nur Ihre Test-Instinkte. Kleinere Firmen verzichten manchmal ganz auf QA-Spezialisten und lassen einen Entwickler das Interview führen, was die Fragen verändert: erwarten Sie mehr Fokus auf Code und weniger auf Test-Strategie oder Fehlermanagement.

Was geprüft wird, unter der Oberfläche des Small Talks: können Sie Probleme finden, die einem Entwickler entgehen, können Sie einen Bug so präzise erklären, dass ihn jemand anderes ohne Rückfrage reproduzieren kann, und verstehen Sie, warum ein Test existiert, nicht nur wie man ihn ausführt. Nichts davon zeigt sich, wenn Sie nur Definitionen von Test-Begriffen auswendig lernen.

Die praktische Übung: wie sie tatsächlich aussieht

Die meisten QA-Interviews bei mittelgroßen und größeren Unternehmen enthalten eine praktische Aufgabe, nicht nur Gespräche. Die gängigen Formate:

• Live-Exploratory-Testing. Sie bekommen eine kleine Web-App, einen Staging-Build oder manchmal nur eine öffentliche Website und sollen in fünfzehn bis zwanzig Minuten Bugs finden, während Sie Ihr Denken laut kommentieren. Was beobachtet wird: Ihre Methode. Beginnen Sie beim offensichtlichen Happy Path und hören dort auf, oder gehen Sie zu Grenzwerten, unerwartetem Input, Session-Handling, Browser-Zurück-Verhalten und gleichzeitigen Aktionen über?
• Test-Case-Design auf Papier oder in einem gemeinsamen Dokument. Sie erhalten eine Feature-Beschreibung, manchmal so vage wie ein einzelner Satz wie "ein Nutzer kann sein Passwort zurücksetzen", und sollen Testfälle schreiben. Dies prüft, ob Sie an Negativfälle, abgelaufene Tokens, Rate-Limiting und Kontostände denken, nicht nur ob Sie ein Spreadsheet formatieren können.
• Eine Bug-Report-Übung. Ihnen wird ein Defekt gezeigt und Sie sollen ihn dokumentieren, oder Sie bekommen einen schlecht geschriebenen Bug-Report und sollen ihn kritisieren. Gesucht werden: Reproduktionsschritte, Umgebungsdetails, erwartetes versus tatsächliches Ergebnis und eine vernünftige Trennung von Schweregrad und Priorität — kein Prosa-Absatz.
• Eine Automatisierungs-Coding-Aufgabe. Für SDET-lastige Rollen werden Sie gebeten, einen Test mit Selenium, Playwright oder Cypress zu schreiben oder zu erweitern, manchmal gegen eine echte Test-App, die sie bereitstellen. Interviewer interessiert die Selektor-Strategie (greifen Sie zu einem fragilen XPath oder einem stabilen data-test-Attribut), Wartezeiten (explizit versus willkürliche Sleep-Calls) und ob Ihr Test eine kleine UI-Änderung überleben würde.
• Eine SQL- oder API-Übung. Berührt die Rolle Backend-Testing, erwarten Sie eine Query-Aufgabe — Validierung der Datenintegrität nach einer Migration oder Prüfung eines Joins auf Duplikate — oder ein Request in Postman gegen eine dokumentierte API, Prüfung von Status-Codes, Response-Schema und Error-Handling.

Take-Home-Assignments sind für QA-Rollen üblich, weil die Arbeit selbst asynchron und schriftlich ist — ein Unternehmen kann viel daraus lernen, wie Sie einen Testplan oder Bug-Report ohne Zeitdruck strukturieren, was schwerer zu fälschen ist als ein Live-Gespräch.

Fragen, die wie Small Talk klingen, es aber nicht sind

Manche Fragen wirken wie Aufwärmgespräch, leisten aber echte Diagnosearbeit.

"Beschreiben Sie einen Bug, den Sie gefunden haben, den niemand sonst entdeckt hat." Hier wird nicht nach einer Anekdote gefragt. Geprüft wird, ob Sie verstehen, warum der Bug übersehen wurde — war es ein Edge Case bei Datumsbehandlung über Zeitzonen hinweg, eine Race Condition unter Last, eine Regression durch ein Dependency-Update — und ob Sie die Überlegung beschreiben können, die Sie dorthin geführt hat, nicht nur das Ergebnis.

"Wie würden Sie ein Login-Formular testen?" Jeder kann Username, Passwort, Submit aufzählen. Die Antwort, die Kompetenz zeigt, umfasst Konto-Sperrung nach wiederholten Fehlversuchen, Session-Ablauf, Passwortfeld-Maskierung, Autofill-Verhalten, SSO-Redirect-Handling falls zutreffend und was passiert, wenn das Backend langsam ist oder ausfällt. Sie priorisiert auch: welche davon würden Sie zuerst testen, wenn Sie eine Stunde hätten, und warum.

"Was ist der Unterschied zwischen einem Smoke-Test und einer Regression-Suite, und wann führen Sie diese aus?" Die Definitionen stehen in jedem Lehrbuch. Was eine echte Antwort unterscheidet, ist ihre Einordnung in eine Pipeline: Smoke-Tests laufen bei jedem Build, um ein kaputtes Deployment schnell zu erkennen, Regression-Suites laufen vor einem Release oder nach Zeitplan, weil sie langsamer und teurer sind, und ein reifes Team taggt Tests, damit CI je nach Änderung die passende Teilmenge ausführen kann.

"Erzählen Sie von einem Fall, wo Sie mit einem Entwickler nicht einig waren, ob etwas ein Bug ist." Hier werden Urteilsvermögen und Kommunikation bei Uneinigkeit getestet, nicht Konfliktvermeidung. Eine gute Antwort nennt das tatsächliche Kriterium zur Lösung — die Spezifikation, die Akzeptanzkriterien, eine Produktentscheidung — nicht nur "wir haben es besprochen".

"Wie entscheiden Sie, was Sie nicht testen?" Dies ist eine der aufschlussreichsten Fragen im gesamten Interview, weil nicht testbarer Umfang und risikobasierte Priorisierung Dinge sind, über die ein oberflächlicher Kandidat nie nachdenken musste. Wer unter Deadline ausgeliefert hat, spricht über Risiko, Nutzungshäufigkeit und Auswirkungsradius. Wer nicht, sagt "ich versuche alles zu testen".

Wie eine oberflächliche Antwort klingt

Ein erfahrener Interviewer erkennt innerhalb von ein, zwei Minuten, wann ein Kandidat rezitiert statt zu denken. Die Anzeichen sind spezifisch:

• Begriffe definieren — Smoke-Testing, Sanity-Testing, Regression, Exploratory-Testing — korrekt, aber nie mit einer Pipeline, einer Release-Kadenz oder einer echten Entscheidung verbinden, wann welche läuft.
• Sagen "ich teste Edge Cases und Grenzwerte", ohne einen einzigen Edge Case für das tatsächlich vorliegende Feature zu nennen.
• Automatisierungs-Erfahrung nur in genutzten Tools beschreiben ("ich habe Selenium und Cypress verwendet"), ohne zu erwähnen, was eine Suite flaky machte, wie sie einen fehlgeschlagenen Test in CI debuggt haben oder wie sie entschieden, was zu automatisieren versus manuell zu belassen ist.
• Einen Bug-Report in der Übung schreiben, der eine Beschreibung hat, aber keine Reproduktionsschritte, keine Umgebung und keinen klaren Schweregrad — genau die Art von Report, die von einem Entwickler in echten Teams zurückgewiesen wird.
• Auf "wie würden Sie X testen" nur mit dem Happy Path antworten, oder mit einer erschöpfenden Liste, die kein Prioritätsgefühl zeigt, wenn gefragt wird, was sie mit begrenzter Zeit täten.
• Vertrautheit mit einem spezifischen Tool — TestRail, Zephyr, BrowserStack, JMeter — behaupten, aber nicht eine konkrete Sache beschreiben können, die sie darin getan haben, außer "Testergebnisse protokolliert".

Nichts davon ist allein disqualifizierend. Jeder hat Lücken. Das Problem ist, wenn jede Antwort dieselbe Form hat: korrektes Vokabular, kein Beweis dafür, die Entscheidungen tatsächlich getroffen zu haben, die dieses Vokabular beschreibt.

Was vor dem Interview zu tun ist

Wählen Sie zwei oder drei Bugs aus Ihrer eigenen Arbeit, die Sie in unter neunzig Sekunden beschreiben können: was das Symptom war, wie Sie die Ursache isoliert haben und warum es wichtig war. Haben Sie ein Beispiel bereit, wo Sie mit einem Entwickler oder Product Owner über den Schweregrad nicht einig waren und wie es gelöst wurde. Listet die Rolle ein spezifisches Automatisierungs-Framework auf, schreiben Sie vorher einen kleinen Test darin, statt nur darüber zu lesen — Interviewer fragen nach Locator-Strategie und Waits, weil dies die Dinge sind, die jemanden unterscheiden, der eine Suite ausgeführt hat, von jemandem, der eine kopiert hat. Ist ein Take-Home oder eine Live-Übung wahrscheinlich, behandeln Sie das Bug-Report-Format so ernst wie den Bug selbst; ein sauberer, reproduzierbarer Report ist oft das, was das Interview tatsächlich bewertet.

Und lesen Sie die Stellenanzeige selbst vor dem Gespräch genau — die Tools, die Test-Typen und der Release-Prozess, die erwähnt werden (manuelle Regression, CI-gesteuert, nur explorativ), sagen Ihnen, welche der obigen Fragen am wichtigsten sein werden. jobmarket.pro liest diese Anzeige vollständig und erstellt aus Ihrer tatsächlichen Arbeitshistorie eine darauf abgestimmte Bewerbung, sodass die Passung, auf die es Sie hinweist, eine ist, die Sie unter der Art von Befragung oben verteidigen können.