Ai aplicat la primul tău job de QA, sau poate cauți o schimbare de echipă. CV‑ul a trecut de filtru, ai primit invitația la interviu — și acum creierul tău rulează cel mai stresant test de regresie posibil: *oare ce mă întreabă?*
Spoiler: nu te întreabă ce crezi tu că te întreabă.
Am strâns mai jos 15 întrebări care apar frecvent în interviurile pentru roluri de testare software din România — de la posturi junior la roluri mid‑level — împreună cu capcanele ascunse și cu tipul de răspuns care îl face pe intervievator să noteze "de reținut" în loc de "următorul".
TL;DR: Interviurile de QA testează logica, nu memoria. Răspunsurile structurate, exemplele concrete și onestitatea față de ce nu știi contează mai mult decât recitarea definițiilor din ISTQB.
---
De ce interviurile de QA sunt diferite față de ce te aștepți
Mulți candidați vin pregătiți cu definiții perfecte: *"un test case este un set de condiții..."*, *"bug‑ul este o neconformitate față de cerințe..."*. Recrutorul le știe. Și el. Ce caută, de fapt, este să înțeleagă cum gândești când ceva nu funcționează cum ar trebui.
Un hiring manager dintr‑o companie de software din București mi‑a spus odată că elimină candidații nu când nu știu un tool, ci când nu pot explica *de ce* ar folosi un tool în locul altuia. Mindset‑ul de tester se vede în detalii mici — în felul în care pui întrebări, nu în cel în care reciti răspunsuri.
---
Întrebările de bază — și unde greșesc cei mai mulți
1. *Care e diferența dintre verification și validation?*
Capcana: răspunzi cu definiția din manual și te oprești. Adaugă un exemplu concret: "Verification înseamnă că am construit produsul corect — de exemplu, codul respectă specificația. Validation înseamnă că am construit produsul potrivit — adică utilizatorul real poate face ce și‑a propus."
2. *Ce este un test case și ce elemente conține?*
Așteptarea ascunsă: să menționezi precondițiile, pașii, datele de test, rezultatul așteptat și rezultatul actual. Mulți uită precondițiile — și exact acolo se nasc bug‑urile intermitente.
3. *Explică diferența dintre severity și priority.*
Capcana clasică: să le confunzi sau să le tratezi ca sinonime. Un bug cu severity mare (aplicația crează) poate avea priority mică dacă afectează 0,1% din utilizatori. Dă un exemplu din banking sau retail — domenii unde intervievatorii din România se simt acasă.
4. *Ce este regression testing și când îl aplici?*
Răspunsul diferențiator: menționează că regression testing nu înseamnă să retestezi tot — ci să identifici ariile de risc afectate de o modificare. Adaugă că în proiectele cu Selenium 4 sau Playwright poți automatiza suita de regresie și o integrezi în pipeline‑ul CI/CD.
5. *Cum prioritizezi test case‑urile când timpul e limitat?*
Aceasta este o întrebare de risk‑based testing. Răspunsul corect invocă criteriile de risc: probabilitate, impact, vizibilitate pentru utilizator. Evită să spui "le fac pe toate" — nu e credibil și nici măcar dezirabil.
---
Întrebările tehnice — tool‑uri și scenarii practice
6. *Ai lucrat cu JIRA? Cum gestionezi un bug report?*
Nu ajunge să spui "da, am folosit JIRA". Descrie câmpurile pe care le completezi — summary clar, steps to reproduce, expected vs. actual result, environment (browser, OS, versiune), severity, attachment cu screenshot sau log. Completitudinea unui bug report spune mai mult despre un tester decât orice certificare.
7. *Cum testezi un câmp de input pentru o sumă bancară?*
Aceasta este o întrebare de boundary value analysis și equivalence partitioning. Menționează valori valide, valori la limită (0, suma maximă), valori invalide (litere, caractere speciale, câmp gol, valori negative). Candidații buni adaugă și scenarii de securitate — SQL injection, XSS.
8. *Ai experiență cu testarea API? Ce tool‑uri ai folosit?*
Postman rămâne standardul de facto în România. Dacă ai folosit și REST Assured sau ai scris colecții cu variabile de environment în Postman, spune‑o explicit. Menționează că verifici nu doar status code‑ul 200, ci și structura răspunsului, timpii de răspuns și comportamentul la erori (4xx, 5xx).
9. *Cum ai testa o bază de date după un import de date?*
MySQL sau PostgreSQL apar frecvent în context. Răspunsul matur include verificarea numărului de înregistrări, integritatea cheilor foreign, valorile null acolo unde nu ar trebui să existe și consistența față de sursa originală.
10. *Ce este un flaky test și cum îl tratezi?*
Un flaky test trece uneori și pică alteori fără modificări de cod. Candidații care au întâlnit asta în practică menționează cauzele frecvente: dependențe de timp (sleep‑uri hardcodate), stare partajată între teste, date de test inconsistente. Soluția nu e să îl ignori — e să îl izolezi, să identifici cauza și să îl stabilizezi sau să îl marchezi explicit ca instabil.
---
Întrebările comportamentale — unde se câștigă sau se pierde interviul
11. *Povestește‑mi despre un bug important pe care l‑ai găsit.*
Structurează cu metoda STAR (Situation, Task, Action, Result). Fii specific: ce proiect, ce feature, cum ai descoperit bug‑ul, care a fost impactul. Dacă ești junior și nu ai experiență profesională, folosește un exemplu din proiectul de practică sau din cursul de testare.
12. *Cum gestionezi un conflict cu un developer care nu acceptă un bug?*
Răspunsul diferențiator: nu faci escaladare imediată, nu cedezi fără argumente. Explici că documentezi clar, aduci dovezi (screenshot, log, steps to reproduce), înțelegi perspectiva developerului și implici product owner‑ul dacă e nevoie. Colaborarea bate confruntarea.
13. *Ce faci când cerințele sunt neclare sau lipsesc?*
Un tester bun pune întrebări înainte să scrie test case‑uri. Menționează că înregistrezi întrebările, implici analistul de business sau product owner‑ul și documentezi răspunsurile. Testarea fără cerințe clare este testarea orbului — o spui exact așa.
14. *Unde te vezi în 2 ani în cariera de QA?*
Evită răspunsurile vagi. Fii concret: vrei să te specializezi în test automation cu Playwright sau Cypress, vrei să obții certificarea ISTQB Foundation sau Advanced, vrei să contribui la construirea unui framework de la zero. Ambiția structurată impresionează mai mult decât entuziasmul difuz.
15. *De ce vrei să lucrezi în testare software?*
Capcana: "pentru că îmi place să găsesc bug‑uri". Sună superficial. Răspunsul matur vorbește despre calitate, despre responsabilitatea față de utilizatorul final, despre curiozitatea de a înțelege cum funcționează un sistem și de a‑l împinge la limite. Dacă ai venit dintr‑un alt domeniu, spune ce te‑a atras specific — uneori tocmai perspectiva de outsider e cel mai mare atu.
---
Ce mai contează, dincolo de răspunsuri
Interviurile de QA bune sunt conversații, nu examene orale. Pregătește și tu 2‑3 întrebări pentru intervievator: cum arată procesul de QA în echipă, ce tool‑uri folosesc, cum e colaborarea cu developerii. Întrebările tale spun la fel de mult ca răspunsurile tale.
O ultimă observație practică: la evenimentele din comunitatea locală — DevTalks, A4Q Summit, meetup‑uri de QA — vei întâlni oameni care au dat sau au luat exact aceste interviuri. Rețeaua contează, dar contează și să ai ceva concret de arătat: un curs finalizat, o certificare, un proiect personal documentat pe GitHub.
---
Dacă vrei să ajungi la interviu cu mai mult decât speranță, Academia Testarii îți oferă cursuri hands‑on care acoperă exact ce testează recrutorii: de la manual testing și bug reporting corect până la test automation cu Selenium, Playwright și Postman. Peste 119 cursanți și‑au schimbat cariera alături de noi — poate ești tu următorul.
Explorează cursurile disponibile pe academiatestarii.ro și fă primul pas înainte ca altcineva să o facă înaintea ta. 🚀
#DeAziEstiTester #AcademiaTestarii #TestareSoftware #SoftwareTesting #QualityAssurance