Cum să evaluezi QA engineers: construirea unui proces de hiring pentru test automation

De ce hiring-ul QA e stricat

Majoritatea companiilor evaluează QA engineers ca programatori cu insignă QA. Pun întrebări algoritmice, rulează coding tests. Dar QA engineering e disciplină diferită: trade-offs și judecată sub constrângere.

Cele trei straturi ale evaluării QA

Stratul 1: design de test cases (scris, 45 min)

Spec realist de feature. 12-15 test cases. Fără cod.

Ce evaluezi:

• Acoperire: happy path, eroare, edge, tranziții de stare?
• Claritate: altcineva poate citi și executa?
• Prioritizare: marchează critic vs nice-to-have?
• Awareness de context: întreabă despre environment?

Stratul 2: portofoliu de automation (take-home, 2-3 ore)

Proiect open-source mic. 4-6 teste automatizate în framework-ul lor.

Ce evaluezi:

• Fluență framework: cod valid, executabil
• Structură: independente, lizibile, mentenabile
• Robustețe: waits, error handling, selectori stabili
• Documentație: explică abordarea

Întrebare cheie: "Dacă se strică mâine, cum debug-ezi?"

Stratul 3: proces și judecată (live, 60 min)

"Avem suită de 2 ore. Tăiem la 30 min. Ce faci?" sau "Feature lansează în 2 săptămâni, testing nu e gata. Strategia ta?"

Ce măsori:

• Strategic (risc, ROI) vs tactic
• Pushback fără confruntare
• Context de business
• Articulează trade-offs

Strat opțional: code review

Hiring la scară

Steaguri roșii

• Supra-automation
• Sub-automation
• Absolutism de framework
• Lipsă context
• Fără prioritizare

Test automation vs manual QA

Automation (80% cod): framework + structură. Manual (80% strategie): test cases, edge cases.