Raportul de code coverage tocmai a apărut în Slack, trimis de un developer. Scrie undeva "87%" și toată lumea pare mulțumită. Tu, ca tester, te uiți la el și... ce faci cu el mai departe?
Dacă răspunsul e "îl dau mai departe fără să-l înțeleg", ai ajuns pe pagina potrivită. Code coverage nu este un număr magic — este o hartă. Și ca orice hartă, trebuie să știi s‑o citești ca să nu te rătăcești.
Ce înseamnă, de fapt, "acoperire a codului" — și de ce nu e același lucru cu "testare bună"
Code coverage măsoară ce procent din codul sursă al aplicației a fost executat în timpul rulării testelor automate. Există mai multe tipuri: line coverage (câte linii au rulat), branch coverage (câte ramuri logice — if/else — au fost parcurse), function coverage și statement coverage.
Un scor de 87% line coverage înseamnă că 13% din linii nu au rulat niciodată în teste. Poate sunt linii de tratare a erorilor, poate sunt funcționalități noi, poate sunt bucăți de cod mort. Nu știi până nu intri în raport.
Și tocmai aici stă capcana clasică: un cod acoperit 100% poate ascunde bug‑uri grave dacă testele verifică existența execuției, nu corectitudinea rezultatelor. Code coverage îți spune "testul a trecut pe acolo", nu "testul a verificat că rezultatul e corect". Sunt două lucruri complet diferite.
Cum arată un raport de code coverage și unde îl găsești
Cele mai comune tool‑uri care generează astfel de rapoarte sunt JaCoCo (pentru proiecte Java), Istanbul/NYC (pentru JavaScript/TypeScript), Coverage.py (pentru Python) sau funcționalitatea built‑in din framework‑uri precum pytest sau dotnet test. Raportul ajunge de obicei în pipeline‑ul de CI/CD — GitHub Actions, Jenkins, Azure DevOps — și poate fi vizualizat ca pagină HTML sau integrat direct în pull request‑uri.
Dacă nu ai acces direct, cere link‑ul sau exportul HTML de la colegii developers. Un raport HTML bun îți permite să navighezi fișier cu fișier, clasă cu clasă, și să vezi exact ce linii sunt colorate în verde (acoperite), roșu (neacoperite) sau galben (parțial acoperite — cazul branch‑urilor).
Instrumentele moderne de coverage se integrează și cu JIRA prin plugin‑uri de raportare sau direct în comentariile automate din pull request‑uri. Dacă echipa ta folosește SonarQube, acoperirea apare acolo agregat, alături de alte metrici de calitate.
Cum citești raportul ca tester, pas cu pas
Primul lucru: nu începe cu scorul global. Scorul global e media, și media minte. Un modul critic acoperit 30% și un modul de logging acoperit 100% pot da împreună un scor de 65% care pare rezonabil, dar ascunde un risc real.
Pasul 1 — identifică modulele de business. Caută în structura de fișiere clasele sau fișierele care corespund funcționalităților principale: autentificare, plăți, generare documente, calcule financiare. Acestea sunt zone cu risc ridicat și merită atenție mai mare decât utilitare interne.
Pasul 2 — verifică branch coverage, nu doar line coverage. O linie acoperită 100% care conține un if cu două ramuri, dar testele au atins doar ramura "happy path", înseamnă că jumătate din logică nu a fost testată. Branch coverage sub 70% în zone critice e un semnal de alarmă clar.
Pasul 3 — corelează zonele roșii cu testele tale manuale sau exploratorii. Dacă o funcționalitate pe care tu o testezi manual are acoperire automată scăzută, ai un argument concret să ridici un flag în echipă: "avem risc neacoperit automat în modulul X, merită să scriem un test sau să adaug eu mai multe scenarii exploratorii."
Pasul 4 — documentează observațiile într‑un test report sau direct în JIRA. Un comentariu de tipul "branch coverage pentru modulul de calcul TVA e 42%, am identificat scenariile neacoperite și le‑am adăugat ca test cases manuale" arată maturitate de QA și valoare concretă adusă echipei.
Greșeli frecvente pe care le fac testerii când citesc coverage
Greșeala numărul unu: să tratezi procentul ca pe un indicator de calitate absolut. Echipe care au rulat la DevTalks sau A4Q Summit prezentări despre qualitate au repetat același mesaj: "100% coverage with bad assertions is worse than 60% coverage with meaningful tests." Numărul fără context e zgomot.
Greșeala numărul doi: să ignori complet raportul pentru că "eu nu scriu cod". Fals. Tu ești cel mai bine plasat să corelezi acoperirea tehnică cu scenariile funcționale reale. Developerul știe ce a scris; tu știi ce face utilizatorul.
Greșeala numărul trei: să nu faci diferența între cod testat în unit tests și cod testat în integration tests sau end‑to‑end tests. Rapoartele de coverage agregate combină adesea toate nivelele. Un modul poate părea bine acoperit, dar doar cu unit tests care mock‑uiesc toate dependențele — comportamentul real în integrare rămâne netestat.
Cum transformi insights din raport în acțiuni concrete
Un raport de coverage devine util abia când generează o decizie. Câteva acțiuni practice pe care le poți face tu, ca tester, imediat după ce ai citit raportul:
- Adaugă test cases exploratorii pentru ramurile neacoperite identificate în zone critice.
- Propune în sprint planning dedicarea unui task de "test debt" pentru a acoperi modulele cu risc ridicat și acoperire scăzută.
- Creează în JIRA un label sau un epic de tip "coverage gap" pentru transparență cu echipa și cu managementul.
- Dacă lucrezi cu Selenium 4, Playwright sau Cypress și ai acces la teste end‑to‑end, verifică dacă tool‑ul de coverage include și execuțiile E2E sau doar unit tests — uneori trebuie configurată instrumentarea separat.
- Solicită o sesiune scurtă de pair review cu un developer pe raportul HTML — 30 de minute în care el îți explică arhitectura modulului și tu îi explici scenariile funcționale neacoperite. Schimbul ăsta de perspectivă valorează mai mult decât orice tool.
TL;DR — Ce să reții
Code coverage e o hartă, nu un verdict. Scorul global minte; uită-te la modulele critice și la branch coverage. Corelează zonele roșii cu scenariile funcționale pe care tu le cunoști. Transformă observațiile în acțiuni documentate. Și amintește-ți: un tester care înțelege rapoartele tehnice ale echipei este de zece ori mai valoros decât unul care se rezumă la a da click în aplicație.
Dacă vrei să înveți să navighezi cu încredere prin metrici de calitate, să înțelegi cum se construiesc pipeline‑uri de testare și să poți purta conversații egale cu developerii din echipa ta, te așteptăm la Academia Testarii. 🚀
Cursurile noastre acoperă atât fundamentele testării manuale cât și automatizarea cu Selenium, Playwright și Postman — cu exerciții hands‑on pe proiecte reale din domenii bancar, retail și energie. Profesia de Analist Testare Software are cod COR 351108 și o cerere în creștere constantă pe piața din România.
Intră pe academiatestarii.ro, explorează cursurile disponibile și fă primul pas spre o carieră în QA în care știi exact ce faci — și de ce. 📖
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestAutomation #QualityAssurance