QA-Ingenieur Interviewfragen & Antworten

Beispielantwort

Bei Regressionstests für ein Payment-Processing-Update fiel mir auf, dass die Währungskonvertierung bei Transaktionen unter 1 $ falsch rundete. Die automatisierten Tests liefen grün, weil alle Testfälle Beträge über 10 $ verwendeten. Ich entdeckte es beim explorativen Testen: Ich prüfte systematisch Grenzwerte nahe null und stellte fest, dass Transaktionen von 0,99 $ oder weniger nach der Währungskonvertierung auf 0,00 $ gerundet wurden. Die Ursache war eine Integer-Division statt einer Float-Division in der Konvertierungsfunktion. Wäre das in die Produktion gelangt, hätte es etwa 15 % unserer Mikrotransaktionen betroffen, rund 8.000 tägliche Transaktionen mit einem geschätzten täglichen Umsatzverlust von 3.200 $. Nach der Behebung ergänzte ich die automatisierte Testsuite um 20 Grenzwert-Testfälle, die kleine Beträge, Nullbeträge und Maximalbeträge in jeder unterstützten Währung abdeckten.

Beispielantwort

Unsere Ende-zu-Ende-Testsuite brauchte 3 Stunden und blockierte jeden Pull-Request-Merge. Entwickler übersprangen Tests oder bündelten PRs, um die Wartezeit zu umgehen. Ich analysierte die Suite und fand drei Probleme: Tests liefen sequenziell statt parallel, 30 % der Tests waren redundant (sie testeten dieselben Code-Pfade), und fehlerhafte Tests ließen 40 % der Durchläufe beim ersten Versuch scheitern. Ich containerisierte die Testumgebung, sodass Tests parallel über 8 Worker laufen konnten, löschte 45 redundante Tests und isolierte 12 instabile Tests, während ich ihre Ursachen behob (meist Race Conditions und fest codierte Testdaten). Die Laufzeit sank von 3 Stunden auf 25 Minuten, die Fehlerrate fiel von 40 % auf unter 2 %, und die Häufigkeit der PR-Merges durch Entwickler verdoppelte sich. Das Team betrachtete Tests nicht länger als Hindernis, sondern vertraute ihnen als Sicherheitsnetz.

Beispielantwort

Mir fiel auf, dass unsere Suchfunktion bei identischer Abfrage Ergebnisse in unterschiedlicher Reihenfolge zurückgab. Der Entwickler bezeichnete es als 'by design', weil die Ergebnisse gleiche Relevanz-Scores hatten und die Datenbank bei Gleichstand keine Reihenfolge garantierte. Ich argumentierte, dass es sich um einen UX-Bug handelte, auch wenn es technisch korrekt war: Nutzer erwarten konsistente Ergebnisse. Ich zeigte Nutzer-Session-Aufzeichnungen, in denen Nutzer durch sich verschiebende Suchergebnisse verwirrt wurden. Wir einigten uns: Wir fügten eine sekundäre Sortierung nach Erstellungsdatum für Ergebnisse mit gleicher Relevanz hinzu, was deterministische Reihenfolge ohne Änderung des Relevanz-Algorithmus ermöglichte. Die Lektion: 'Bug vs. Feature'-Diskussionen löst man am besten durch den Blick auf den Nutzereffekt, nicht auf technische Korrektheit. Wenn Nutzer verwirrt sind, muss sich etwas ändern, unabhängig davon, was die Spezifikation besagt.

Beispielantwort

Als ich dem Team beitrat, schrieben Entwickler minimale Unit-Tests und verließen sich vollständig auf QA für die Fehlererkennung. Statt Vorträge über Testabdeckung zu halten, begann ich, während Code-Reviews gemeinsam mit Entwicklern Testcode zu schreiben. Ich sagte: 'So würde ich diese Funktion testen. Sollen wir diese Fälle ergänzen?' Nach einigen Sitzungen begannen Entwickler, eigene Tests zu schreiben. Ich erstellte außerdem eine 'Bug-Wand', ein Dashboard, das zeigte, wo Bugs gefunden wurden (Unit-Test, Integrationstest, QA, Produktion). Über 3 Monate zeigte die Daten klar, dass spät gefundene Bugs exponentiell mehr kosten. Die Produktionsfehlerquote sank um 55 %, als Entwickler die Shift-Left-Denkweise verinnerlichten. Der Schlüssel war Zusammenarbeit statt Konfrontation. Ich positionierte mich als Partner für Qualität.

Beispielantwort

Die Testpyramide hat drei Schichten: Unit-Tests an der Basis (schnell, isoliert, viele), Integrationstests in der Mitte (testen Komponenteninteraktionen, mittlere Anzahl) und Ende-zu-Ende-Tests an der Spitze (langsam, gesamtes System, wenige). In der Praxis strebe ich grob 70 % Unit-, 20 % Integrations- und 10 % E2E-Tests an. Unit-Tests decken einzelne Funktionen und Randfälle ab: Sie laufen in Millisekunden und geben sofortiges Feedback. Integrationstests prüfen, ob Komponenten zusammenarbeiten: API-Endpunkte liefern korrekte Antworten, Datenbankabfragen funktionieren gegen ein echtes Schema, Message-Consumer verarbeiten Nachrichten korrekt. E2E-Tests decken kritische Nutzerpfade ab: Registrierung, Kauf, Kernworkflow. Ich halte diese minimal, weil sie langsam, instabil und wartungsaufwändig sind. Das Anti-Pattern, gegen das ich am häufigsten ankämpfe: die 'umgekehrte Pyramide', bei der Teams 500 E2E-Tests und 20 Unit-Tests haben. Das bedeutet 3-stündige Test-Läufe, ständige Instabilität und Entwickler, die Fehlschläge ignorieren.

Beispielantwort

Ich würde auf vier Ebenen testen. Contract-Testing: Prüfen, ob Request- und Response-Schemas mit der OpenAPI-Spezifikation übereinstimmen. Das fängt Breaking Changes ab, bevor sie Consumer betreffen. Funktionaler Test: Für jeden Endpunkt Happy Paths, Validierungsfehler (fehlende Felder, falsche Typen, Grenzwerte), Authentifizierung und Autorisierung (unbefugter Zugriff, falsche Rolle) und Randfälle testen (leere Collections, maximale Payload-Größen, Sonderzeichen). Integrationstest: Sicherstellen, dass die API korrekt mit ihren Abhängigkeiten interagiert: Datenbankoperationen, externe Service-Aufrufe, Message-Queue-Publishing. Ein echtes Datenbankschema mit Testdaten verwenden, externe Services auf Netzwerkebene mocken. Performance-Test: Antwortzeit unter normaler Last messen (Baseline), Stress-Test bis zum Bruchpunkt, Soak-Test auf Memory-Leaks über längere Zeiträume. Das alles würde ich in der CI-Pipeline automatisieren: Contract- und Funktionstests bei jedem PR, Integrationstests beim Merge in main, Performance-Tests nächtlich. Für Funktionstests würde ich Postman/Newman einsetzen, für Performance k6 oder JMeter, für Contract-Testing Pact.

Beispielantwort

Ein Stub gibt vorkonfigurierte Antworten zurück. Er ersetzt eine Abhängigkeit durch eine vereinfachte Version mit vorhersehbarer Ausgabe. Ich verwende Stubs, wenn ich eine Abhängigkeit brauche, die bestimmte Daten zurückgibt, mir aber nicht wichtig ist, wie sie aufgerufen wird. Ein Mock ist ein Stub, der zusätzlich aufzeichnet, wie er aufgerufen wurde, und Interaktionen überprüfbar macht: Wurde diese Methode mit diesen Argumenten aufgerufen? Ich nutze Mocks, wenn das getestete Verhalten die Interaktion selbst ist, zum Beispiel zu prüfen, ob ein Service nach der Registrierung eine E-Mail sendet, nicht was die E-Mail enthält. Ein Fake ist eine funktionierende Implementierung mit Abkürzungen, etwa eine In-Memory-Datenbank statt PostgreSQL oder ein lokales Dateisystem statt S3. Ich verwende Fakes, wenn ich realistisches Verhalten brauche, die echte Abhängigkeit aber in Tests nicht nutzen kann. Meine Faustregel: Fakes für Datenspeicher (realistischer), Stubs für externe APIs (vorhersehbar), Mocks sparsam für Interaktionsverifikation. Over-Mocking ist ein verbreitetes Anti-Pattern. Wenn alles gemockt ist, testet man die Mocks, nicht den Code.

Beispielantwort

Instabile Tests sind ein ernstes Problem: Sie untergraben das Vertrauen in die Testsuite und trainieren Entwickler, Fehlschläge zu ignorieren. Mein Ansatz: Zunächst instabile Tests systematisch identifizieren. Ich tagge Tests, die unregelmäßig scheitern, und erfasse ihre Fehlerrate. Jeder Test, der ohne Code-Änderung mehr als einmal fehlschlägt, gilt als instabil. Dann Quarantäne: Instabile Tests in eine separate Suite verschieben, die läuft, aber Deployments nicht blockiert. Das bewahrt das Signal-Rausch-Verhältnis der Hauptsuite. Anschließend Ursachen beheben: Die häufigsten Quellen sind Timing-Probleme (explizite Wartezeiten für asynchrone Operationen statt Sleep), geteilter Zustand (Testisolierung mit korrektem Setup/Teardown), externe Abhängigkeiten (mocken oder containerisieren) und Reihenfolgeabhängigkeit (Tests, die einzeln bestehen, aber nach einem anderen Test scheitern). Schließlich neue instabile Tests verhindern: Retry-Erkennung im CI einbauen. Wenn ein Test beim Wiederholungsversuch besteht, als potenziell instabil markieren und ein Ticket erstellen. Instabile Tests mit derselben Dringlichkeit wie Produktionsfehler zu behandeln hält die Suite zuverlässig.

Beispielantwort

Ich würde nicht abstrakt für 'Testzeit' argumentieren, sondern das Risiko konkret machen. Meine Frage: 'Was kostet es, wenn wir einen kritischen Bug an unsere 50.000 Nutzer ausliefern?' Dann würde ich einen risikobasierten Testplan vorlegen. Ich kann nicht alles testen, also identifiziere ich die Bereiche mit dem höchsten Risiko: neuer Code, geänderter Code und kritische Nutzerpfade (Zahlung, Authentifizierung, Datenintegrität). Ich schlage einen gezielten 2-tägigen Testplan vor, der diese Bereiche abdeckt, ergänzt durch parallel laufende automatisierte Regressionstests. Außerdem stelle ich die Alternative dar: Wir können ohne Tests ausliefern, brauchen aber einen schnellen Rollback-Plan und jemanden im Bereitschaftsdienst. Den Kompromiss explizit zu machen ('Wir sparen 2 Tage, akzeptieren aber das Risiko von X') verändert das Gespräch meistens. Wenn der PM auf null Tests besteht, dokumentiere ich die Entscheidung und die Risiken schriftlich. Wenn man das Risiko klar beziffert, lautet die Antwort fast immer: 'Lass uns 2 Tage finden.'

Beispielantwort

Zuerst beurteile ich Schweregrad und Auswirkung. Betrifft er Kernfunktionen (Datenverlust, Sicherheit, Zahlung), eskaliere ich sofort und empfehle, den Release zu verschieben, ohne Ausnahme. Bei einem UI-Problem oder einem Nebenfluss prüfe ich, ob wir mit einem bekannten Problem ausliefern und innerhalb von 24 Stunden hotfixen können. Ich kommuniziere klar an Release-Manager und Product Owner: Hier ist der Bug, das ist die Auswirkung, das sind die Optionen. Option A: Release verschieben, Bug beheben, Regression durchlaufen. Option B: Release ohne das betroffene Feature (per Feature-Flag deaktivieren). Option C: Release mit bekanntem Problem, Hotfix morgen. Ich gebe meine Empfehlung, überlasse die Entscheidung aber den Verantwortlichen. Was ich nicht tue: ignorieren, herunterspielen oder einen überstürzten Fix ohne Tests versuchen. Jeder 'Quick Fix', den ich 1 Stunde vor dem Release erlebt habe, hat einen zweiten, schlimmeren Bug eingeführt.

Beispielantwort

Ich beginne damit, zu testen, was ich aus dem Feature selbst ableiten kann: Es wie ein Nutzer verwenden und meine Annahmen dokumentieren. Ich erstelle einen Testplan auf Basis dieser Annahmen und teile ihn mit Product Manager und Entwickler: 'Das plane ich zu testen. Das sind meine Annahmen. Stimmen sie? Was fehlt mir?' Dieser Ansatz ist schneller als auf perfekte Anforderungen zu warten und deckt oft Lücken auf, an die der PM nicht gedacht hat. Für jede Lücke stelle ich konkrete Fragen: 'Was passiert, wenn der Nutzer mehr als 500 Zeichen eingibt? Was soll die Fehlermeldung sagen? Soll das Formular Daten bei einem Validierungsfehler behalten?' Außerdem schaue ich mir ähnliche Features im Produkt auf Konsistenzmuster an. Das Ziel: vage Anforderungen durch Gespräch in testbare Akzeptanzkriterien umwandeln, nicht auf eine perfekte Spezifikation warten, die vielleicht nie kommt.

Beispielantwort

Ich behandle es als echte Untersuchung, nicht als Konfrontation. Zunächst prüfe ich die Test-Assertion gegen die aktuellen Anforderungen: Testet der Test veraltetes Verhalten? Wenn das Feature absichtlich geändert wurde und der Test nicht aktualisiert wurde, ist das eine Prozesslücke. Ich aktualisiere den Test entsprechend. Dann prüfe ich, ob die Verhaltensänderung beabsichtigt war: Commit-Historie, Pull-Request-Beschreibung und verknüpfte Tickets. Gibt es eine dokumentierte Entscheidung zur Verhaltensänderung, wird der Test aktualisiert. Fehlt die Dokumentation, frage ich Entwickler und PM zur Bestätigung. Manchmal ändern Entwickler beim Refactoring unbeabsichtigt das Verhalten, und der vermeintlich falsche Test hat tatsächlich einen echten Bug gefunden. In jedem Fall bringt das Gespräch ein gutes Ergebnis: Entweder aktualisieren wir den Test (und die Änderung ist dokumentiert) oder wir entdecken eine unbeabsichtigte Regression. Außerdem weise ich auf die Prozessverbesserung hin: Verhaltensänderungen sollten Test-Updates im selben PR auslösen.