Il miglior test QA per engineer di test automation: costruisci la tua valutazione

Cosa significa «migliore» per le valutazioni QA

Non esiste un singolo test QA che funziona per ogni assunzione. Ma esiste uno schema che funziona: una valutazione a più livelli che separa il pensiero sui test dalla velocità di codifica, il giudizio dalla conoscenza, l'architettura dalla sintassi.

Il miglior test QA non è il più difficile. È quello che rivela se la candidata manterrà una test suite per tre anni senza bruciarsi.

La struttura ideale della valutazione

Parte 1: design dei casi di test (scritto, 30–45 minuti)

Non negoziabile. È il primo filtro.

Dai alle candidate una spec di feature realistica — non «testa il login» (troppo vago), non «scrivi 100 casi di test» (troppo). Qualcosa nel mezzo: «Ecco una feature per importare in massa dati utente da CSV. Scrivi 8–12 casi di test che proporresti al tuo team».

Cosa valuti:

• Copertura: identifica i casi limite (file vuoto, 100k righe, caratteri speciali)?
• Chiarezza: qualcun altro può eseguire questi test senza chiamarla?
• Giudizio: prioritizza i casi critici o tratta tutto allo stesso modo?
• Realismo: riconosce i vincoli (setup dei dati, ambiente)?

Usa una rubrica: copertura 25 %, chiarezza 25 %, giudizio 25 %, fattibilità 25 %. Non è oggettività perfetta, ma è coerente.

Tempo di valutazione: 10–15 minuti per candidata.

Parte 2: codice di automazione (take-home, 2–3 ore)

Se passano la parte 1, mandale un take-home: «Ecco una sandbox app. Scegli 4–5 dei casi di test che hai appena progettato e automatizzali. Usa il framework che conosci».

Cosa valuti:

• Qualità del codice: leggibile, manutenibile, non troppo astuto?
• Fluidità nel framework: sintassi valida, asserzioni proprie, attese intelligenti?
• Robustezza: il test sopravvive a una piccola modifica UI o è fragile?
• Architettura: usano page object, data setup, teardown?

Non valutare sulla velocità. Una candidata che scrive 2 test solidi in 2,5 ore è più forte di una che ne scrive 8 frettolosi nello stesso tempo.

Cosa ignorare: se ha scelto Selenium o Cypress, se ha usato una specifica libreria. Sono preferenze. Conta la qualità del test.

Tempo di valutazione: 15–20 minuti. Cerca selettori che non si rompano, attese sensate, asserzioni che testano comportamento (non solo stato del DOM) e codice leggibile.

Parte 3: colloquio di processo live (60 minuti)

Qui brilla il giudizio. Prepara 2–3 scenari:

Scenario 1: «La tua suite di regressione dura 3 ore. Il team vuole tagliarla a 1 ora per sbloccare deploy più rapidi. Qual è la tua mossa?»

Scenario 2: «Un bug critico in produzione è sfuggito alla tua suite. È una race condition che capita 1 su 100. Spiegami la tua indagine.»

Scenario 3: «Una feature lancia tra 2 settimane. La copertura non è completa. Spedire senza copertura ci espone a rischio di perdita dati. Cosa proponi?»

Nessuno ha risposte giuste. Ascolta:

• Pone domande di chiarimento (dimensione del team, impatto utente, budget)?
• Sa articolare trade-off senza tergiversare?
• Pensa come un'engineer (rischio, ROI, manutenzione) o solo come una tester (copertura)?
• È onesta sui vincoli?

Tempo: 20 minuti per le domande, 10 per il loro ragionamento, 30 per follow-up e le loro domande.

Parte 4 (opzionale): esercizio di code review (30–45 minuti)

Se il tuo ruolo QA include il review di codice di test, aggiungi questa parte.

Fornisci una test suite con 3–5 problemi: un selettore flaky, gestione degli errori mancante, un test sovraffermato, una race condition setup/teardown. Chiedile di identificare i problemi e suggerire fix.

Cosa valuti:

• Sa leggere e criticare codice?
• Capisce le modalità di guasto?
• I suoi suggerimenti sono pratici o teorici?

Necessaria solo se il tuo team fa davvero review del codice di test.

Investimento di tempo totale

• Parte 1 (scritta): 45 min candidata, 10–15 min valutazione
• Parte 2 (take-home): 2–3 ore candidata, 15–20 min valutazione
• Parte 3 (live): 1 ora candidata, 30 min colloquio, 10 min note
• Parte 4 (opzionale): 30–45 min candidata, 10 min valutazione

Totale: 4–5 ore di tempo candidata, 1,5–2 ore di tempo recruiter/intervistatrice per candidata. Ragionevole per un'assunzione senior.

Screening prima della valutazione

Non mandare il take-home a tutte. Usa la parte 1 (design scritto dei casi di test) come screener.

Se non sanno progettare un caso di test coerente in 45 minuti, non scriveranno codice di automazione solido. Risparmia il take-home di 3 ore alle candidate che superano il round scritto.

Tasso di passaggio approssimativo: mira al 40–60 % delle submission scritte che avanzano al take-home. Se è molto più alto, la rubrica è troppo lasca. Se è inferiore, la spec potrebbe essere poco chiara.

Calibrazione del punteggio

Prima di assumere, calibra il team su cosa significa «bene».

Esegui la valutazione su 2–3 hire noti come buoni del tuo team. Come sono i loro casi di test? La qualità del codice? Usalo come standard di riferimento.

Poi esegui 2–3 hire noti come cattivi (persone che non hanno funzionato). Cosa era debole nelle loro submission? Anche quello spazio negativo conta.

Non stai cercando di essere perfettamente oggettiva. Stai cercando di essere coerente.

Quando saltare delle parti

Assunzione per un ruolo QA manuale (esplorativo, non automazione): salta parte 2 e parte 4. Concentrati su parte 1 (pensiero sui test) e parte 3 (giudizio).

Assunzione di un'engineer mid-level con portfolio verificato: potresti saltare parte 1 (design dei test) e andare direttamente a parte 2 (codice) e parte 3 (colloquio). Ma solo se hai già visto il suo codice reale.

Assunzione su scala, fase iniziale: inizia con solo parte 1 + parte 3 (salta il take-home). È più veloce. Una volta che il processo è stabile, aggiungi la parte 2 per i round finali.

Perché questa struttura batte le alternative

Meglio dei problemi stile leetcode: quelli testano la velocità di coding sotto pressione, non il pensiero sui test o l'architettura.

Meglio di un singolo colloquio di live coding: non puoi valutare la capacità di qualcuna di progettare test o mantenere codice in una sessione live di 60 minuti.

Meglio della sola review del portfolio: i portfolio sono curati. Una valutazione mostra la skill attuale, non il miglior lavoro di tre anni fa.

La struttura funziona perché separa il segnale. Il design dei test è diverso dalla qualità del codice che è diversa dal giudizio. Hai bisogno di tutti e tre.

Considerazione contraria: forse stai assumendo male

Alcuni team sostengono che dovresti assumere engineer forti che possono prendere in mano il testing, non specialiste che sanno solo fare testing.

È giusto se le tue engineer sono abbastanza forti. Ma engineer forti assunte per «fare anche QA» spesso non lo fanno. Il QA diventa un'attività che detestano. Finisci con test non manutenuti ed engineer bruciate.

Assumi persone che hanno scelto questa disciplina. La valutazione ti aiuta a trovarle.