Ai executat toate test case‑urile din plan, totul e verde, echipa e mulțumită. Și totuși, la două zile după release, un utilizator găsește un crash care blochează complet fluxul de plată. Sună familiar? Nu ești singurul. Și nu, nu e vina ta că planul de test nu l‑a prins — e pur și simplu limitarea oricărui script scris dinainte. Exact pentru asta există exploratory testing‑ul cu sesiuni charter.
Ce este, de fapt, exploratory testing cu charter — și de ce nu e „testare la întâmplare"
Există un mit persistent: exploratory testing înseamnă să deschizi aplicația și să dai click pe unde îți vine chef. Greșit. Asta e clicking around, nu exploratory testing.
Exploratory testing‑ul structurat cu sesiuni de tip charter înseamnă că înainte să pornești, definești un charter — o propoziție concisă care stabilește scopul sesiunii tale. Ceva de genul: „Explorează comportamentul formularului de checkout atunci când utilizatorul schimbă metoda de plată în mijlocul sesiunii pe conexiune mobilă slabă." Ai o misiune clară. Ai o durată fixată (de obicei 60‑90 de minute). Ai un debriefing la final.
James Bach și Michael Bolton au formalizat această abordare prin SBTM (Session‑Based Test Management), iar azi e considerată una dintre cele mai mature tehnici de testare manuală — recunoscută explicit și în curriculum‑ul ISTQB Advanced Level Test Analyst.
Anatomia unui charter bine scris
Un charter slab sună așa: „Testează modulul de plăți." Un charter bun are trei componente:
- Target: Ce anume explorezi? (ex: câmpul de introducere a codului promoțional)
- Informație de acoperit: Ce vrei să afli? (ex: comportamentul la caractere speciale, la coduri expirate, la aplicarea multiplă)
- Riscuri de investigat: Ce ar putea merge prost? (ex: prețul final afișat diferit față de cel calculat în backend)
Când scrii charter‑ul înainte de sesiune, nu mai testezi „la întâmplare" — testezi cu intenție. Iar intenția e exact ce lipsea din planul de test inițial, pentru că planul acoperă scenariile cunoscute, nu pe cele descoperite prin curiozitate.
Un truc pe care îl folosim în sesiunile practice din Academia Testarii: formulează charter‑ul ca o întrebare. „Ce se întâmplă dacă utilizatorul are cont deschis simultan pe trei dispozitive și finalizează comanda de pe toate trei în interval de 10 secunde?" Întrebările bune generează bug‑uri critice. Afirmațiile generează confirmări.
Cum structurezi o sesiune de 90 de minute ca să maximizezi descoperirile
Împarte sesiunea în trei blocuri, cu proporții aproximative
Primele 15 minute sunt pentru setup și orientare. Deschizi aplicația, notezi versiunea, mediul (staging vs. producție), tool‑urile active — Chrome DevTools dacă testezi web, Postman dacă interceptezi request‑uri, JIRA deschis în tab separat pentru a loga bug‑urile instant. Nu începi să testezi serios în această etapă; pur și simplu te familiarizezi cu teritoriul.
Urmează 60 de minute de explorare activă. Urmărești charter‑ul, dar nu ești sclav al lui. Dacă descoperi ceva interesant tangențial, notezi rapid și revii. Tehnica se numește „tour": poți face un „Money Tour" (urmărești tot ce ține de bani și tranzacții), un „Landmark Tour" (testezi funcționalitățile principale în ordine neașteptată) sau un „Saboteur Tour" (încerci să strici intenționat fluxul). Alegi turul în funcție de charter.
Ultimele 15 minute sunt pentru debriefing și documentare. Notezi: câte bug‑uri ai găsit, câte charter‑uri noi au apărut din explorare, ce zone au rămas neacoperite. Dacă lucrezi în echipă, debriefing‑ul se face împreună — de preferat față în față sau pe video, nu doar prin JIRA.
Unde găsești bug‑urile critice pe care planul nu le‑a anticipat
Experiența noastră din cursurile hands‑on de la Academia Testarii, confirmată și de ce se discută la conferințe precum DevTalks sau A4Q Summit, arată că bug‑urile critice neașteptate se ascund aproape întotdeauna în aceleași tipuri de zone:
- Interacțiunile dintre module. Planul de test testează modulele separat. Bug‑urile critice apar la granița dintre ele: ce face sesiunea de autentificare când modulul de coș de cumpărături expiră simultan?
- Stări intermediare și tranziții. Nimeni nu testează ce se întâmplă dacă utilizatorul apasă „Înapoi" exact în momentul în care serverul procesează plata. Exact acolo se ascund crash‑urile.
- Date reale vs. date de test. Testezi cu „test@test.com" și „Parola123". Utilizatorul real are un email cu apostrof în numele de domeniu sau o parolă cu emoji. MySQL poate să se comporte surprinzător cu anumite encodinguri.
- Comportamente dependente de context. Rezoluții neobișnuite, browsere mai vechi, conexiuni lente, drepturi de acces la jumătate între roluri. Selenium 4 îți permite să simulezi unele dintre acestea, dar imaginația unui tester bun depășește orice script.
#FunFact: Într‑un studiu intern pe care l‑am analizat la un workshop, 3 sesiuni de exploratory testing de câte 90 de minute au descoperit mai multe bug‑uri de severitate „Critical" sau „Major" decât 200 de test case‑uri automate rulate săptămânal. Nu pentru că automatizarea e proastă — ci pentru că automatizarea confirmă ce știi deja, iar exploratory testing‑ul descoperă ce nu știai că nu știi.
Cum integrezi sesiunile charter într‑un sprint Agile fără să deranjezi nimeni
Cea mai frecventă obiecție: „Nu am timp de exploratory testing, avem sprint de două săptămâni." Înțeleg. Dar o sesiune charter durează 90 de minute, nu trei zile.
Recomandarea practică: alocă minim două sesiuni charter per sprint, una la mijloc (când feature‑ul e suficient de stabil) și una înainte de release. Documentează-le sumar în JIRA ca un task separat cu eticheta „Exploratory Session" și atașează nota de debriefing. Product owner‑ul vede activitate, echipa vede valoare, iar tu ai acoperire pentru conversațiile dificile după un bug de producție.
Dacă echipa e la început cu această practică, începe simplu: un charter, o sesiune, un debriefing de 10 minute. Rezultatele vorbesc singure — de obicei după prima sesiune, toată lumea vrea să continue.
Vrei să pui în practică tot ce ai citit aici?
La Academia Testarii predăm exploratory testing nu ca teorie abstractă, ci ca tehnică aplicată — cu charter‑uri reale, sesiuni simulate pe aplicații cu bug‑uri injectate intenționat și debriefing‑uri ghidate de traineri cu experiență în domenii precum bancar, retail și automotive.
Dacă te pregătești pentru certificarea ISTQB Foundation sau Advanced, vei regăsi aceste concepte direct în syllabus — și le vei înțelege cu totul altfel după ce le‑ai trăit hands‑on.
Aruncă un ochi pe cursurile noastre la academiatestarii.ro și vezi ce sesiune se potrivește cu nivelul și obiectivele tale acum. Primul pas e mai mic decât crezi — și merită făcut. 🚀
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestareSoftware #ISTQB