Metode de a gandi si scrie cazuri de testare
Job-ul unui QA cu siguranta este compus din foarte multe activitati si parti componente care alcatuiesc la nivel general ciclul de viata al testarii software, parte componenta si fundamentala a SDLC. Despre ce face intr-o zi normala un QA am vorbit mai demult intr-un articol dedicat, aici pe blog.
Astazi ne vom apleca asupra uneia dintre aceste activitati componente, si anume gandirea si scrierea scenariilor si cazurilor de testare. De multe ori, nu e tocmai usor sa ne gandim la aceste cazuri si sa le scriem intr-o maniera prea simpla, asa ca in continuare vom vedea ce solutii putem aplica pentru a simplifica aceasta activitate.
Nevoia de testcases: obligatorii sau optionale?
Cand vine vorba de importanta cazurilor de testare, dezbaterea devina destul de complexa ca urmare a diferitelor opinii fata de acestea. Pe de-o parte, sunt cei care considera ca nevoia de testcases este obligatorie, acestea fiind cele care trebuie urmate cu sfintenie atunci cand se abordeaza o functionalitate noua, deoarece ele contin datele si pasii necesari ce trebuie urmati pentru a verifica in mod corect un feature, in modul in care a fost gandit acesta.
Pe de alta parte, exista opiniile potrivit carora testcase-urile nu sunt deloc obligatorii, si deci necesitatea lor e indoielnica. Argumentul principal al acestei pozitii este acela ca ele limiteaza testarea exploratorie si creativitatea testerului atunci cand acesta este pus in fata unei functii noi, si in loc sa incerce diferite situatii in functie de cum ii vine natural lui, trebuie sa urmeze strict acele testcases si atat.
Personal, consider ca trebuie un echilibru in aceasta abordare. Testcase-urile au rolul lor, acela de a sintetiza intr-o formula scrisa flow-urile principale sau secundare din cadrul unei aplicatii, si de a ne face sa nu uitam care sunt acestea, pe masura ce proiectul devine din ce in ce mai complex.
In acelasi timp, nu trebuie sa ne limitam doar la acestea, mai ales cand testam initial un feature. In aceasta situatie, testarea trebuie sa fie cat mai larga si cuprinzatoare, sa nu ne limitam strict la 2-3 flow-uri principale si atat, ci sa incercam cat mai multe lucruri, sa ”dam de pamant” cu acel feature pana gasim bug-urile sale ascunse. De multe ori, cazurile de test au rol de reminder, mai ales la o testare de regresie: sa nu uitam si de X si Y sa testam pe langa A, B si C, chiar daca poate X si Y nu par la fel de importante.
Cum putem sa gandim sau sa gasim idei pentru cazurile de test?
De multe ori poate nu e tocmai usor sa scriem prea multe cazuri de testare care sa fie relevante pentru functionalitatea ce o avem de testat, din diferite motive: fie poate nu am inteles-o suficient de bine, fie nu stim exact cum ar folosi-o un utilizator final, fie poate nu ni se pare prea atractiv sa scriem testcases.
Aici se cuvine facuta o clarificare importanta, cea intre notiunea de caz de testare (testcase) si scenariu de testare (test scenario). Un scenariu de testare reprezinta generalizarea unei componente din cadrul aplicatiei referitoare la modul in care ea trebuie verificata, si grupeaza la randul ei mai multe testcases.
Spre deosebire, un caz de testare este un set de pasi concreti, cu preconditii si rezultate asteptate bine definite, care descrie un flow concret din cadrul acelui scenariu. Un exemplu de test scenario ar fi Check the login functionality, pe cand un caz de testare pentru Login ar fi cel in care trebuie sa verificam aceasta componenta cu credentiale gresite: introducem username, introducem parola gresita, apasam click iar rezultatul ar fi ca userul nu se poate loga in pagina respectiva.
Sa vedem cum anume putem face sa scriem cazuri sau scenarii de testare mai usor.
1. Cum anume ajuta un utilizator final acea functionalitate?
O prima metoda pe care o putem aplica de fiecare data si care ne-ar ajuta inclusiv profesional sa devenim testeri mai buni este aceea de a ne adapta mindset-ul sa gandeasca din perspectiva unui utilizator final.
Astfel, cand nu stim de unde sa apucam o aplicatie sau o functie anume, putem face un pas in spate si sa incercam sa o privim in tabloul de ansamblu, contextual, si sa ne gandim cum ar folosi-o un utilizator simplu, nespecialist, daca ar trebui sa o foloseasca intr-un context real.
Pornind de la aceasta mentalitate, putem pune pe hartie cateva flow-uri intr-un mod sumar, pe care ulterior sa le dezvoltam sub forma unor testcase-uri adevarate, complete, cu titlul, descriere, preconditii, pasi de reproducere si expected results.
De exemplu, daca avem o aplicatie de mobil care ne efectueaza plati cu cardul, merita sa ne gandim in ce context o va folosi userul, ce conditii are nevoie ca sa mearga, ce sume se pot achita cu ea, in ce monede, deci tinand cont de cat mai multe variabile cotidiene. Daca exista, experienta noastra personala este un punct bonus aici.
2. Experimenteaza acel feature ca sa il intelegi
O a doua metoda esentiala ce ne ajuta enorm cand trebuie sa intelegm un produs software pentru a-i putea scrie cazurile de testare necesare este aceea de a folosi practic noi insine acel produs. Nimic nu ajuta mai mult procesul de intelegere decat practica efectiva pe ceva anume, iar testarea unui produs in prima faza este cu siguranta ceva ce nu se poate deprinde decat practic.
Odata ce am testat manual, ne va fi mult mai usor sa identificam posibilele situatii in care un utilizator va folosi acel produs, si deci sa identificam flow-urile de testare. Daca ne limitam strict la partea teoretica, mai ales pe un produs complex, de nisa, pe care probabil nu il cunoastem asa de bine, atunci va fi infinit mai greu sa scriem testcases.
Nu este totusi recomandat sa amanam prea mult scrierea de testcase-uri pana cand un produs sau functie e gata, deoarece dupa aceste activitati (scrierea de cazuri si testarea propriu-zisa) se vor suprapune si ne vor ocupa prea mult timp, riscand sa omitem detalii importante.
3. Ghideaza-te dupa documentatie
Un alt mod foarte bun prin care ne putem ghida ca sa gasim idei pentru cazurile de test ce trebuie sa le scriem este sa ne bazam pe documentatia proiectului (daca aceasta exista, sub o forma sau alta).
Cu ajutorul documentatiei, putem identifica ce anume trebuie sa faca respectiva aplicatie (sau feature in cadrul unei aplicatii mai mari), ne putem uita dupa verbele de comanda sau scenariile de User Experience generale daca sunt trecute („Utilizatorul va putea sa…”), si de aici sa ne inspiram fara probleme pentru a scrie testcases valide.
Uneori in cadrul documentatiei tehnice sunt trecute si detaliile adiacente precum date de test specifice, platforme unde trebuie testat, conturi dedicate si multe alte lucruri asemanatoare, care pot fi trecute la fel de bine in continutul cazurile noastre de testare.
4. Liste predefinite de testcases
In functie de gradul de generalitate al componentei respective si a gradului in care este ea intalnita sub o anumita forma si in alte produse software, putem sa ne ghidam la scrierea cazurilor de testare si dupa anumite liste predefinite.
Mai precis, daca nu stim exact de unde sa pornim, sau daca sunt prea multe cazuri si ne pierdem in multitudinea ideilor, exista solutia de a cauta pe internet cu un simplu search liste predefinite de testcases pentru functia X, asta daca metaforic vorbind „roata a mai fost o data inventata”.
De exemplu, am cautat pentru exemplificare liste predefinite de cazuri de testare pentru functionalitatea de Login sau de Search, la modul cel mai general, si am gasit si pentru Login, si pentru Search rezultate foarte interesante. Desigur, nu trebuie luate de aici cu Copy-Paste si atat, ele trebuie editate si adaptate aplicatiei noastre, insa pot fi un punct bun de pornire.
De asemenea, e posibil ca daca aplicatia noastra sa fie una mai speciala, de nisa, sa nu gasim astfel de liste predefinite, sau nu chiar atat la de usor, la prima cautare pe Google.
5. Ce zice AI-ul?
O ultima metoda in ton cu tendintele tehnologice ale vremurilor in care traim este, desigur, sa intrebam un chatbot bazat pe AI. Si cu siguranta din aceasta categorie, cel mai cunoscut instrument este de departe ChatGPT.
Pentru a exemplifica la modul cel mai general, i-am spus lui ChatGPT sa imi zica ce cazuri de testare ar putea sa imi livreze pentru o aplicatie mobila care iti cauta curse aeriene si ti le compara in functie de mai multe detalii (pret, data de plecare etc.). Rezultatul e destul de impresionant, in termen de ~1 minut mi-a oferit mai multe testcase-uri grupate tot de el in 6 categorii diferite (cautare, filtrare, securitate, UX etc.), si in fiecare categorie a inclus intre 1 si 3 cazuri de testare, deci aproximativ 20 de cazuri drept exemplu. Deloc rau pentru o baza de pornire ce poate fi ulterior dezvoltata.
Aici insa trebuie mentionate si niste lucruri ce tin de limita folosirii acestor instrumente AI online. E foarte posibil ca in multe cazuri companiile sa nu permita deloc (sau aproape deloc) folosirea acestor chatboti AI deoarece s-ar putea pierde informatii confidentiale din zona de dezvoltare si productie, si sa ajunga sa fie ulterior publice si folosite de alte companii concurente. Deci inainte de a folosi ChatGPT pentru activitatile de la job, asigura-te ca ai voie sa faci asta fara repercusiuni legale.
Concluzii
In incheiere, exista mai multe metode pentru a ne cauta surse de inspiratie si a formula cazuri si scenarii de testare pentru o functionalitate sau aplicatie pe care o avem pe mana la testare. Chiar daca la inceput pare putin mai greu, putem depasi acest lucru cu o documentare mai buna din surse ce sunt relevante pentru proiectul nostru, cautand pe Google sau in unele cazuri sa intrebam un chatbot AI.
Surse consultate si suplimentare
Ghiduri de scriere de testcases si sfaturi generale sunt pe Medium, LambdaTest si Coursera.
Idei template pentru cazuri de test generale
Liste predefinite de testcases pentru functionalitatea de Search si cea de Login
