QA Tester Test: Beispielfragen und Coaching

Warum Standard-QA-Fragen beim Hiring fehlschlagen

Die meisten QA-Interview-Fragen fallen in zwei Fallen: Sie sind entweder so generisch („Was ist der Unterschied zwischen Testen und QA?"), dass jeder, der eine Zertifiziierungsprüfung besteht, sie beantworten kann, oder so spezifisch für deinen Tech-Stack, dass sie Framework-Wissen statt Denken testen. Die Kandidaten, die Test-Vokabeln auswendig lernen, klingen kompetent. Diejenigen, die tatsächlich Software brechen und Prozesse beheben, sind unsichtbar.

Gute QA-Fragen messen Test-Strategie, nicht Terminologie. Sie offenbaren, was Kandidaten wirklich tun, wenn sie keinem Testplan folgen.

Beispielfrage #1: Das Bug-Report-Szenario

„Du testest einen E-Commerce-Checkout-Flow. Das Zahlungs-Gateway akzeptiert manchmal doppelte Transaktionen — dieselbe Bestellungs-ID, derselbe Betrag, innerhalb von 5 Sekunden. Dies passiert ungefähr 1 zu 50 Mal. Gehe mir durch, wie du dies untersuchen und dokumentieren würdest."

Was du misst:

• Stellen sie Klarstellungsfragen (welche Zahlungsmethode? welcher Browser? Netzwerkbedingungen)?
• Unterscheiden sie zwischen Bug-Reproduktion, Grundursache und Umfang (ist es in ihrem Code oder im Gateway)?
• Können sie einen Testfall artikulieren, der es erneut erwischt?
• Würden sie eskalieren oder erst selbst versuchen, es zu reproduzieren?

Dies offenbart, ob sie wie Ingenieure denken (Grundursache, Umfang, Prävention) oder nur wie Reporter (Symptom, Screenshot, Ticket).

Beispielfrage #2: Der Automatisierungs-Trade-off

„Du hast eine Test-Suite, die End-to-End 2 Stunden läuft. Dein Team führt sie einmal täglich aus. Ein Teamkollege schlägt vor, den UI-Flow für Bild-Uploads zu automatisieren — ungefähr 40 Zeilen Selenium und 15 Minuten Wartung pro Quartal. Machst du es? Gehe mir durch deine Überlegung."

Was du misst:

• Denken sie über ROI nach (Kosten zur Automatisierung vs. Kosten für manuelles Retesting)?
• Wissen sie, wann Automatisierung Overhead ist, nicht Effizienz?
• Können sie Wartungslast ehrlich schätzen?
• Bedenken sie Zerbrechlichkeit und falsche Positive?

Kandidaten, die sagen „ja, automatisiere alles" oder „nein, UI-Tests sind flaky" verfehlen den Punkt. Die richtige Antwort ist normalerweise „es hängt davon ab, was es erwischt und wie oft es bricht."

Beispielfrage #3: Die Test-Design-Herausforderung

„Wir bauen eine Funktion, die Benutzerdaten zu CSV exportiert. Die Datei kann 10 bis 100.000 Zeilen haben. Was würdest du testen? Was würdest du nicht testen und warum?"

Was du misst:

• Können sie priorisieren (CSV-Format, Zeilen-Zahl Edge Cases, Sonderzeichen) vs. Rauschen (spielt die Button-Farbe eine Rolle)?
• Wissen sie, was es wert ist zu automatisieren vs. Spot-zu-prüfen?
• Können sie Risiko (Datenleck, Formatierungskorruption) vs. Vorliebe artikulieren?

Gute QA-Ingenieure sind erbarmungslos über Umfang. Sie testen nicht alles; sie testen, was das 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 ist dein Vertrauenslevel?"

Was du misst:

• Möchten sie die vollständige Regressions-Suite ausführen oder zuerst kritisch denken?
• Können sie identifizieren, was könnte brechen (N+1-Queries, falsche Datenbindung)?
• Verstehen sie den Unterschied zwischen „Code hat sich geändert" und „Risiko hat sich geändert"?

Dies trennt Analysten von Ingenieuren. Ingenieure fragen „was hat sich geändert und was ist wichtig?" Analysten führen die volle Suite unabhängig aus.

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

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

Was du misst:

• Kennen sie deine Benutzerbasis (nicht alle Produkte brauchen IE11-Unterstützung)?
• Können sie Browser-Coverage vs. Test-Kosten schätzen?
• Wissen sie den Unterschied zwischen echten Browsern und gefälschter Coverage?

Dies ist, wo Meinung zählt. „Wir unterstützen IE11 nicht, also nein" ist stärker als „wir sollten alles testen."

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

„Schreibe einen Testfall in welchem Framework du am besten kennst. Ich werde dir eine einfache Funktion geben: validateEmail(email). Gib wahr zurück, wenn es eine gültige E-Mail ist, falsch sonst. Schreibe den Test — schreibe nicht die Funktion."

Was du misst:

• Können sie über Edge Cases denken (leerer String, kein @, mehrere @, Leerzeichen)?
• Schreiben sie lesbare oder kryptische Tests?
• Kennen sie ihr Test-Framework (Assertions, Setup/Teardown)?
• Testen sie Verhalten oder Implementierung?

Dies ist ein Live-Coding-Interview, das 10 Minuten dauert und Sprachflüssigkeit, Test-Struktur und Denken offenbart.

Das Muster, das funktioniert

Alle sechs dieser Fragen haben dieselbe Struktur: Stelle eine echte (oder realistische) Situation vor, bitte den Kandidaten, sie zu durchdenken, und achte auf Urteil, nicht Keyword-Wiedergabe. Die Antworten sind nicht richtig oder falsch. Sie sind offenbaren.

Die Interviews, die du dir merken wirst, sind diejenigen, in denen ein Kandidat dir eine Klarstellungsfrage stellt, die dich innehalten lässt. Das ist das Signal. Das ist der Hire.

Wann man schriftliche Bewertungen stattdessen verwendet

Nicht jede QA-Einstellung braucht ein aufgezeichnetes Live-Coding-Interview. Eine Take-Home-Test-Case-Aufgabe kann gleich offenbaren sein: „Hier ist eine Feature-Spezifikation. Schreibe 10-15 Testfälle, die du deinem Team vorschlagen würdest. Erkläre deine Priorität." Stelle dann Folgefragen in der nächsten Runde zu ihrer Überlegung. Dies kombiniert Artefakt-Qualität mit verbaler Verteidigung.

Zum Skalieren von Hiring verwenden Assessment-Plattformen, die Test-Case-Coverage, Assertion-Qualität und Edge-Case-Denken bewerten können, Live-Runden effizienter.

Gegenüberlegung

Manche Teams bevorzugen verhaltensführerliche Interviews ohne die Test-Terminologie überhaupt: „Erzähl mir von einem Bug, den du gefunden hast, der dich überrascht hat" oder „Gehe mir durch, das letzte Mal, als du eine Frist in Frage gestellt hast, weil Testen nicht erledigt war." Dies funktioniert auch, besonders wenn du Leute einstellst, die Qualität besitzen, statt Leute, die sind Tester.

Die Fragen spielen eine kleinere Rolle als die Philosophie: Du misst Denken, nicht Gedächtnis. Alles andere folgt.