Ai 6 ore până la release. Ai 80 de test case‑uri în backlog. Product owner‑ul te sună din 10 în 10 minute. Ce faci?
Dacă răspunsul tău e „încep de sus și merg în jos pe listă", atunci acest post e exact pentru tine. Risk‑based testing nu e un buzzword de conferință — e un mindset practic care separă testerul care livrează valoare de testerul care bifează căsuțe.
Ce înseamnă, de fapt, risk‑based testing?
Simplu: prioritizezi efortul de testare în funcție de probabilitatea că ceva se va strica și de impactul pe care l‑ar avea acel „ceva" în producție. Nu testezi totul la fel de adânc — testezi mai mult acolo unde miza e mai mare.
ISTQB definește riscul de produs ca o zonă din software cu potențial de eșec care poate afecta utilizatorii, businessul sau compania. Și fix asta e ghidajul tău: nu toate funcționalitățile sunt egale. Un bug în fluxul de plată dintr‑o aplicație de e‑commerce e cu totul altceva față de un bug în pagina „Despre noi".
Sună evident? Poate. Dar în practică, mai ales sub presiune, tocmai această ierarhie se pierde primul.
Matricea de risc: instrumentul pe care îl poți folosi de mâine
Cel mai rapid framework pe care îl poți aplica imediat e matricea probabilitate × impact. Arată cam așa:
- Probabilitate mare + Impact mare → testezi primul, aprofundat
- Probabilitate mică + Impact mare → testezi al doilea, dar nu sari peste
- Probabilitate mare + Impact mic → testezi dacă mai ai timp
- Probabilitate mică + Impact mic → documentezi că ai acceptat riscul și mergi mai departe
Concret: dacă lucrezi într‑un proiect bancar sau de asigurări, modulul de calcul al dobânzilor sau cel de generare a contractelor are probabilitate medie de regresie și impact uriaș dacă cedează. Ăla intră la prioritate maximă. Pagina de setări pentru notificări push? Mult mai jos pe listă.
Poți construi această matrice direct în JIRA, adăugând câmpuri custom pentru „Risk Level" și „Business Impact" pe fiecare story sau bug. Câteva ore de setup, săptămâni de claritate câștigate.
Cum identifici riscurile înainte să scrii primul test case
Greșeala clasică: aștepți să primești specificațiile, deschizi un doc gol și începi să scrii teste. Risk‑based testing începe mai devreme — în faza de analiză, uneori chiar în refinement.
Câteva tehnici hands‑on
- Interviuri cu stakeholderii: întreabă product owner‑ul și tech lead‑ul „Ce nu ți‑ai permite să se strice la acest release?" Răspunsul lor îți dă direct lista de risc înaltă.
- Analiza istoricului de bug‑uri: deschide JIRA, filtrează bug‑urile din ultimele 3‑6 sprint‑uri și uită-te unde s‑au concentrat. Modulele cu regresii frecvente sunt candidați clari la risc crescut.
- Hărți de dependențe: într‑un sistem cu bază de date relațională (MySQL, PostgreSQL), o modificare în tabela de utilizatori poate cascada în 7 alte module. Vizualizează aceste dependențe înainte să tai din scope.
- Complexitatea codului: dacă ai acces la metrici de cod, ciclomaticitatea ridicată e un semnal clar. Cu cât mai mulți branches, cu atât mai mare probabilitatea de surprize.
La A4Q Summit și la DevTalks, temele de risk‑based testing revin constant în sesiunile despre testare agilă — tocmai pentru că presiunea timpului e universal valabilă, indiferent de industrie.
Risk‑based testing în practică: un scenariu din retail
Imaginează-ți că lucrezi la o platformă de retail online care urmează să lanseze o nouă funcționalitate de voucher. Sprint‑ul durează 2 săptămâni, echipa de QA are 3 oameni și există deja 120 de test case‑uri pentru regresie generală, plus ~40 pentru feature‑ul nou.
Cu o abordare tradițională, echipa ar încerca să ruleze totul și ar eșua inevitabil — fie testând în grabă, fie depășind deadline‑ul.
Cu risk‑based testing
1. Identifică zonele de risc maxim: fluxul de aplicare a voucherului la checkout, validarea limitelor de utilizare per user, compatibilitatea cu promoțiile existente.
2. Marchează în JIRA fiecare test case cu un nivel de risc (High / Medium / Low).
3. Alocă 70% din capacitatea de testare pe categoria High, 20% pe Medium, 10% pe Low.
4. Documentează explicit ce a rămas netestat și de ce — asta nu e o scuză, e o decizie asumată, comunicată transparent.
Rezultatul? Bug‑urile cu impact real sunt prinse. Release‑ul iese. Echipa nu face ore suplimentare până la 2 noaptea.
Ce spune ISTQB și de ce contează pentru cariera ta
Risk‑based testing nu e un concept inventat de un influencer de LinkedIn. E unul din pilonii fundamentali ai ISTQB Foundation Level și apare detaliat în Advanced Level – Test Manager. Examenul te întreabă explicit cum prioritizezi testarea bazat pe risc, cum documentezi riscurile reziduale și cum revizuiești matricea de risc pe parcursul proiectului.
Dacă ești la început de drum, știind să aplici un framework de risk‑based testing de la primele tale proiecte, ieși din mulțimea de juniori care „știu Selenium 4 și Postman" și devii testerul care înțelege businessul. Iar asta se vede imediat în interviu.
Un #FunFact din experiența noastră la Academia Testarii: cursanții care înțeleg conceptele de risc și prioritizare primesc feedback pozitiv semnificativ mai rapid de la hiring manageri față de cei care listează doar tool‑uri în CV. Nu pentru că tool‑urile n‑ar conta — ci pentru că mindset‑ul de QA e ceea ce nu se poate citi dintr‑un tutorial de YouTube.
Nu toate riscurile se pot elimina — și asta e ok
Risk‑based testing nu promite zero bug‑uri în producție. Promite că, dacă ceva ajunge în producție, e un risc pe care l‑ai evaluat conștient, nu unul trecut cu vederea din lipsă de timp.
Riscul rezidual — ce rămâne netestat după ce ai epuizat bugetul de timp și resurse — trebuie documentat și comunicat. Într‑un proiect matur, un raport de risc rezidual e la fel de valoros ca un raport de bug‑uri. Îl poți construi simplu: o coloană în spreadsheet sau un câmp custom în JIRA, cu decizia luată și cine a aprobat‑o.
Transparența asta construiește încredere cu echipa de produs și cu managementul. Și, sincer, te protejează și pe tine ca tester.
---
Dacă vrei să înveți risk‑based testing nu doar la nivel teoretic, ci aplicat pe scenarii reale din industria românească — bancar, automotive, retail, energie — te așteptăm la cursurile și certificările de la Academia Testarii. 🎯
Explorează programa completă pe academiatestarii.ro și fă primul pas spre o carieră în QA în care știi nu doar *ce* testezi, ci și *de ce*.
#DeAziEstiTester #AcademiaTestarii #ISTQB #SoftwareTesting #QualityAssurance