Sunt două ore până la release. Ai o listă cu 200 de test case‑uri și ai bifat 80. Ce faci?
Dacă răspunsul tău e "testez în ordine, de sus în jos" — citește mai departe. Dacă răspunsul tău e "depinde de risc" — citește oricum, că detaliile contează.
Risk‑based testing nu e o teorie academică frumoasă pe care o uiți după ISTQB. E exact tehnica pe care o aplici (conștient sau nu) de fiecare dată când alegi ce bug să raportezi primul sau ce modul să atingi înainte de orice altceva. Hai să facem procesul explicit, repetabil și — cel mai important — defensibil în fața unui tech lead sau a unui client nervos.
Ce înseamnă, de fapt, "risc" în testare?
În contextul risk‑based testing, riscul are o definiție precisă: probabilitatea că ceva să meargă prost, înmulțită cu impactul dacă acel ceva chiar merge prost.
Risc = Probabilitate × Impact
Sună simplu. Complicat e să estimezi onest ambele variabile. Probabilitatea crește când codul e nou, când a trecut printr‑un refactor recent, când dezvoltatorul e junior sau când feature‑ul a mai avut bug‑uri istorice. Impactul crește când zona afectată e vizibilă pentru utilizator, când implică date financiare, autentificare, sau când o eroare acolo poate produce un efect domino în tot sistemul.
Domenii ca bancar, automotive sau energie au un profil de risc complet diferit față de, să zicem, o pagină de blog. Nu că o pagină de blog nu contează — contează — dar o eroare în calculul unui credit sau în sistemul de frânare al unui vehicul autonom e altă poveste.
Matricea de risc: instrumentul tău de prioritizare
Cel mai practic punct de plecare e o matrice 3×3 sau 5×5 în care plasezi fiecare modul sau funcționalitate după probabilitate și impact. Arată cam așa:
- Impact mare + Probabilitate mare → testezi primul, necondiționat.
- Impact mare + Probabilitate mică → testezi al doilea; o dată ce ai confirmat că zona e stabilă, poți dormi liniștit.
- Impact mic + Probabilitate mare → util de automatizat și rulat în pipeline, nu neapărat prioritate manuală acum.
- Impact mic + Probabilitate mică → candidat pentru skip în sprint‑ul curent, cu documentare explicită a deciziei.
Documentarea deciziei e crucială. Dacă omiți ceva și apare un bug în producție, vrei să poți arăta că ai luat o decizie informată, nu că ai uitat.
În practică, această matrice o construiești cu echipa — nu singur. Implică dev‑ul care a scris codul, product owner‑ul care știe ce e critic pentru client, și dacă lucrezi în automotive sau retail, poate și un domain expert. O sesiune de 30 de minute cu oamenii potriviți valorează mai mult decât două ore de estimat singur.
Cum aduni datele pentru a estima riscul corect
Matrices sunt inutile dacă datele din ele sunt inventate. Surse reale de informație:
Istoricul de bug‑uri din JIRA. Câte defecte au apărut în modulul X în ultimele 3 sprint‑uri? Dacă modulul de autentificare a generat 12 bug‑uri în 6 săptămâni, probabilitatea că mai are probleme e mai mare decât zero, indiferent ce spune cineva la standup.
Complexitatea codului. Code coverage, cyclomatic complexity, numărul de dependențe. Nu trebuie să fii developer să ceri aceste cifre — trebuie doar să știi că există și să le folosești ca semnal.
Schimbările recente. Un modul atins în ultimele 48 de ore e mai riscant decât unul neatins de 3 luni. Git log e prietenul tău.
Feedback din mediul de producție. Dacă ai acces la logs, la monitorizare sau la rapoarte de la support, ele îți spun unde utilizatorii reali au dureri chiar acum.
La A4Q Summit sau la sesiunile DevTalks, practicienii cu experiență în domenii reglementate — bancar, pharma, automotive — vorbesc constant despre cât de mult contează această fază de analiză. Nu improvizezi riscul; îl măsori.
Risk‑based testing în ciclul tău zilnic de muncă
Teoria e frumoasă, dar cum arată asta într‑o zi obișnuită de QA?
Dimineața, când primești task‑urile de testat, înainte să deschizi Selenium 4 sau să scrii primul test în Playwright sau Cypress, pune-ți două întrebări: "Ce se întâmplă dacă X nu funcționează?" și "Cât de probabil e să nu funcționeze?". Răspunsurile îți ordonează lista.
Când construiești un regression suite automatizat, nu automatiza totul egal. Testele pentru fluxul de plată, autentificare sau generare de rapoarte merită să ruleze la fiecare push în pipeline. Testele pentru o pagină de setări accesată de 2% dintre utilizatori pot rula o dată pe zi sau o dată pe săptămână.
Când comunici cu echipa, exprimă riscul în termeni de business, nu de testare. Nu "am găsit un bug în modulul de checkout" — ci "există o eroare care blochează finalizarea comenzii pentru utilizatorii cu adrese de livrare din afara țării; impactul estimat e X% din tranzacțiile zilnice". Asta e o conversație pe care un manager o înțelege și acționează.
Postman îți poate valida că API‑urile critice returnează răspunsurile corecte înainte să ajungi la UI. Chrome DevTools îți arată ce se întâmplă în rețea și unde se pierd cereri. Dacă lucrezi cu baze de date, o interogare simplă în MySQL îți confirmă că datele persistă corect după un flux critic. Toate acestea sunt verificări rapide, cu risc mare acoperit, timp mic investit.
Când risk‑based testing îți salvează releases‑ul — și reputația
Am auzit varianta asta de nenumărate ori de la cursanții noștri: "Nu știam de ce testez în ordinea asta, o făceam din instinct." Risk‑based testing transformă instinctul în metodă. Iar metoda e ce poți prezenta, justifica și îmbunătăți.
Un tester care intră într‑o sesiune de planificare și spune "propun să prioritizăm modulul de facturare pentru că a avut 7 bug‑uri în ultimele două sprint‑uri și orice eroare acolo blochează întregul flux de revenue" e un tester cu care echipa vrea să lucreze. Nu e magie — e risk‑based thinking aplicat clar.
Și da, există situații în care, chiar și cu cea mai bună prioritizare, un bug scapă în producție. Documentarea deciziilor tale de risc e ceea ce face diferența între "nu ai testat bine" și "am luat o decizie informată, documentată, bazată pe datele disponibile, și iată ce facem diferit data viitoare". Prima variantă te costă credibilitate. A doua o construiește.
Vrei să faci din asta o competență solidă, nu doar un instinct?
Risk‑based testing e parte integrantă din curricula ISTQB Foundation Level și din programele avansate pe care le predăm la Academia Testarii. Dacă ești la început de drum sau vrei să-ți structurezi mai bine gândirea de QA, cursurile noastre sunt construite exact pentru contextul pieței românești — cu exemple din retail, bancar, automotive și energie, nu din manuale traduse mot-à-mot.
Intră pe academiatestarii.ro, explorează cursurile disponibile și află cum poți obține o certificare recunoscută internațional — inclusiv prin programele A4Q pe care le susținem. Primul pas e întotdeauna cel mai greu. Restul vine de la sine. 🚀
#DeAziEstiTester #AcademiaTestarii #ISTQB #RiskBasedTesting #SoftwareTesting