Der beste QA-Test für Test-Automation-Engineers: deine Bewertung aufbauen

Was „beste" für QA-Bewertungen bedeutet

Es gibt keinen einzelnen QA-Test, der für jede Einstellung funktioniert. Aber es gibt ein Muster, das funktioniert: eine mehrschichtige Bewertung, die Test-Denken von Coding-Tempo trennt, Urteilsvermögen von Wissen, Architektur von Syntax.

Der beste QA-Test ist nicht der härteste. Es ist der, der zeigt, ob die Bewerberin eine Test-Suite drei Jahre lang pflegt, ohne auszubrennen.

Die ideale Bewertungsstruktur

Teil 1: Testfall-Design (schriftlich, 30–45 Minuten)

Nicht verhandelbar. Das ist der erste Filter.

Gib Bewerberinnen eine realistische Feature-Spec — nicht „teste Login" (zu vage), nicht „schreibe 100 Testfälle" (zu viel). Etwas dazwischen: „Hier ist ein Feature, das User-Daten aus CSV bulk-importiert. Schreibe 8–12 Testfälle, die du deinem Team vorschlagen würdest."

Was du bewertest:

• Abdeckung: Identifiziert sie Grenzfälle (leere Datei, 100k Zeilen, Sonderzeichen)?
• Klarheit: Kann jemand die Tests ausführen, ohne sie anzurufen?
• Urteilsvermögen: Priorisiert sie kritische Fälle oder behandelt sie alles gleich?
• Realismus: Erkennt sie Constraints (Datensetup, Umgebung)?

Nutze eine Rubrik: Abdeckung 25 %, Klarheit 25 %, Urteil 25 %, Machbarkeit 25 %. Nicht perfekt objektiv, aber konsistent.

Bewertungszeit: 10–15 Minuten pro Bewerberin.

Teil 2: Automatisierungscode (Take-home, 2–3 Stunden)

Wer Teil 1 besteht, bekommt einen Take-home: „Hier ist eine Sandbox-App. Wähle 4–5 deiner Testfälle und automatisiere sie. Nutze das Framework, das du kannst."

Was du bewertest:

• Codequalität: lesbar, wartbar, nicht zu klug?
• Framework-Fluenz: valide Syntax, korrekte Assertions, sinnvolle Waits?
• Robustheit: überlebt der Test eine kleine UI-Änderung oder ist er brüchig?
• Architektur: Page Objects, Datensetup, Teardown?

Bewerte nicht auf Tempo. Wer 2 solide Tests in 2,5 Stunden schreibt, ist stärker als wer 8 schnelle hinrotzt.

Was ignorieren: ob sie Selenium oder Cypress wählt, welche Lib. Das sind Vorlieben. Testqualität zählt.

Bewertungszeit: 15–20 Minuten. Achte auf: Selektoren, die nicht brechen, sinnvolle Waits, Assertions, die Verhalten (nicht nur DOM-Zustand) prüfen, lesbarer Code.

Teil 3: Live-Prozess-Interview (60 Minuten)

Hier glänzt Urteilsvermögen. 2–3 Szenarien:

Szenario 1: „Deine Regression-Suite läuft 3 Stunden. Das Team will sie auf 1 Stunde kürzen, um schnelleres Deployment zu ermöglichen. Was machst du?"

Szenario 2: „Ein kritischer Production-Bug wurde von deiner Suite übersehen. Race Condition, 1 von 100. Erklär mir deine Ermittlung."

Szenario 3: „Ein Feature launcht in 2 Wochen. Tests sind nicht fertig. Ohne volle Abdeckung zu launchen exponiert uns für Datenverlust. Was schlägst du vor?"

Keines hat eine richtige Antwort. Höre auf:

• Stellt sie Klärungsfragen (Teamgröße, User-Impact, Budget)?
• Kann sie Trade-offs ohne Hedging artikulieren?
• Denkt sie wie eine Engineerin (Risiko, ROI, Wartung) oder nur wie eine Testerin (Abdeckung)?
• Ist sie ehrlich zu Constraints?

Zeit: 20 Minuten Fragen, 10 Reasoning, 30 Follow-up und ihre Fragen.

Teil 4 (optional): Code-Review (30–45 Minuten)

Wenn deine QA-Rolle Test-Code-Reviews umfasst, füge das hinzu.

Gib eine Test-Suite mit 3–5 Problemen: flackriger Selektor, fehlende Fehlerbehandlung, übermäßig gepasste Tests, Setup/Teardown-Race. Bitte sie, die Probleme zu finden und Fixes vorzuschlagen.

Was du bewertest:

• Kann sie Code lesen und kritisieren?
• Versteht sie Fehlerszenarien?
• Sind ihre Vorschläge praktisch oder theoretisch?

Nur notwendig, wenn dein Team Test-Code wirklich reviewt.

Gesamter Zeitaufwand

• Teil 1 (schriftlich): 45 min Bewerberin, 10–15 min Bewertung
• Teil 2 (Take-home): 2–3 h Bewerberin, 15–20 min Bewertung
• Teil 3 (Live): 1 h Bewerberin, 30 min Interview, 10 min Notizen
• Teil 4 (optional): 30–45 min Bewerberin, 10 min Bewertung

Gesamt: 4–5 h Bewerberinzeit, 1,5–2 h Recruiter/Interviewer pro Bewerberin. Vernünftig für Senior-Hire.

Screening vor der Bewertung

Schick den Take-home nicht an alle. Nutze Teil 1 (Testfall-Design) als Screen.

Wer in 45 Minuten keinen kohärenten Testfall designt, wird auch keinen soliden Automatisierungscode schreiben. Spar die 3-Stunden-Take-home für Bewerberinnen, die den schriftlichen Teil bestehen.

Grobe Bestehensquote: ziele auf 40–60 % von schriftlich zu Take-home. Viel höher = Rubrik zu mild. Niedriger = Spec womöglich unklar.

Kalibrierung

Bevor du einstellst, kalibriere dein Team auf „gut".

Lass die Bewertung an 2–3 bekannt-guten Mitgliedern deines Teams laufen. Wie sehen ihre Testfälle aus? Codequalität? Das ist dein Referenzstandard.

Lass sie an 2–3 bekannt-schlechten Hires laufen (Leute, die nicht funktioniert haben). Was war schwach? Auch dieser Negativraum zählt.

Du musst nicht perfekt objektiv sein. Du willst konsistent sein.

Wann Teile weglassen

Manuelle QA-Rolle (explorativ, keine Automatisierung): überspringe Teil 2 und 4. Fokussiere auf Teil 1 (Test-Denken) und 3 (Urteil).

Mid-Level mit verifiziertem Portfolio: überspringe vielleicht Teil 1 und gehe direkt zu 2 und 3. Nur wenn du echten Code gesehen hast.

Massen-Hiring, frühe Phase: beginne nur mit 1 + 3 (skip Take-home). Schneller. Wenn dein Prozess stabil ist, füge 2 für Endrunden hinzu.

Warum diese Struktur Alternativen schlägt

Besser als Leetcode-Probleme: die testen Coding-Tempo, nicht Test-Denken oder Architektur.

Besser als ein einzelnes Live-Coding-Interview: in 60 Minuten kannst du Test-Design oder Code-Wartung nicht beurteilen.

Besser als nur Portfolio-Review: Portfolios sind kuratiert. Ein Assessment zeigt aktuelle Skills, nicht beste Arbeit von vor drei Jahren.

Die Struktur funktioniert, weil sie Signale trennt. Test-Design ist anders als Codequalität, anders als Urteilsvermögen. Du brauchst alle drei.

Gegenüberlegung: vielleicht stellst du falsch ein

Manche Teams argumentieren, du solltest starke Engineers einstellen, die Testing nebenher machen, statt Spezialistinnen, die nur testen.

Fair, wenn deine Engineers stark genug sind. Aber starke Engineers, die „nebenbei QA machen sollen", tun es oft nicht. QA wird zur Aufgabe, die sie hassen. Du landest bei nicht-gewarteten Tests und ausgebrannten Engineers.

Stelle Leute ein, die diese Disziplin gewählt haben. Das Assessment hilft dir, sie zu finden.