Ai un pipeline CI/CD bine uns, o suită de teste Selenium 4 care rulează verde de trei săptămâni la rând și un dashboard Allure care arată impecabil. Și totuși, utilizatorul găsește un bug ridicol în prima zi de producție. Sună familiar?
Nu e o ironie a sorții. E o lecție despre limitele fundamentale ale automatizării testelor — și despre de ce Exploratory Testing rămâne, în 2025, cel mai puternic instrument pe care îl are un tester cu experiență.
TL;DR: Scripturile automate verifică ce știi deja că se poate strica. Exploratory Testing descoperă ce nu ți‑ai imaginat că se poate strica. Ai nevoie de ambele — dar mai ales de abilitatea să le combini inteligent.
Ce este, de fapt, Exploratory Testing — și ce nu este
Exploratory Testing nu înseamnă să dai click aleatoriu prin aplicație sperând că ceva se strică. Asta e testare haotică, nu exploratorie.
Definiția dată de Cem Kaner, care a popularizat conceptul, e mult mai precisă: este o abordare în care design‑ul testului, execuția lui și învățarea despre produs se întâmplă simultan. Tu, ca tester, iei decizii în timp real pe baza a ceea ce observi.
Diferența față de testarea scriptată e fundamentală. Un test case automatizat din Selenium sau Cypress știe exact ce să verifice și nu se abate niciodată de la script. Exploratory Testing trăiește tocmai din abateri.
De ce scripturile automate au orb structural
Un script automatizat este, prin natura lui, o înregistrare a trecutului. A fost scris pe baza unor cerințe cunoscute, a unor fluxuri anticipate, a unor date de test pe care cineva le‑a pregătit. El verifică dacă aplicația se comportă conform așteptărilor — nimic mai mult.
Bug‑urile cele mai periculoase, însă, apar tocmai acolo unde nimeni nu a avut așteptări. Câteva categorii pe care automatizarea le ratează aproape sistematic:
- Probleme de UX și flux cognitiv — un buton plasat confuz, un mesaj de eroare care derutează, un form cu tab order greșit. Niciun assert din Playwright nu validează dacă utilizatorul înțelege ce i se cere.
- Bug‑uri de stare combinatorie — ce se întâmplă dacă utilizatorul deschide același cont simultan pe mobile și desktop, face o tranzacție și imediat după schimbă limba interfeței? Combinații de genul acesta explodează exponențial și niciun test suite nu le acoperă pe toate.
- Comportament inconsistent în condiții de date reale — un câmp de adresă care acceptă caractere speciale în engleză, dar trunchiază numele cu diacritice (ș, ț, ă) e un bug clasic în aplicații românești bancare sau de retail. Scriptul tău de automatizare a folosit date de test cu "Ion Popescu", nu cu "Ștefănescu‑Grămadă".
- Degradare vizuală subtilă — un layout care se rupe la un anumit zoom level sau pe un font size de accesibilitate. Chrome DevTools te poate ajuta să depistezi manual aceste situații, dar niciun CI/CD nu le prinde automat fără investiție majoră în teste vizuale dedicate.
- Race conditions și timing issues — evenimente care se suprapun în milisecunde și produc stări inconsistente în baza de date MySQL. Le poți reproduce uman prin explorare, le e greu să le codifici într‑un script reproductibil.
Cum structurezi o sesiune de Exploratory Testing eficientă
Fără structură, explorarea devine haotica menționată mai devreme. Tehnica consacrată e Session‑Based Test Management (SBTM): definești o misiune clară (charter), explorezi timp limitat (45–90 de minute), documentezi ce ai testat, ce ai găsit și ce ai lăsat neacoperit.
Un charter bun arată simplu: "Explorează fluxul de checkout pe mobile pentru utilizatori cu coș de cumpărături mai mare de 10 produse, cu focus pe comportamentul la aplicarea codurilor de discount."
În timpul sesiunii, notezi totul în timp real — poți folosi JIRA cu un template de sesiune, un simplu document partajat sau tool‑uri dedicate precum exploratory testing add‑on‑urile din TestRail. Important e să capturezi nu doar bug‑urile, ci și întrebările ridicate și zonele de risc identificate.
La A4Q Summit și la DevTalks, un subiect care revine constant în discuțiile dintre testeri seniori este tocmai această combinație: automatizare pentru regresia de rutină, explorare pentru zonele de risc nou și pentru tot ce e ambiguu în cerințe.
Mindset‑ul care face diferența: testerul ca utilizator adversarial
Cel mai valoros asset în Exploratory Testing nu e un tool. Ești tu.
Mindset‑ul corect e cel al unui utilizator adversarial — cineva care încearcă activ să găsească situații în care aplicația se comportă neașteptat. Nu din rea‑voință, ci dintr‑o curiozitate structurată.
Câteva heuristici practice pe care le poți aplica imediat
- SFDIPOT (Structure, Function, Data, Interface, Platform, Operations, Time) — un framework de explorare care te asigură că nu uiți dimensiuni întregi ale aplicației.
- Testează la granițe și dincolo de ele: ce se întâmplă cu un câmp numeric dacă introduci text? Ce se întâmplă dacă trimiți un form de două ori rapid?
- Schimbă contextul: testează același flux pe o conexiune 3G simulată în Chrome DevTools, cu un utilizator fără drepturi depline, după o sesiune expirată.
- Urmărește logurile în timp real: un tester explorator cu acces la consolă și la logurile de backend găsește de trei ori mai repede cauza unui comportament ciudat.
Acest mindset se cultivă în timp — dar se cultivă deliberat. Nu vine automat din a executa test case‑uri toată ziua.
Exploratory Testing și automatizarea: nu e o competiție
Un tester matur nu pune Exploratory Testing contra automation. Le folosește pe amândouă strategic.
Automatizarea acoperă regresia — cele 300 de test case‑uri care verifică că ce a funcționat ieri funcționează și azi. Eliberează timp și energie umană pentru explorare, care e cognitiv costisitoare și nu se scalează cu copy‑paste.
Exploratory Testing alimentează automatizarea: bug‑urile descoperite prin explorare devin candidați pentru noi teste automate, mai ales dacă riscul de regresie e mare. E un ciclu virtuos, nu un conflict.
Într‑un proiect din domeniul energiei pe care l‑am analizat recent, o sesiune exploratorie de 90 de minute a descoperit un bug de concurență în modulul de facturare pe care o suită de peste 400 de teste automate Selenium 4 îl ratase complet timp de două luni. Cost de remediere în producție: considerabil. Cost de descoperire prin explorare: o sesiune și un charter bine scris.
Vrei să înveți să găsești bug‑urile pe care alții le ratează?
Exploratory Testing e una dintre abilitățile care separă un tester junior de unul cu adevărat valoros pe piață — și una dintre competențele evaluate în certificările ISTQB Foundation și avansate.
La Academia Testarii, pregătim testeri care știu să gândească, nu doar să execute scripturi. Dacă vrei să-ți dezvolți instinctul de tester, să înveți tehnici structurate de explorare și să te pregătești pentru o certificare recunoscută internațional, vizitează academiatestarii.ro și descoperă cursurile noastre actuale. 🚀
Primul pas e întotdeauna cel mai important — și de data asta, îl poți face azi. 😊
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestareSoftware #ISTQB