QA Engineer Mock-Interview — üben mit AI

QA-Interviews teilen sich in zwei Tracks auf: manuelle/Teststrategie-Rollen und SDET-/Automatisierungs-Rollen, und sie wollen sehr unterschiedliche Signale. Manual QA will jemanden, der ein Feature in fünfzehn Minuten kaputt machen und einen klaren Bug-Report schreiben kann; SDET will jemanden, der wie ein Backend Engineer codet, aber wie ein Tester denkt. Die meisten Kandidaten verlieren, weil sie auf das falsche Ziel zielen. Dieser Leitfaden zeigt, wie Sie den QA-Engineer-Interview-Loop mit AI-Mocks proben, kalibriert auf Ihren Track.

Typische Interview-Runden für QA Engineers

Der QA-Loop umfasst bei den meisten Unternehmen 4 Runden. Ein Recruiter-Gespräch, ein Teststrategie-Interview (Sie bekommen ein Feature und werden gefragt, wie Sie es testen würden), eine Hands-on-Runde (Automatisierungscode schreiben oder eine Bug-Untersuchung durchgehen) und ein Behavioral. SDET-Rollen ergänzen ein Coding-Interview, das wie ein Junior- oder Mid-Level-Backend-Interview aussieht — DSA-light, plus Testing-spezifische Muster (Page Object Model, Fixtures, Parametrisierung). Senior-QA-Loops beinhalten eine Quality-Strategy-Runde: Wie würden Sie die Messlatte in einer Organisation ohne Test-Disziplin anheben?

Die Teststrategie-Runde und die Quality-Strategy-Runde sind die, in denen AI-Mocks am meisten helfen. Beide sind offen, beide belohnen strukturiertes Denken, beide bestrafen generische Antworten. Die Automatisierungs-Coding-Runde profitiert ebenfalls vom Mock — zu verbalisieren, warum Ihr Test an wackeligen Selektoren scheitert, kommt stärker an als nur den Code zu schreiben. Reines manuelles exploratives Testen ist schwerer zu mocken; dafür kombinieren Sie den AI-Mock mit gezielter Übung an echten Apps.

Wichtigste technische Themen

Teststrategie und Pyramiden

Die Testpyramide ist älter als die Hälfte der QA-Kandidaten, mit denen ich gesprochen habe, aber Interviewer erwarten weiterhin, dass Sie sie diskutieren. Seien Sie bereit: wann die Pyramide zerbricht (Microservices, Mobile, ML-getriebene Features), was sie ersetzt (Test-Diamant, Honeycomb), der Unterschied zwischen Testen für Confidence vs. für Coverage und was „dieser Code hat 90 % Coverage, aber keine Tests“ in der Praxis bedeutet. Starke Antworten trennen Confidence (beweist der Test, dass die Sache funktioniert) von Coverage (hat der Test die Zeile ausgeführt).

Automatisierungs-Frameworks

Playwright hat Selenium bei neuen Projekten überholt, aber Selenium-WebDriver betreibt weiterhin riesige Enterprise-Suites. Cypress hält die für Frontend-Entwickler freundliche Nische. Seien Sie bereit zu diskutieren: die tatsächlichen Unterschiede (Playwrights Auto-Wait, Cypress' iframe-Grenzen, Seleniums Grid-Modell), wann Sie welches wählen würden und wie man eine Suite migriert, ohne das Dev-Team zu brechen. Für API-Testing: REST Assured, Postman/Newman, pytest + requests, Karate. Für Mobile: Appium, XCUITest, Espresso, Maestro.

Testdesign und Daten

Boundary Value Analysis, Äquivalenzklassenbildung, Decision Tables, Pairwise Testing — Interviewer erwarten Sicherheit im Vokabular, auch wenn Sie die Tabelle nicht am Whiteboard zeichnen. Seien Sie bereit, über Testdaten-Strategie zu sprechen: synthetisch vs. aus Production geklont, Umgang mit PII, Fixture-Management im großen Maßstab, was ein „flaky Test“ tatsächlich bedeutet (Daten, Timing, Umgebung, Race Conditions) und wie Sie einen Test debuggen würden, der 1 von 50 Läufen scheitert.

API-Testing

API-Tests sind der Bereich, in dem die meisten Automatisierungs-Suites gewichten sollten — und in dem viele scheitern. Seien Sie bereit für: Contract Testing (Pact, Spring Cloud Contract), Schema-Validierung, Idempotenz-Tests, Retry-Verhalten, Authentifizierungspfade, Rate Limiting und den Unterschied zwischen dem Testen einer API und dem Testen eines Systems über eine API. Eine beliebte Frage: „Die API gibt 200 für einen ungültigen Request zurück — ist das ein Bug?“ Starke Antworten trennen API-Contract von Geschäftslogik.

CI/CD-Integration

Tests, die nicht bei jedem Commit laufen, zählen nicht. Seien Sie bereit: parallele Ausführung, Test-Sharding, was zu tun ist, wenn die Suite 90 Minuten dauert, Quarantäne flaky Tests, Testauswahl (nur relevante Tests für eine Änderung ausführen) und Reporting (JUnit XML, Allure, ReportPortal). Senior-QA-Loops erwarten, dass Sie die gesamte Pipeline vom Green-Commit zum Production-Deploy mit Quality Gates in jeder Stufe entwerfen.

Häufige Szenario-Fragen

• „Sie bekommen einen Login-Screen. Wie testen Sie ihn?“ (Happy Path, Fehlerzustände, Sicherheit, Accessibility, Performance, Internationalisierung, Edge Cases abdecken — strukturiert.)
• „Das Team hat 3 % flaky Tests und der Build ist die Hälfte der Zeit rot. Was tun Sie?“ (Kategorisieren, Quarantäne, Root Causes beheben, Monitoring hinzufügen.)
• „Entwerfen Sie eine Regressionstest-Strategie für einen Checkout-Flow, der mit 4 Drittanbieter-Diensten integriert.“ (Service-Virtualisierung, Contract Testing, echter Payment-Sandbox, Monitoring.)
• „Sie sollen ‚AI-generierte Tests' zur Suite hinzufügen. Was sagen Sie?“ (Tradeoffs, wo AI-generiert hilft, wo es Rauschen erzeugt.)
• „Das Team will QA überspringen und mit Feature Flags ausliefern. Widersprechen oder zustimmen?“ (Shift-Left, Monitoring, Rollback, Blast Radius, Kundenvertrauen.)

Behavioral-Schwerpunkte — worauf Hiring Manager achten

QA-Hiring-Manager screenen auf drei Eigenschaften. Erstens Advocacy ohne Schärfe — können Sie ein Release stoppen, ohne dass das Dev-Team Sie hasst? Starke Geschichten zeigen, wie Sie den Fall mit Daten dargelegt, die Empfehlung verantwortet und das Team entscheiden ließen. Zweitens explorative Denkweise — finden Sie Bugs, an die sonst niemand denkt? Achten Sie auf Prompts zu einem denkwürdigen Bug; antworten Sie mit der Spur der Neugier, die dazu führte, nicht nur mit dem Bug selbst. Drittens Komfort mit Ambiguität — QA bekommt oft eine halb geschriebene Spec und soll sie testen. Hiring Manager wollen jemanden, der klärt, dokumentiert und fortfährt, nicht jemanden, der auf perfekte Anforderungen wartet.

Wie Sie AI-Mock-Übungen für diese Rolle nutzen

Stellen Sie den Interview-Typ auf „Tech Screening“ und wählen Sie Ihren Track — manuell/Strategie oder SDET/Automatisierung. Die AI kalibriert die Fragen entsprechend. Fügen Sie die Stellenbeschreibung ein, falls vorhanden; die Framework-Erwähnungen in der Ausschreibung (Playwright vs. Selenium vs. Cypress) prägen den Fragenpool stark.

Für Teststrategie-Übungen führen Sie szenariobasierte Sessions durch: „Sie bekommen Feature X, wie testen Sie es.“ Fünf davon hintereinander in verschiedenen Domänen (E-Commerce, Fintech, Mobile, B2B-SaaS) baut den Pattern-Matching-Muskel auf. Für SDET-Coding-Übungen kombinieren Sie den Mock mit einem echten Editor — der Mock übernimmt den verbalen Durchlauf, warum Ihr Test so strukturiert ist, wie er ist.

Ein zu wenig genutzter Drill: Lassen Sie die AI die Rolle eines sturen Entwicklers spielen, der Ihren Bug-Report nicht beheben will. Üben Sie, den Fall ruhig mit Belegen zu vertreten. Dieses Gespräch ist die Hälfte des QA-Alltags und wird fast nie geprobt.

Häufig gestellte Fragen