Cel mai bun test QA pentru ingineri de automatizare a testelor: construiește-ți evaluarea

Ce înseamnă „cel mai bun" pentru evaluările QA

Nu există un singur test QA care să funcționeze pentru fiecare angajare. Dar există un tipar care funcționează: o evaluare multi-nivel care separă gândirea testelor de viteza de codificare, discernământul de cunoaștere și arhitectura de sintaxă.

Cel mai bun test QA nu e cel mai dificil. E cel care dezvăluie dacă un candidat va menține o suită de teste timp de trei ani fără să se ardă.

Structura ideală a evaluării

Partea 1: design de cazuri de test (scris, 30–45 de minute)

Nenegociabil. E primul filtru.

Dă candidaților o specificație realistă — nu „testează login-ul" (prea vag), nu „scrie 100 de cazuri de test" (prea mult). Ceva la mijloc: „Iată o funcționalitate de import în masă a datelor utilizatorilor din CSV. Scrie 8–12 cazuri de test pe care le-ai propune echipei tale".

Ce notezi:

• Acoperire: identifică cazuri-limită (fișier gol, 100k rânduri, caractere speciale)?
• Claritate: poate altcineva să execute aceste teste fără să-l sune?
• Discernământ: prioritizează cazurile critice sau tratează totul egal?
• Realism: recunoaște constrângerile (setup de date, mediu)?

Folosește o rubrică: acoperire 25 %, claritate 25 %, discernământ 25 %, fezabilitate 25 %. Nu e obiectivitate perfectă, dar e consecventă.

Timp de notare: 10–15 minute per candidat.

Partea 2: cod de automatizare (take-home, 2–3 ore)

Dacă trec partea 1, trimite-le un take-home: „Iată o aplicație sandbox. Alege 4–5 din cazurile de test pe care tocmai le-ai proiectat și automatizează-le. Folosește orice framework cunoști".

Ce notezi:

• Calitatea codului: lizibil, mentenabil, nu prea inteligent?
• Fluența framework-ului: sintaxă validă, asserts proprii, așteptări inteligente?
• Robustețe: va supraviețui testul unei mici schimbări UI sau e fragil?
• Arhitectură: folosește page objects, setup, teardown?

Nu nota pe viteză. Un candidat care scrie 2 teste solide în 2,5 ore e mai puternic decât unul care scrie 8 rapide.

Ce să ignori: dacă a ales Selenium sau Cypress, dacă a folosit o anume librărie. Sunt preferințe. Calitatea testului contează.

Timp de notare: 15–20 de minute. Caută: selectori care nu se vor strica, așteptări cu sens, asserts care testează comportament (nu doar starea DOM) și cod uman-lizibil.

Partea 3: interviu de proces live (60 de minute)

Aici strălucește discernământul. Pregătește 2–3 scenarii:

Scenariul 1: „Suita ta de regresie durează 3 ore. Echipa vrea s-o reducă la 1 oră ca să deblocheze deploy-uri mai rapide. Care e mișcarea ta?"

Scenariul 2: „Un bug critic de producție a fost ratat de suita ta de teste. E o condiție de cursă care apare 1 din 100. Spune-mi cum ai investiga".

Scenariul 3: „O funcționalitate se lansează în 2 săptămâni. Testarea nu e gata. Lansarea fără acoperire completă ne expune la risc de pierdere de date. Ce propui?"

Niciuna nu are răspuns corect. Asculți:

• Pune întrebări de clarificare (mărimea echipei, impact utilizator, buget)?
• Poate articula compromisuri fără ezitare?
• Gândește ca un inginer (risc, ROI, mentenanță) sau doar ca un tester (acoperire)?
• E onest despre constrângeri?

Timp: 20 de minute pentru întrebări, 10 minute pentru raționamentul lor, 30 de minute pentru follow-up și întrebările lor.

Partea 4 (opțional): exercițiu de code review (30–45 de minute)

Dacă rolul tău QA include revizuirea codului de teste, adaugă asta.

Furnizează o suită de teste cu 3–5 probleme: un selector flaky, lipsa gestionării erorilor, un test cu prea multe assertions, o condiție de cursă în setup/teardown. Cere-i să identifice problemele și să sugereze rezolvări.

Ce notezi:

• Poate citi și critica codul?
• Înțelege moduri de eșec?
• Sugestiile lui sunt practice sau teoretice?

Necesar doar dacă echipa ta chiar revizuiește codul de teste.

Investiția totală de timp

• Partea 1 (scris): 45 min timpul candidatului, 10–15 min notare
• Partea 2 (take-home): 2–3 ore timpul candidatului, 15–20 min notare
• Partea 3 (interviu live): 1 oră candidatul, 30 min interviu, 10 min note
• Partea 4 (opțional): 30–45 min candidatul, 10 min notare

Total: 4–5 ore timpul candidatului, 1,5–2 ore timpul recrutorului/intervievatorului per candidat. Rezonabil pentru o angajare senior.

Screening înaintea acestei evaluări

Nu trimite take-home-ul tuturor. Folosește partea 1 (designul scris al cazurilor de test) ca screener.

Dacă nu pot proiecta un caz de test coerent în 45 de minute, nu vor scrie cod de automatizare solid. Salvează take-home-ul de 3 ore pentru candidații care trec runda scrisă.

Rata de trecere aproximativă: țintește 40–60 % din submisiile scrise să avanseze la take-home. Dacă e mult mai sus, rubrica ta e prea îngăduitoare. Dacă e mai jos, specificația ta e neclară.

Calibrarea notării

Înainte să angajezi, calibrează echipa pe ce înseamnă „bine".

Rulează evaluarea pe 2–3 angajări cunoscute ca bune din echipă. Cum arată cazurile lor de test? Calitatea codului? Folosește asta ca standard de referință.

Apoi rulează 2–3 angajări cunoscute ca slabe (oameni care n-au funcționat). Ce era slab la submisiile lor? Acel spațiu negativ contează și el.

Nu încerci să fii perfect obiectiv. Încerci să fii consecvent.

Când să sari peste părți

Angajare pentru un rol QA manual (explorator, nu automatizare): sari peste părțile 2 și 4. Concentrează-te pe partea 1 (gândirea testelor) și partea 3 (discernământ).

Angajare a unui inginer mid-level cu portofoliu verificat: ai putea sări peste partea 1 (design de teste) și să mergi direct la partea 2 (cod) și partea 3 (interviu). Dar doar dacă i-ai văzut deja codul real.

Angajare la scară, fază timpurie: începe doar cu partea 1 + partea 3 (sări peste take-home). E mai rapid. Odată ce procesul e stabil, adaugă partea 2 pentru rundele finale.

De ce această structură bate alternativele

Mai bună decât probleme stil leetcode: acelea testează viteza de codare sub presiune, nu gândirea testelor sau arhitectura.

Mai bună decât un singur interviu de live coding: nu poți evalua capacitatea cuiva de a proiecta teste sau menține cod într-o sesiune live de 60 de minute.

Mai bună decât doar revizuirea portofoliului: portofoliile sunt selectate. O evaluare îți arată skill-ul lor curent, nu cea mai bună muncă de acum trei ani.

Structura funcționează pentru că separă semnalul. Designul de teste e diferit de calitatea codului care e diferită de discernământ. Ai nevoie de toate trei.

Contra-considerare: poate angajezi greșit

Unele echipe argumentează că ar trebui să angajezi ingineri puternici care pot prelua testarea, nu specialiști care știu doar testare.

E corect dacă inginerii tăi sunt suficient de puternici. Dar inginerii puternici angajați să „facă și QA" adesea n-o fac. QA devine o sarcină pe care o resping. Ajungi cu teste nemenținute și ingineri arși.

Angajează oameni care au ales această disciplină. Evaluarea te ajută să-i găsești.