Interviews im Qualitätssicherungsbereich haben eine eigenartige Falle: In der Rolle geht es darum zu finden, was kaputtgeht, und trotzdem machen Kandidaten regelmäßig ihre eigenen Chancen kaputt, indem sie antworten, als hieße QA immer noch, sich durch eine Oberfläche zu klicken und Bugs zu melden. 2026 wird von einem QA Engineer erwartet, dass er über Teststrategie nachdenkt, wartbare Automatisierung schreibt und mit Verstand darüber argumentiert, was nicht getestet wird. Dieser Guide geht die Fragen durch, die dir wirklich gestellt werden, warum Interviewer sie stellen, und wie du antwortest wie jemand, der Qualität im großen Maßstab geliefert und nicht ein Glossar auswendig gelernt hat.
Was QA-Interviews 2026 wirklich prüfen
Die Latte hat sich verschoben. Reine manuelle Testrollen gibt es weiterhin, aber die meisten Anzeigen mit "QA Engineer" erwarten inzwischen zumindest ein Grundverständnis von Automatisierung, und SDET-Rollen erwarten, dass du Testcode auf Produktionsniveau schreibst. Interviewer klopfen dabei vier Dinge gleichzeitig ab.
Erstens Risikoeinschätzung: Kannst du ein Feature anschauen und sofort sehen, wo es wahrscheinlich bricht und wo Testaufwand verschwendet ist? Zweitens Automatisierungshandwerk: Kannst du Tests schreiben, die stabil und lesbar sind und nicht verrotten, sobald sich ein Button verschiebt? Drittens Systemdenken: Verstehst du, wie deine Tests in CI/CD passen, wo sie laufen und was eine rote Pipeline das Team kostet? Viertens Kommunikation: Ein hervorragender Bug-Report, auf den niemand reagiert, ist ein Fehlschlag, also wollen sie sehen, wie du eskalierst, priorisierst und widersprichst, ohne schroff zu werden.
Was sie still aussortieren, ist die Haltung "Tester als Türsteher". Moderne Teams wollen QA in der Lieferung verankert, früh für Qualität eintretend, nicht am Ende der Kette stehend und Releases abstempelnd. Wenn deine Antworten QA als die Abteilung rahmen, die Nein sagt, hast du es schwer gegen Kandidaten, die sie als die Funktion rahmen, die das Team schnell und sicher liefern lässt.
Der Interviewprozess
Bei den meisten QA- und SDET-Stellen kannst du 2026 mit vier bis fünf Stufen rechnen. Wer die Form kennt, kann die Tiefe jeder Antwort kalibrieren.
- Recruiter-Screening (20 bis 30 Minuten). Organisatorisches, Gehaltsrahmen und ein kurzer Check, dass du manuelles von automatisiertem Testen unterscheiden kannst. Bleib auf Flughöhe.
- Gespräch mit der einstellenden Führungskraft (45 Minuten). Viel Verhalten und Strategie. Rechne mit "wie würdest du X testen"-Szenarien und Fragen dazu, wie du mit Entwicklern arbeitest. Diese Runde entscheidet, ob du wie ein Quality Engineer denkst oder nur wie jemand, der Tests ausführt.
- Technische oder Coding-Runde (60 bis 90 Minuten). Bei SDET-Rollen ist das eine Live-Coding-Aufgabe: eine Funktion und ihre Tests schreiben, oder einen kleinen Web-Flow mit Selenium, Playwright oder Cypress automatisieren. Bei eher manuell ausgerichteten QA-Rollen ist es oft eine Testdesign-Aufgabe (Testfälle für ein Login-Formular, einen Aufzug, einen Getränkeautomaten) plus ein paar SQL- oder API-Fragen.
- System- oder Teststrategie-Runde. Du bekommst vielleicht eine Feature-Spezifikation oder ein einfaches Architekturdiagramm und sollst einen Testplan bauen: was du automatisierst, was manuell bleibt, was du auf API- statt auf UI-Ebene prüfst, und wie das in die Pipeline passt.
- Bar Raiser oder teamübergreifende Runde. Kultur, Zusammenarbeit, und wie du mit einem Konflikt über einen "Won't fix"-Bug oder eine verpasste Regression umgehst.
Aufgaben für zu Hause sind ebenfalls verbreitet, meist ein kleines Automatisierungs-Framework. Bewertet werden sie genauso auf Struktur und Lesbarkeit wie darauf, ob die Tests durchlaufen.
Die Fragen
Testgrundlagen und Strategie
Führ mich durch, wie du eine Login-Seite testen würdest. Der klassische Einstieg, und ein Filter. Zähl nicht einfach "richtiges und falsches Passwort" auf. Zeig Struktur: funktionale Fälle (gültiger Login, falsches Passwort, leere Felder, Kontosperre nach N Versuchen), dann Grenzwerte und Eingabevalidierung (maximale Länge, SQL-Injection-Strings, Unicode, führende Leerzeichen), dann nicht-funktionale Aspekte (Antwortzeit, Brute-Force-Schutz, Passwortmaskierung), dann Querschnittsthemen (Session-Ablauf, "Angemeldet bleiben", Zurück-Button nach dem Logout, parallele Sessions). Schließ damit ab, was deine Prioritäten sind und was du automatisierst statt einmal manuell zu prüfen. Die Struktur ist die Antwort.
Was ist der Unterschied zwischen Severity und Priority? Nenn ein Beispiel, wo sie auseinandergehen. Severity ist die technische Auswirkung, Priority die geschäftliche Dringlichkeit. Der Punkt der Frage ist genau das Auseinandergehen. Ein Tippfehler im Firmennamen auf der Startseite hat niedrige Severity (nichts ist kaputt), aber hohe Priority (es ist peinlich und öffentlich). Ein Crash tief in einem Admin-Feature, das zweimal im Jahr benutzt wird, hat hohe Severity und niedrige Priority. Nenn ein konkretes Beispiel aus deiner eigenen Arbeit, um zu zeigen, dass du das erlebt hast.
Wie entscheidest du, was automatisiert wird und was manuell bleibt? Rahme es als Rendite, nicht als Dogma. Automatisier die stabilen, sich wiederholenden, wertvollen Pfade: Regressionssuiten, Smoke-Tests, datengetriebene Prüfungen, alles, was bei jedem Build läuft. Manuell bleiben exploratives Testen, einmalige UX-Urteile und Features, die wöchentlich noch umgebaut werden (ein bewegliches Ziel zu automatisieren verbrennt Zeit). Erwähne, dass brandneue Features oft zuerst manuelle Abdeckung bekommen und Automatisierung erst, wenn sich das Design gesetzt hat.
Erklär die Testpyramide und wo du sie umgedreht erlebt hast. Viele Unit-Tests, weniger Integrationstests, sehr wenige End-to-End-UI-Tests, weil UI-Tests langsam und brüchig sind. Der interessante Teil ist die umgedrehte Version: die Eistüte, bei der ein Team sich auf schwere End-to-End-Suiten und dünne Unit-Abdeckung stützt. Beschreib den Schmerz, den das verursacht (langsame Pipelines, flaky Fehlschläge, stundenlange Triage), und wie du sie neu ausbalancieren würdest, indem du Abdeckung auf schnellere Ebenen nach unten drückst.
Was ist der Unterschied zwischen Smoke-, Sanity- und Regressionstests? Smoke ist eine flache, breite Prüfung nach dem Motto "lebt der Build überhaupt", die zuerst läuft. Sanity ist eine schmale, tiefe Prüfung, dass ein bestimmter Fix oder ein Feature funktioniert. Regression ist das weite Netz, das bestätigt, dass bestehende Funktionalität nach einer Änderung noch läuft. Interviewer fragen das, um Vokabularpräzision zu prüfen, also sei knackig und gib je ein Einzeiler-Beispiel.
Automatisierung und Coding
Schreib einen Test für eine Funktion, die E-Mail-Adressen validiert. Sie schauen auf dein Testdesign, nicht auf deine Regex. Deck die Äquivalenzklassen ab: gültige Adressen, fehlendes @, fehlende Domain, doppelte Punkte, führende oder abschließende Leerzeichen, sehr lange Eingaben und der leere String. Sprich positive und negative Fälle laut durch, erwähne, dass du die Eingaben parametrisierst statt Assertions zu kopieren, und benenne deine Testfälle beschreibend. Saubere, gut benannte Tests signalisieren Seniorität schneller als cleverer Code.
Wie gehst du mit einem flaky Test um? Sag nicht "Retry dranhängen und weiter". Das ist der falsche Reflex, und Interviewer wissen das. Fang bei der Ursache an: Ist es ein Timing-Problem (mit sauberen expliziten Waits lösen, niemals mit festen Sleeps), Abhängigkeit zwischen Tests (Tests teilen sich State), instabile Umgebung oder echter Nichtdeterminismus in der Anwendung? Erklär, dass du den flaky Test in Quarantäne stellst, damit er die Pipeline nicht mehr blockiert, untersuchst, die Ursache behebst und ihn dann in die Suite zurückholst. Retries verdecken Flakiness, sie heilen sie nicht, und eine Suite, der niemand vertraut, ist schlimmer als gar keine Suite.
Explizite Waits, implizite Waits oder harte Sleeps. Was nutzt du und warum? Ein Liebling bei Selenium- und Playwright-Rollen. Harte Sleeps (eine feste Pause) sind ein Antipattern: zu kurz und du bekommst Flakiness, zu lang und deine Suite kriecht. Implizite Waits setzen ein globales Polling-Timeout, vertragen sich aber schlecht mit expliziten Waits und können Probleme verdecken. Explizite Waits (warten auf genau diese Bedingung, etwa dass ein Element klickbar ist) sind der richtige Standard. Moderne Frameworks wie Playwright warten bei den meisten Aktionen automatisch, und das ist erwähnenswert als die Richtung, in die sich das Tooling bewegt hat.
Wie würdest du ein UI-Automatisierungs-Framework von Grund auf entwerfen? Zeig Architekturdenken. Deck das Page Object Model (oder das Screenplay-Pattern) ab, um Testlogik von Locators zu trennen, eine Konfigurationsschicht für Umgebungen, zentrales Reporting, Datenverwaltung, damit Tests unabhängig sind und parallel laufen können, und die Einbindung in CI. Betone Wartbarkeit: Locators an einer Stelle, keine hartkodierten Testdaten, kein Test, der von den Nebeneffekten eines anderen abhängt. Erwähne, dass du die End-to-End-Ebene dünn hältst und Logikprüfungen zu API- oder Unit-Tests schiebst.
Die UI-Tests sind in CI langsam und flaky. Wie reparierst du die Suite? Ein Dauerbrenner 2026, weil das jeder erlebt hat. Sprich darüber, Abdeckung die Pyramide runterzuschieben (UI-Prüfungen wo möglich durch API-Tests ersetzen), parallel laufen zu lassen, über Maschinen zu sharden, Locators zu stabilisieren (Test-IDs statt brüchigem CSS oder XPath), harte Sleeps zu entfernen und Testdaten zu isolieren. Nimm Observability dazu: Screenshots, Videos und Traces bei Fehlschlägen aufzeichnen, damit die Triage Minuten dauert und nicht Stunden.
API, Daten und Systeme
Wie testest du eine REST-API? Geh über "Request schicken, Statuscode prüfen" hinaus. Deck ab: Statuscodes und Validierung des Response-Schemas, den kompletten CRUD-Lebenszyklus, Authentifizierung und Autorisierung (kann ein Nutzer auf die Daten eines anderen zugreifen?), Eingabevalidierung und Fehlerbehandlung, Idempotenz, Pagination, Rate Limiting und Rückwärtskompatibilität, wenn sich der Contract ändert. Nenn Tools (Postman zum Erkunden, dann Tests auf Codeebene mit REST Assured, requests oder Playwrights API-Testing) und Contract Testing, falls du das genutzt hast.
Du hast eine users-Tabelle und eine orders-Tabelle. Schreib eine Query, die Nutzer findet, die nie bestellt haben. Grundlegendes SQL ist für QA 2026 nicht verhandelbar, weil du ständig Datenzustände verifizierst. Ein LEFT JOIN mit WHERE orders.id IS NULL, oder eine NOT EXISTS-Subquery. Sei bereit zu erklären, warum du NOT IN nicht nimmst, wenn die Spalte NULLs enthalten kann, denn genau auf diese Stolperfalle hören sie.
Ein Nutzer meldet einen Bug, den du nicht reproduzieren kannst. Führ mich durch, was du tust. Methodisches Vorgehen gewinnt hier. Sammle Details (exakte Schritte, Browser, Betriebssystem, App-Version, Zeitstempel, Konto), prüf Logs und Monitoring rund um diesen Zeitstempel, reproduzier die exakte Umgebung und den Datenzustand des Nutzers, und überleg, ob es umgebungsspezifisch, datenspezifisch oder eine Race Condition ist. Erklär, dass "nicht reproduzierbar" ein Startpunkt ist und kein Urteil, und dass du das nie ohne Beleg schließen würdest, dass es behoben ist oder wirklich nicht auftritt.
Wie testest du etwas ohne Dokumentation und ohne Anforderungen? Das trennt Tester von Quality Engineers. Exploratives Testen mit einer klaren Charter, Verhalten mit vergleichbaren Produkten abgleichen, mit Entwickler und Product Owner sprechen, um die Absicht zu rekonstruieren, und die De-facto-Spezifikation unterwegs dokumentieren. Rahme Unklarheit als Qualitätsrisiko, das du sichtbar machst, nicht als Blocker, der dich stoppt.
Verhalten und Zusammenarbeit
Ein Entwickler markiert deinen Bug als "Won't fix", aber du glaubst, dass damit ein echtes Problem ausgeliefert wird. Was tust du? Getestet wird, ob du für Qualität eintrittst, ohne zum Blocker zu werden. Verankere es neu in Auswirkung und Daten: quantifizier den Effekt auf Nutzer, häng Belege an, rahme es als Risiko, über das der Product Owner entscheidet, statt als Machtkampf QA gegen Entwicklung. Zeig, dass du widersprechen, angemessen eskalieren und dann eine dokumentierte Geschäftsentscheidung souverän akzeptieren kannst. Die schlechteste Antwort ist "Ich gebe die Freigabe nicht". Die zweitschlechteste ist "Ich lasse es einfach laufen".
Erzähl mir von einem Bug, der in die Produktion durchgerutscht ist. Was ist passiert und was hast du danach geändert? Nimm einen echten. Sei ehrlich über die Lücke (ein fehlender Testfall, ein Umgebungsunterschied, eine Annahme) und konzentrier dich dann stark auf den systemischen Fix: den Regressionstest, den du ergänzt hast, die Prozessänderung, das Monitoring, das du eingerichtet hast, damit so etwas beim nächsten Mal schneller auffällt. Zum Versäumnis zu stehen und die Präventionsschleife zu zeigen ist der ganze Punkt.
Typische Fehler, an denen QA-Kandidaten scheitern
- Testfälle ohne Struktur oder Priorisierung auflisten. Fälle zusammenspinnen kann jeder. Senior-Kandidaten gruppieren sie (funktional, Grenzwerte, negativ, nicht-funktional) und sagen, was sie zuerst testen würden und warum.
- Automatisierung als Selbstzweck behandeln. Alles zu automatisieren ist ein Warnsignal. Das Ziel ist Risikoabdeckung zu den richtigen Kosten. Kandidaten, die nicht artikulieren können, was sie nicht automatisieren würden, wirken junior.
- Flakiness mit Retries verteidigen. Zu einer Retry-Schleife zu greifen statt zur Ursachensuche ist 2026 ein sofortiges Warnsignal.
- Die Türsteher-Haltung. QA als das Team zu rahmen, das Releases blockiert, statt als die Funktion, die sichere, schnelle Lieferung ermöglicht, macht dich alt.
- Schwache Bug-Reports im Gespräch. Wenn sie nach einem Defekt fragen, sagen vage Kandidaten "es geht nicht". Starke liefern ungefragt Schritte zur Reproduktion, Erwartung gegen Realität, Umgebung und Severity.
- Keine Routine in SQL oder APIs. "Ich mache nur manuelles UI-Testing" schließt Türen. Selbst eher manuelle Rollen erwarten heute, dass du Daten verifizierst und einen Endpoint anpiekst.
Wie du dich vorbereitest (und wo ein Live-Copilot hilft)
Fang damit an, die Szenariofragen laut zu üben, nicht im Kopf. "Wie würdest du [einen Kaffeeautomaten, einen Geldautomaten, einen Datei-Upload, eine Suchleiste] testen" sollte zum Reflex werden, bei dem du funktionale, Grenzwert-, negative und nicht-funktionale Fälle in geordneter Reihenfolge runterrasselst. Bau oder frisch ein kleines Automatisierungsprojekt in Playwright oder Cypress auf, damit du über die Struktur eines echten Frameworks sprechen kannst, und üb dann die SQL-Joins und ein paar API-Tests mit REST Assured oder requests. Halt zwei oder drei Geschichten im STAR-Format bereit: ein durchgerutschter Bug, ein Konflikt über einen Defekt, und eine Situation, in der du eine langsame oder flaky Suite verbessert hast. Lies die Stellenbeschreibung noch einmal und spiegle ihren Stack, ein Selenium-Laden und ein Playwright-Laden wollen unterschiedliche Details hören.
In den technischen Live-Runden trifft Vorbereitung auf Druck, und genau da verdient sich ein Echtzeit-Copilot sein Geld. GhostPilot ist ein KI-Interview-Assistent, der der Unterhaltung zuhört und dir strukturierte Impulse einblendet, während du sprichst: das Testdesign-Framework, das dir unter Druck entfallen ist, der genaue Unterschied zwischen Severity und Priority, eine saubere Formulierung für deinen Ursachenprozess bei flaky Tests. Es ist ein Coach, der dir das Gerüst zuwirft, kein Autopilot, der dir Antworten vorliest, Vortrag und gelebte Erfahrung müssen weiterhin von dir kommen.
Es läuft im Chrome Side Panel, wenn du also während eines Remote-Gesprächs einen einzelnen Browser-Tab teilst, ist es nicht Teil dessen, was aufgezeichnet wird. Es gibt außerdem eine optionale Windows-Desktop-App, die unter Windows 10 (Build 2004 oder neuer) und Windows 11 für Bildschirmaufnahmen unsichtbar ist, falls du den ganzen Bildschirm abdecken musst. Mehr dazu und die Installation auf ghostpilotai.com. Richtig eingesetzt nimmt es dir das Risiko, beim Offensichtlichen einen Blackout zu haben, damit du dich darauf konzentrieren kannst, wie der Engineer zu klingen, der du tatsächlich bist.
FAQ
Was sind 2026 die häufigsten QA-Engineer-Interviewfragen? Immer wieder kommen "wie würdest du [ein Feature] testen", Severity gegen Priority, die Testpyramide, der Umgang mit flaky Tests, was du automatisierst und was manuell bleibt, und eine grundlegende SQL- oder API-Frage. Szenariofragen nach dem Muster "wie würdest du X testen" dominieren, weil sie zeigen, wie du über Risiko denkst, nicht nur welche Begriffe du kennst.
Müssen QA Engineers 2026 programmieren können? Zunehmend ja. Rein manuelle Rollen gibt es weiterhin, aber die meisten "QA Engineer"-Anzeigen erwarten Automatisierungskompetenz, und SDET-Rollen erwarten Testcode auf Produktionsniveau in JavaScript, Python oder Java. Selbst eher manuelle Rollen verlangen heute SQL und einfaches API-Testing. Etwas Programmierfähigkeit erweitert deine Optionen erheblich.
Wie unterscheidet sich ein SDET-Interview von einem manuellen QA-Interview? SDET-Interviews setzen stark auf Live-Coding: eine Funktion und ihre Tests schreiben, ein kleines Automatisierungs-Framework bauen oder eine Datenstruktur-Aufgabe lösen. Manuelle QA-Interviews gewichten Testdesign-Aufgaben, exploratives Testen und Prozessfragen stärker. Beide prüfen Risikoeinschätzung, aber die Latte für Code-Qualität liegt bei SDET deutlich höher.
Was gehört in eine QA-Automatisierungsaufgabe für zu Hause? Behandle sie wie Produktionscode. Klare Struktur (Page Object Model oder Äquivalent), unabhängige Tests, die parallel laufen können, keine hartkodierten Daten, eine lesbare README, die erklärt, wie man es startet und was du warum getestet hast. Reviewer bewerten Design und Klarheit genauso wie das Durchlaufen der Tests, eine kleinere, saubere Abgabe schlägt also eine ausufernde, chaotische.
Wie beantworte ich "wie würdest du das testen", ohne zu labern? Nutz jedes Mal dieselbe mentale Vorlage: zuerst funktionale Fälle, dann Grenzwerte und Eingabevalidierung, dann negative und Fehlerfälle, dann nicht-funktionale Aspekte (Performance, Sicherheit, Bedienbarkeit), dann Querschnittsthemen. Schließ mit deinen Prioritäten ab und damit, was du automatisieren würdest. Die Struktur hält dich vom Labern ab und signalisiert Seniorität.
GhostPilot AI testen
QA-Interviews belohnen strukturiertes Denken unter Druck, und genau dann setzt das Gedächtnis aus. GhostPilot gibt dir Impulse in Echtzeit, passend zur Rolle, damit das Testdesign-Framework, die Unterscheidung zwischen Severity und Priority oder die saubere Erklärung eines Flaky-Test-Fixes da ist, wenn du sie brauchst. Kostenloser Tarif: Live-Sessions von 10 Minuten mit unbegrenzten KI-Antworten. Session Pass: $29 für drei komplette Interviews à zwei Stunden (einmalig, kein Abo). Pro: $59/Monat oder $192/Jahr ($16/Monat bei jährlicher Abrechnung).