Wie man QA-Engineers bewertet: Test-Automation-Hiring-Prozess aufbauen

Warum QA-Hiring kaputt ist

Die meisten Unternehmen bewerten QA-Engineers wie Programmierer mit QA-Badge. Sie stellen algorithmische Fragen, machen Coding-Tests. Aber QA-Engineering ist Programming mit anderen Tools. Es ist andere Disziplin: Trade-offs und Urteil unter Constraint.

Die drei Schichten der QA-Bewertung

Schicht 1: Test-Case-Design (geschrieben, 45 Min)

Realistische Feature-Spec. 12-15 Test-Cases. Kein Code.

Was zu bewerten:

• Coverage: Happy-Path, Error, Edge, State-Transitions?
• Klarheit: Kann jemand sie lesen und ausführen?
• Priorisierung: Kritisch vs. nice-to-have markiert?
• Kontext-Awareness: Fragen zu Environment?

Schicht 2: Automation-Portfolio (Take-Home, 2-3 Stunden)

Kleines Open-Source-Projekt. 4-6 automatisierte Tests in ihrem Framework.

Was zu bewerten:

• Framework-Fluency: Valider, runnable Code
• Struktur: Unabhängig, lesbar, wartbar
• Robustheit: Waits, Error-Handling, stabile Selectors
• Dokumentation: Erklärt Approach

Schlüsselfrage: "Wenn das morgen bricht, wie debuggst du?"

Schicht 3: Prozess und Urteil (live, 60 Min)

"Wir haben 2-Stunden-Suite. Auf 30 Min kürzen. Was tust du?" oder "Feature launcht in 2 Wochen, Testing nicht fertig. Dein Play?"

Was zu bewerten:

• Strategisch (Risiko, ROI) vs. taktisch
• Pushback ohne Konfrontation
• Business-Kontext
• Trade-offs artikulieren

Optionale Schicht: Code-Review

Wenn die Rolle Test-Code-Review beinhaltet.

Hiring at Skala

• Test-Cases graden
• Automation in Sandbox
• Live-Coding aufzeichnen

Rote Flaggen

• Über-Automation
• Unter-Automation
• Framework-Absolutismus
• Fehlender Kontext
• Keine Priorisierung

Test-Automation vs. Manual-QA

Automation (80% Code): Framework + Struktur. Manual (80% Strategie): Test-Cases, Edge-Cases.