Sprint‑ul se termină vineri. Backlog‑ul e plin. Product Owner‑ul vrea demo luni dimineață. Și tu, undeva între standup și retro, realizezi că n‑ai scris nicio linie de strategie de testare.
Sună familiar?
Dacă lucrezi în Agile — și tot mai multe echipe din România o fac, fie în banking, fie în automotive, fie în retail sau energie — știi că documentația clasică de testare se lovește de un zid dur: timpul. Un Test Plan de 40 de pagini nu supraviețuiește până la al doilea sprint.
Dar asta nu înseamnă că testezi haotic. Înseamnă că testezi altfel. Strategia de testare în Agile există — e doar mai ușoară, mai vie și mai puțin birocratică. Hai să o construim împreună.
Ce înseamnă, concret, o strategie de testare în Agile
O strategie de testare nu este un document. Este un set de decizii conștiente despre cum, ce și cât testezi. În Agile, aceste decizii trebuie luate rapid, revizuite des și comunicate scurt.
Gândește‑te la ea ca la un GPS recalibrat după fiecare sprint, nu ca la o hartă imprimată înainte de călătorie.
Trei întrebări îți structurează orice strategie, indiferent de framework
- Ce riscuri apar dacă funcționalitatea asta merge prost în producție?
- Ce tip de testare acoperă cel mai eficient riscul respectiv (manual, automat, exploratoriu)?
- Cine face ce și până când?
Dacă ai răspuns la cele trei întrebări înainte de fiecare sprint, ai o strategie. Nu e poetică, dar e funcțională.
Ce poți simplifica fără remușcări
Documentația clasică ISTQB vine cu artefacte bogate: Test Policy, Master Test Plan, Test Design Specification, Test Summary Report. Toate au valoarea lor — mai ales în proiecte reglementate, cum ar fi sistemele bancare sau medicale. Dar în Agile pur, le poți reduce dramatic.
Ce simplifici
- Test Plan‑ul devine o pagină sau chiar o secțiune în Confluence sau Notion. Conține scopul, abordarea, tool‑urile folosite (Selenium 4, Playwright, Postman, JIRA) și criteriile de exit pentru sprint. Atât.
- Test case‑urile pot trăi ca criterii de acceptare directe pe user story, scrise în format Given‑When‑Then. Nu ai nevoie de un document separat dacă echipa înțelege și respectă formatul.
- Rapoartele de testare se rezumă la un comentariu pe ticket în JIRA și la 2‑3 slide‑uri pentru demo. Nu ai nevoie de PDF cu 15 secțiuni.
- Matricea de trasabilitate o poți înlocui cu etichete (labels sau components) în JIRA care leagă test case‑urile de cerințe. Nu e perfectă, dar e live și actualizabilă în timp real.
Simplificarea nu înseamnă neglijență. Înseamnă că alegi artefacte care aduc valoare, nu artefacte care bifează un proces.
Ce păstrezi — și de ce contează
Chiar și cel mai rapid sprint are nevoie de câteva ancore ferme. Astea nu se negociază:
Criteriile de acceptare clare înainte de development. Dacă testerul citește user story‑ul abia când branch‑ul e gata pentru review, e prea târziu. Implicarea QA în rafinament (refinement) nu este opțională — este locul unde prinzi 40‑50% din bug‑urile potențiale înainte să existe cod.
O abordare risk‑based conștientă. Nu toate funcționalitățile merită același efort de testare. O funcție de căutare simplă și un modul de plată online nu stau pe același nivel de risc. Prioritizează explicit — și documentează decizia, chiar și într‑un bullet point.
O suită de regression testing automată. Aceasta este ancora întregii strategii Agile. Fără ea, fiecare sprint devine un hazard: ce ai livrat săptămâna trecută poate fi stricat de ce livrezi azi. Un smoke test automatizat care rulează la fiecare commit în pipeline salvează ore de investigație manuală și nopți nedormite înainte de release.
Exploratory testing structurat. Chiar dacă ai automatizare, mintea umană prinde comportamente pe care niciun script nu le anticipează. Reservă cel puțin 20% din capacitatea de testare manuală pentru sesiuni exploratorii cu time‑box (45‑60 de minute, charter clar, note rapide).
Ce nu poți sări niciodată, indiferent de viteză
Există trei lucruri pe care viteza sprint‑ului nu le justifică să le omit. Niciodată.
1. Testarea la nivel de acceptance (UAT sau echivalent). Cineva din business sau un proxy al utilizatorului final trebuie să valideze că software‑ul face ce trebuie să facă, nu doar că funcționează tehnic. Un bug găsit de client în producție costă de 10 până la 100 de ori mai mult decât unul găsit în sprint.
2. Revizia criteriilor de ieșire (exit criteria). Înainte să marchezi un sprint ca Done, trebuie să existe o definiție clară a lui Done din perspectivă QA. Nu "am testat și pare ok", ci: bug‑urile critice și majore sunt închise, regression‑ul automat este verde, test coverage‑ul pentru noile funcționalități atinge pragul agreat de echipă.
3. Comunicarea riscurilor neacoperite. Dacă dintr‑un motiv sau altul (timp, resurse, complexitate tehnică) nu ai putut testa ceva, spune‑o explicit. Nu în email, nu pe Slack, ci în mod formal — în board, în retro, în demo. O echipă care știe că a livrat cu un risc neacoperit poate lua decizii informate. O echipă care presupune că totul e testat, nu poate.
Cum arată o strategie minimă, dar solidă, pentru un sprint de două săptămâni
Zilele 1‑2 (Planning): identifici riscurile pe user story‑uri noi, stabilești ce se testează automat și ce manual, confirmi criteriile de acceptare.
Zilele 3‑8 (Execuție): testezi în paralel cu development‑ul, raportezi bug‑urile în JIRA cu pași clari de reproducere, actualizezi suita automată cu noile scenarii.
Zilele 9‑10 (Stabilizare): rulezi regression‑ul complet, faci o sesiune exploratoriu de 45 de minute pe funcționalitățile noi, confirmi exit criteria.
Ziua 10 (Demo + Retro): prezinți ce ai testat, ce riscuri rămân deschise, ce îmbunătățești în sprint‑ul următor.
E simplu pe hârtie. E greu în practică fără disciplina și mentalitatea potrivite — și fără o bază solidă de cunoștințe QA.
Strategia se învață. Mentalitatea, mai ales.
La A4Q Summit și DevTalks, un subiect revine obsesiv în discuțiile dintre testerii seniori: nu tool‑urile lipsesc în echipele tinere, ci framework‑ul de gândire. Știi să scrii un test case în Playwright, dar știi să decizi când nu merită să-l scrii?
Aceasta este diferența dintre un tester care execută și un tester care contribuie la calitate.
Dacă vrei să construiești acest framework de gândire pe baze solide — cu metodologie ISTQB, cu exemple din proiecte reale din România și cu mentori care au testat în Agile, nu doar despre el — te așteptăm la Academia Testarii.
Explorează cursurile și certificările disponibile pe academiatestarii.ro 🎯 Fie că ești la primul sprint sau la al o sutălea, există mereu un nivel următor.
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestareSoftware #ISTQB