Come valutare i QA engineer: costruire un processo di hiring per test automation

Perché l'hiring QA è rotto

La maggior parte delle aziende valuta i QA engineer come programmatori con badge QA. Fanno domande algoritmiche, corrono coding test. Ma il QA engineering è una disciplina diversa: trade-off e giudizio sotto vincolo.

I tre livelli di valutazione QA

Livello 1: design dei test case (scritto, 45 min)

Spec realistico di feature. 12-15 test case. Niente codice.

Cosa valutare:

• Copertura: happy path, errore, edge, transizioni di stato?
• Chiarezza: qualcun altro può leggerlo ed eseguirlo?
• Prioritizzazione: marcano critico vs nice-to-have?
• Awareness di contesto: chiedono dell'environment?

Livello 2: portfolio di automation (take-home, 2-3 ore)

Piccolo progetto open-source. 4-6 test automatizzati nel loro framework.

Cosa valutare:

• Fluency framework: codice valido, eseguibile
• Struttura: indipendenti, leggibili, manutenibili
• Robustezza: wait, error handling, selector stabili
• Documentazione: spiegano l'approccio

Domanda chiave: "Se si rompe domani, come fai debug?"

Livello 3: processo e giudizio (live, 60 min)

"Abbiamo una suite di 2 ore. Tagliamola a 30 min. Cosa fai?" o "Feature lanciata in 2 settimane, il testing non è pronto. La tua giocata?"

Cosa misurare:

• Strategico (rischio, ROI) vs tattico
• Pushback senza scontro
• Contesto di business
• Articolano trade-off

Livello opzionale: code review

Hiring a scala

Bandiere rosse

• Sovra-automation
• Sotto-automation
• Assolutismo di framework
• Manca contesto
• Niente prioritizzazione

Test automation vs manual QA

Automation (80% codice): framework + struttura. Manual (80% strategia): test case, edge case.