În ultima vreme am auzit/văzut în diferite contexte(grupuri, meetinguri…) subiectul Exploratory Testing despicat ca “firul în patru”. Targetul meu pentru acest articol e un rezumat – util, sper al ideilor primite, însușite, testate de către mine.
Am tot ascultat dialoguri și monologuri legate de exploratory fie ele pro, fie contra. Urmărind un parcurs firesc al unei aplicații o să încerc să creionez și să subliniez câteva dintre argumente.
Exploratory testing e în principal testarea pe care o faci evitând urmărirea și executarea unor testcase-uri deja scrise. Exploratory presupune să înveti produsul, să creezi și să corelezi o suită de teste cu o suită de date, în cele din urmă să le execuți. Toate acestea într-un singur om, în aceelași timp și într-o maniera mai degajată, consider eu.
Să vedem… Ca să o luam de la început, am primit o aplicație pe care trebuie să o demonstrăm fie ca e bună, fie că e ne-bună. Aici se pare că opiniile variază destul de mult în funcție de orizontul fiecăruia. Discuția, evident, e una mai complexă și adevărul e de cele mai multe ori la mijloc. De data aceasta voi merge pe varianta în care demonstrăm că aplicația noastră nu e cea mai bună.
Și cum bug-urile sunt un fel centru de atracție în domeniul nostru, ne vom referi la ele în cele ce urmează, doar asta ne face plăcere, nu? Având aplicația, totul ar trebui să înceapă de la niște scenarii de bază care să urmăreasca “flow-ul”. Și dezvoltând aceste scenarii să vedem dacă fiecare părticică din pretinsul tot al aplicației își joacă bine rolul.
Și dacă e să o luăm de la început, am putea să ne lăudam cu niște teste scrise pe baza unor “Cerințe”, cum am zice noi “Requirement-uri”, care ar fi cazul ideal, după mine. Specie rară – Clientul care știe ce vrea - din punct de vedere funcțional, estetic și tehnic. Daca aș fi eu Clientul aș ști că vreau un produs calitativ, care să fie livrat ieri, cu costuri minimale, probabil asta știu toți Clienții, nu? Evident această abordare ne afectează nouă cursivitatea și succesul testării. Gândindu-mă la experiențe și discuții aș putea zice ca am întâlnit destul de des sintagma – de la Client de data asta: “Dacă nu-l poți convinge, zăpăcește-l “
Acum că am așezat totul într-un context am putea să dăm prima Contră. Folosind explorarea s-ar putea să ne scape flow-uri de bază și să deviem cu bună știința în credința că scenariile de bază merg. Nu e cea mai constructivă gândire, dar cred ca măcar o dată tot am căzut în păcat.
Să zicem că am terminat de explorat aplicația și precum ne-am așteptat am găsit o sumedenie de bug-uri carecâteodata ne-au făcut ziua ori mai frumoasă ori mai nervoasă, după caz. Expresia “terminat explorat aplicația” e una mai relativă, e aproape la fel cum am zice că aplicația nu are buguri), se poate? Contra. Cum gestionăm și măsuram ce am testat, doar nu vrem sa repetam aceeași explorare. Evident e mai greu decăt să dăm un pass sau un fail la niște teste deja scrise. Ar fi aici de fapt și un Pro, existând modalități de măsurare: Checklist, Recording, Notes, Bug Hunt, Questioning…
Abordarea în sine, prin natura ei, te invață să cunoști produsul.
Faci și înveți să faci cam de toate: să creezi teste, să le rulezi,să investighezi, să contabilizezi…
Folosește partea mai curioasă si creativă din fiecare, zic eu. E momentul mai multor întrebări “ce ar fi dacă”, “ce ar fi să”, comparativ cu testarea dupa mai mulți pași din exceluri, worduri, qc… sau orice altă metodă ar fi folosită.
Ar trebui sa conducă la creșterea responsabilității, având în vedere că fiecare explorator trebuie să decidă traseul prin vrea să facă o anumită testare, iar in realizarea lui sa găsească, investigheze, folosească orice mijloc care l-ar putea ajuta, pornind de la specificațiile (ne)existente, la produse similare testate, la produse concurente.. Ce ar putea să ajute aici e conștientizarea faptului că explorarea fiecaruia e unică prin simplul fapt că fiecare tester e unic.
Cam astea ar fi câteva dintre argumentele disputate momentan, fiecare dintre ele poate constitui un nou subiect de discuții pe care o lăsam pe altă dată, când vom avea mai multă hârtie, mai multă mină la creion, mai mult timp.
Dacă ar fi să trag acum o linie, aș zice Pro, dar nu ca metoda unica de testare.
de Simplex team
de Tavi Bolog
de Ovidiu Deac
