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…