QA Tester Beispielfragen: Worauf es bei technischen Interviews ankommt

Warum Standard-QA-Fragen beim Einstellungsprozess fehlschlagen

Die meisten QA-Interview-Fragen fallen in zwei Fallen: Sie sind entweder so allgemein („Was ist der Unterschied zwischen Testen und QA?"), dass jeder, der eine Zertifiziierungsprüfung bestanden hat, sie korrekt beantwortet, oder so spezifisch für deinen Tech-Stack, dass sie eher Framework-Wissen als echtes Denken prüfen. Kandidaten, die Test-Vokabeln auswendig gelernt haben, wirken kompetent. Diejenigen, die wirklich Software zum Absturz bringen und Prozesse optimieren, fallen durchs Raster.

Gute QA-Fragen messen Test-Strategie, nicht Terminologie. Sie zeigen, was Kandidaten wirklich tun, wenn sie keinem vorgegebenen Testplan folgen können. Strukturierte QA- und Test-Automatisierungs-Assessments schließen diese Lücke, indem sie realistische Fehlersuche statt nur Vokabularwissen bewerten.

Beispielfrage #1: Das Bug-Report-Szenario

„Du testest einen E-Commerce-Checkout-Flow. Das Zahlungs-Gateway akzeptiert manchmal versehentlich doppelte Transaktionen – gleiche Bestellungs-ID, gleicher Betrag, innerhalb von 5 Sekunden. Das passiert etwa bei 1 von 50 Mal. Erkläre mir, wie du dieses Problem untersuchen und dokumentieren würdest."

Was du damit misst:

• Stellen sie Verständnisfragen (Zahlungsmethode? Browser? Netzwerkbedingungen)?
• Unterscheiden sie zwischen Bug-Reproduktion, Grundursache und Scope (ihr Code oder das Gateway)?
• Können sie einen Test-Case formulieren, der den Fehler wieder reproduziert?
• Würden sie eskalieren oder erst selbst versuchen, den Fehler zu reproduzieren?

Das zeigt, ob sie wie Ingenieure denken (Grundursache, Scope, Prävention) oder nur wie Bug-Reporter (Symptom, Screenshot, Ticket).

Beispielfrage #2: Der Automatisierungs-Trade-off

„Du hast eine Test-Suite, die End-to-End 2 Stunden dauert. Das Team läuft sie einmal täglich aus. Ein Teamkollege schlägt vor, den UI-Flow für Bild-Uploads zu automatisieren – etwa 40 Zeilen Selenium und 15 Minuten Wartung pro Quartal. Würdest du das machen? Begründe deine Überlegung."

Was du damit misst:

• Denken sie über ROI nach (Automatisierungs-Kosten vs. manuelle Retesting-Kosten)?
• Wissen sie, wann Automatisierung ein Overhead ist statt Effizienz?
• Können sie ehrlich den Wartungsaufwand abschätzen?
• Berücksichtigen sie Anfälligkeit und False Positives?

Kandidaten, die „ja, automatisiert alles" oder „nein, UI-Tests sind zu fehleranfällig" sagen, verfehlen den Punkt. Die richtige Antwort ist normalerweise: „Das hängt davon ab, was der Test fängt und wie oft er fehlschlägt."

Beispielfrage #3: Die Test-Design-Herausforderung

„Wir entwickeln eine Funktion, die Nutzerdaten als CSV exportiert. Die Datei kann zwischen 10 und 100.000 Zeilen haben. Was würdest du testen? Was würdest du bewusst nicht testen und warum?"

Was du damit misst:

• Können sie priorisieren (CSV-Format, Zeilenanzahl-Edge-Cases, Sonderzeichen) statt Nebensächliches zu testen (spielt die Button-Farbe eine Rolle)?
• Wissen sie, was automatisiert werden sollte vs. was man manuell spot-checked?
• Können sie geschäftliche Risiken (Datenleck, Format-Korruption) von Vorlieben unterscheiden?

Gute QA-Ingenieure sind unnachgiebig beim Scope. Sie testen nicht alles – sie testen das, was dem Geschäft schaden könnte.

Beispielfrage #4: Das Regressions-Risiko

„Dein Team hat gerade die Datenbankabfragen auf der Benutzerprofilseite überarbeitet. Es gab keine Schema-Änderungen, nur Code-Bereinigung. Was ist deine Test-Strategie? Wie hoch ist dein Vertrauenslevel?"

Was du damit misst:

• Wollen sie die komplette Regressions-Suite laufen lassen oder erst kritisch überlegen?
• Können sie identifizieren, was potenziell kaputt gehen könnte (N+1-Queries, falsche Datenbindung)?
• Verstehen sie den Unterschied zwischen „Code wurde geändert" und „Risiko ist gestiegen"?

Das unterscheidet Analysten von Ingenieuren. Ingenieure fragen „Was hat sich geändert und wo ist das Risiko?" Analysten führen die komplette Suite aus, egal was.

Beispielfrage #5: Die Cross-Browser-Frage (mit einer Wendung)

„Du testest eine neue UI-Komponente auf Chrome, Firefox und Safari. Sie wird überall korrekt angezeigt. Testest du sie auch auf IE11? Auf mobilem Chrome? Auf Chromium-basierten Browsern wie Edge? Triff die Trade-off-Entscheidung."

Was du damit misst:

• Kennen sie deine tatsächliche Nutzerbasis (nicht alle Produkte brauchen IE11-Support)?
• Können sie Browser-Coverage gegen Test-Kosten abwägen?
• Wissen sie den Unterschied zwischen echten Browsern und künstlicher Test-Abdeckung?

Hier zählt die Meinung. „Wir unterstützen IE11 nicht, also nein" ist eine stärkere Antwort als „wir sollten auf allem testen."

Beispielfrage #6: Das Live-Coding-Interview (kurz)

„Schreib einen Test-Case in dem Framework, das du am besten beherrschst. Ich gebe dir eine einfache Funktion: validateEmail(email). Sie gibt true zurück, wenn es eine gültige E-Mail ist, false sonst. Schreib den Test – nicht die Funktion."

Was du damit misst:

• Können sie über Edge Cases nachdenken (leerer String, kein @, mehrere @, Leerzeichen)?
• Schreiben sie lesbaren oder kryptischen Test-Code?
• Beherrschen sie ihr Test-Framework (Assertions, Setup/Teardown)?
• Testen sie das Verhalten oder die Implementierung?

Das ist ein Live-Coding-Interview, das 10 Minuten dauert und Sprachfertigkeit, Test-Struktur und analytisches Denken zeigt.

Das Muster, das funktioniert

Alle sechs Fragen folgen dem gleichen Aufbau: Stell eine echte (oder realistische) Situation vor, bitte den Kandidaten, sie durchzudenken, und achte auf seine Urteils­fähigkeit, nicht auf Stichwort-Wiedergabe. Es gibt keine richtigen oder falschen Antworten. Die Antworten sind aussagekräftig.

Die besten Interviews sind diejenigen, in denen der Kandidat dir eine Verständnisfrage stellt, die dich inne­halten lässt. Das ist das Signal. Das ist der richtige Hire.

Wann man stattdessen schriftliche Assessments nutzt

Nicht jede QA-Neueinstellung braucht ein aufgezeichnetes Live-Coding-Interview. Eine Take-Home-Test-Case-Aufgabe kann genauso aussagekräftig sein: „Hier ist eine Feature-Spezifikation. Schreib 10-15 Test-Cases, die du deinem Team vorlegen würdest. Begründe deine Priorisierung." Dann stelle in der nächsten Runde Folgefragen zu ihrer Überlegung. Das kombiniert die Qualität des Artefakts mit einer mündlichen Verteidigung.

Zum Skalieren von Einstellungsprozessen helfen Assessment-Plattformen, die Test-Case-Coverage, Assertion-Qualität und Edge-Case-Logik bewerten können, um Live-Interviews effizienter zu gestalten.

Gegenposition

Manche Teams bevorzugen verhaltensgestützte Interviews ganz ohne Testing-Terminologie: „Erzähl mir von einem Bug, den du gefunden hast und der dich überrascht hat" oder „Beschreib mir das letzte Mal, als du eine Deadline hinterfragt hast, weil Testen noch nicht fertig war." Das funktioniert auch, besonders wenn du Leute einstellst, die Qualität verantworten, statt Menschen, die reine Tester sind.

Die konkreten Fragen sind weniger wichtig als die Grundphilosophie: Du misst Denkvermögen, nicht Gedächtnis. Alles andere folgt daraus.