Ai primit vreodată întrebarea asta: „Cât durează testarea?" — și ai simțit că pământul se deschide sub tine? Nu ești singur. Estimarea este una dintre cele mai temute activități din QA, nu pentru că testerul nu știe să testeze, ci pentru că nimeni nu l‑a învățat cum să estimeze. Vestea bună: există tehnici clare, testate în timp, pe care le poți aplica chiar de mâine.
De ce estimăm greșit — și de ce nu e vina ta
Primul reflex când cineva îți cere o estimare este să spui primul număr care îți vine în minte. De obicei e prea mic, pentru că uiți să incluzi review‑ul documentației, pregătirea datelor de test, re‑testarea bug‑urilor fixate sau timpii de așteptare pentru un environment instabil. Psihologii numesc asta planning fallacy — tendința naturală de a fi optimiști legat de propriile planuri.
La asta se adaugă presiunea externă: un Product Owner care vrea livrarea în sprint‑ul curent, un manager care a promis deja clientului o dată. Într‑un astfel de context, multe echipe cad în capcana estimărilor „de complezență" — numere care mulțumesc pe toată lumea pe moment și dor pe toată lumea mai târziu.
Tehnicile pe care le descriem mai jos nu îți garantează că nu vei mai greși niciodată. Îți garantează că greșelile vor fi mai mici, mai rare și mai ușor de explicat.
WBS — Taie elefantul în bucăți
Work Breakdown Structure (WBS) este punctul de plecare pentru orice estimare serioasă. Principiul e simplu: nu poți estima un întreg pe care nu îl înțelegi, dar poți estima aproape orice dacă îl spargi suficient de fin.
Cum arată concret în QA? Pornești de la feature‑ul de testat — să zicem un modul de plăți într‑o aplicație de retail — și îl descompui ierarhic: analiza cerințelor, design test case‑uri, pregătirea datelor în MySQL, execuție manuală, execuție automată cu Selenium 4, logging bug‑uri în JIRA, re‑testare, raport final. Fiecare activitate devine un „pachet de lucru" cu un efort estimabil separat.
Avantajul imediat: când îți treci WBS‑ul prin față unui coleg sau lead, lacunele ies la suprafață instantaneu. „Ai inclus testarea pe mobile?" „Dar cei 3 brokeri de plată diferiți?" Punctul ochit, punctul lovit — nu poți uita ce ai scris negru pe alb.
PERT — Când o singură cifră nu e suficientă
PERT (Program Evaluation and Review Technique) rezolvă o problemă pe care WBS‑ul singur nu o poate rezolva: incertitudinea. Nu știm exact cât durează un task, știm că poate dura mai puțin sau mai mult.
Formula PERT lucrează cu trei estimări pentru fiecare pachet de lucru:
- O (Optimistic) — cel mai bun scenariu realist, totul merge strună
- M (Most Likely) — scenariul cel mai probabil
- P (Pessimistic) — ce se întâmplă dacă mediul crapă, cerințele se schimbă, colegul e în concediu
Estimarea PERT se calculează astfel: E = (O + 4×M + P) / 6
Ponderea mai mare dată scenariului „most likely" face ca rezultatul să fie mai echilibrat decât o medie simplă. Și mai există un bonus: deviatia standard — (P - O) / 6 — îți spune cât de riscantă este estimarea. Cu cât e mai mare, cu atât ai mai mult motiv să comunici un interval, nu un număr fix.
Un exemplu rapid: dacă estimezi un ciclu de regresie la O=3 zile, M=5 zile, P=11 zile, PERT îți dă E = (3 + 20 + 11) / 6 = 5,67 zile. Mult mai onest decât „5 zile" sau „o săptămână", nu?
Delphi Wideband — Inteligența colectivă bate instinctul individual
Delphi Wideband este tehnica preferată atunci când ai o echipă de cel puțin 3‑4 persoane cu experiențe diferite. Ideea centrală: nu există un singur expert care știe cel mai bine; există o conversație structurată care scoate la suprafață cunoașterea distribuită a grupului.
Cum funcționează:
1. Fiecare participant estimează independent, în scris, fără să vadă cifrele celorlalți.
2. Estimările se dezvăluie simultan — exact ca în Planning Poker, dacă ești familiar din Agile.
3. Cei cu valorile extreme (cel mai mic și cel mai mare număr) își explică raționamentul.
4. Se repetă rundele până când grupul converge sau acceptă conștient un interval.
Delphi Wideband este deosebit de valoroasă în domeniile în care Academia Testarii lucrează frecvent: bancar, automotive, energie — proiecte cu multă complexitate ascunsă și cu riscuri reglementare ridicate. Când un tester senior din automotive spune „P=15 zile" și un junior spune „P=4 zile", conversația care urmează este mai valoroasă decât orice spreadsheet.
La A4Q Summit și la DevTalks, estimarea corectă a efortului de testare apare constant pe agenda discuțiilor despre maturitate QA. Nu e o temă academică — este o competență care diferențiază un tester junior de un tester cu adevărat valoros pentru echipă.
Cum combini cele trei tehnici într‑un proces coerent
Tehnicile nu se exclud — se completează. Un workflow practic arată cam așa:
Pasul 1 — Folosești WBS ca să identifici toate activitățile. Nicio activitate neidentificată nu poate fi estimată.
Pasul 2 — Aplici Delphi Wideband pentru activitățile cu incertitudine mare sau cu care echipa are experiență variabilă. Ieșirea acestui pas sunt tripletele O/M/P pentru fiecare pachet de lucru.
Pasul 3 — Calculezi estimarea PERT per activitate și o agregezi la nivel de feature sau sprint. Suma estimărilor PERT îți dă efortul total; suma deviațiilor standard îți spune cât buffer să ceri.
Pasul 4 — Documentezi ipotezele. „Această estimare presupune că environment‑ul de test este stabil, că cerințele nu se vor schimba după kick‑off și că avem acces la datele de test în MySQL până joi." Ipotezele scrise sunt scutul tău când realitatea se abate de la plan.
Ce faci cu estimarea odată ce o ai
O estimare bună nu e un număr magic — e o conversație. Când prezinți cifrele stakeholder‑ilor, prezintă și intervalul de încredere: „Estimăm între 8 și 13 zile de efort, cu o valoare probabilă de 10 zile, ipotezele fiind X, Y, Z."
Urmărește apoi acuratețea estimărilor tale în timp. Câte ore ai estimat vs. câte ai consumat? JIRA îți poate scoate aceste date automat dacă logați timp consecvent. Echipele care fac acest review după fiecare sprint ajung, în general, la o acuratețe de estimare cu 30‑40% mai bună în 3‑4 cicluri.
Estimarea nu este o știință exactă, dar nici nu trebuie să fie un joc de ghicit. Este o abilitate care se antrenează — cu metode clare, cu feedback loop‑uri și cu curajul de a spune „nu știu suficient ca să estimez fără mai multă informație."
Dacă vrei să stăpânești nu doar estimarea, ci întregul set de competențe care fac dintr‑un tester un profesionist complet — de la test planning și risk‑based testing până la automatizare cu Selenium 4, Cypress sau Playwright — cursurile noastre de la Academia Testarii sunt locul potrivit. Avem programe pentru juniori care fac primul pas în QA, pentru medii care vor certificarea ISTQB și pentru seniori care pregătesc echipe întregi. Intră pe academiatestarii.ro, uită-te la oferta de cursuri și hai să estimăm împreună cât îți ia să devii testerul în care echipa ta poate avea încredere. 🚀
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestareSoftware #ISTQB