Bune practici in testarea software
In viata de zi cu zi din cadrul procesului de testare software apar numeroase situatii cand, pentru a rezolva unele task-uri, e nevoie de a face sau de a sti anumite lucruri astfel incat acestea sa poata fi indeplinite cu succes si fara probleme ulterioare.
Chiar daca multe lucruri si sfaturi sunt cuprinse in teoria legata de testare din carti sau din cursurile pe care le-am urmat pentru a lucra ca testeri, practica efectiva ne va dezvalui mereu unele moduri mai adecvate de lucru, care poate nu sunt cuprinse in teorie.
Se mai poate intampla si reversul acestui lucru, si anume ca desi teoria prevede anumite lucruri importante de urmat, ele sunt ignorate sau uitate in practica, din diverse motive (greseala, neatentie, ignoranta etc.). Astfel, putem vorbi de anumite bune practici (best practices) in testare.
Exemple de bune practici in testarea software (QA)
Prin aceste bune practici putem intelege multe lucruri, de la sfaturi, mici trucuri, lucruri care in aparenta nu par cele mai importante sau mai grele, dar care in realitate ajuta enorm la desfasurarea cu succes a testarii software in ansamblu. Unele lucruri sunt considerate bune practici, altele mai putin, in functie de experienta si modul de lucru al fiecaruia.
Oricum ar fi, cele mai multe bune practici se invata cu timpul, prin exercitiu repetat, de multe ori dandu-ne singuri seama ce si cum e mai bine sa facem. In continuare, voi prezenta cateva exemple ilustrative, care cu siguranta nu sunt singurele si pot fi completate oricand.
Scrierea cat mai simpla si clara a test case-urilor
Orice pasionat sau angajat in testare stie ce reprezinta un test case, ca fiind un flow de pasi prin care vrem sa verificam o anumita functionalitate. Desi stim ca trebuie sa le scriem cat mai clar si fara inflorituri, de multe ori tindem sa cadem intr-una din cele 2 extreme: fie le scriem prea simplist si lacunar, nefiind clar pentru un alt coleg ce are de facut daca citeste acel caz de test, fie sunt prea complex scrise si se pierd in detalii.
E bine ca acestea sa cuprinda exact pasii esentiali pentru a nu incarca prea mult cazul de test, asa cum la fel de bine ar fi sa exista un review la test case-urile pe care le scriem, sa vada si un alt coleg cu o alta minte daca e bine cum am scris. Eventual, o data la ceva timp e recomandat sa existe si o reevaluare a test case-urilor, pentru a vedea care pot fi updatate sau chiar sterse, daca e cazul.
Scrierea clara a cazurilor de test e importanta si din perspectiva muncii viitoare de automatizare a lor. Daca sunt scrise clar si concis, e mult mai usor de inteles cum trebuie automatizate cu framework-urile aferente precum Cypress sau Playwright, si se pot concepe inclusiv in paradigma BDD (Behavior Driven Development), fiind scrise si in limbaj natural, nu doar in cod.
Adaugarea de atasamente la Bug reports
Un alt element de testare pe care il cunosc toti cei care lucreaza sau care aspira la o cariera de QA este raportul de bug (bug report). Fiecare curs serios de testare software prezinta structura obligatorie a unui bug report, de la titlu, la pasii de reproducere, rezultate asteptate (expected results) si rezultatele faptice (actual results).
Insa de multe ori tindem sa consideram mai mult optionala partea in care adaugam atasamente pentru acel bug. Fie uitam, fie ni se pare de la sine inteles despre ce bug e vorba si atunci ne limitam la a adauga pasii de reproducere cu expected si actual results si cam atat. Insa e o practica foarte buna si recomandata sa adaugam atasamente la rapoartele de bug scrise de noi.
Prin atasamente putem intelege imagini (screenshots) cu efectele bug-ului, inregistrari video in care putem executa noi flow-ul prin care am reprodus acel defect, inregistrari audio daca e vorba de sunete inexplicabile, detalii legate de environment-ul in care s-a gasit problema (ex: Windows / MacOS / Linux) sau log-uri (set de date din contul nostru din aplicatie) daca e vorba de o problema mai tehnica, de exemplu ceva ce tine de back-end.
Va fi mult mai usor pentru un developer sa inteleaga problema, si de urmarit pe viitor daca se mai reproduce sau nu. Recomandat e sa punem si atasamente dupa ce bug-ul e reparat, ca sa ramana clar cum trebuie sa fie in aplicatie.
Comunicarea directa cu programatorii si restul persoanelor implicate
Un alt aspect esential care poate fi oricand considerat o buna practica este comunicarea directa intre QA si programatori ori restul echipelor. Acest lucru e fundamental deoarece lipsa comunicarii conduce la intelegerea inexacta a defectelor descoperite in aplicatii si implicit la o proasta fixare a acestora.
De asemenea, daca nu exista o comunicare directa, nu prea se poate realiza nici o colaborare trainica, prin care task-urile sa fie indeplinite pentru ambele parti. De aceea e extrem de important ca un tester sa comunice direct, 1 la 1, cu programatorii si sa se indrepte spre acestia cand lucrurile nu sunt suficient de clare.
Discutiile directe pot fi mult mai eficiente decat sedintele largi unde se reunesc mai multe persoane, dar care nu sunt direct implicate / interesate, si inevitabil apare plictiseala, nerabdarea care nu sunt in avantajul nimanui. Ori de cate ori exista dubii legate de un bug sau cum ar trebui testat ceva, o discutie directa cu programatorul respectiv sau cu cei din zona de management poate clarifica si accelera in mod eficient testarea.
Testarea din perspectiva autentica a unui utilizator
O idee foarte importanta pe care trebuie sa o avem mereu in minte atunci cand verificam un anumit feature este aceea de a testa cat mai aproape de cum ar face-o un user adevarat. Acest best practice de multe ori este trecut cu vederea pentru ca e mai simplu si mai comod doar sa bifam anumite criterii tehnice pe care functionalitatea respectiva trebuia sa le respecte si atat, fara a intra mai adanc in modul de functionare.
Insa nu trebuie sa uitam in niciun moment ca tot ceea ce testam va ajunge ulterior, mai devreme sau mai tarziu, la utilizatori, iar acestia trebuie sa se poata bucura de o aplicatie cat mai curata de erori si defecte. Pentru ca acest lucru sa fie posibil, trebuie sa testam componentele in ansamblu, sa verificam daca interfata de utilizare (UI) si experienta prilejuita (UX) sunt adecvate pentru majoritatea utilizatorilor.
Ideal este si sa testam de exemplu in medii cat mai apropiate de realitate, de exemplu pe masini reale (computere cu Windows / MacOS) si mai putin pe masini virtuale pentru ca pot aparea anumite neconcordante.
Astfel, buna practica de a nu limita testarea strict la Acceptance Criteria, ci sa avem o perspectiva cat mai larga in testare, sa ne intrebam constant „Functionalitatea X la ce ii poate ajuta pe useri si cum e mai probabil ca acestia sa o folosesasca?” este fundamentala. Desigur, mereu vor aparea corner case-uri la care nu ne gandim, dar modul de abordare face diferenta pe termen lung.
Grija la micile detalii unde se pot ascunde defecte majore
Ceea ce am mentionat anterior se leaga direct de urmatoarea buna practica din testare, si anume faptul de a avea mereu grija la cele mai mici si aparent nesemnificative detalii. Acest lucru se leaga de faptul ca exact acolo unde (si cand) ne asteptam mai putin, fix acolo apar bug-urile in soft.
De multe ori ne gandim sa trecem poate cu vederea anumite detalii pe care le consideram prea mici, ca „nu se ascunde nimic acolo”, si e fix invers. De aceea, cand testam ceva, mai mare sau ceva particular, trebuie sa fim atenti la absolut orice ni se pare ca nu e in regula.
Uneori poate e un comportament pe care nu il stiam dar care asa e construit, insa de multe ori poate fi vorba de un bug serios, care trebuie raportat si corectat din timp.
Elaborarea pe niveluri a testarii automate
Un best practice despre care am discutat mai pe larg in trecut este legat de piramida nivelurilor in testarea automata. Aceasta este o proiectie ideala a modului in care ar putea fi organizata testarea automata pe 3 niveluri, astfel incat gradul de eficienta in acoperirea cazurilor de test sa fie cat mai mare.
Propriu-zis, aceasta piramida a testarii cuprinde nivelul de baza, Unit testing, unde testele automate care verifica codul in sine sunt scrise de developer; Component testing, unde deja se verifica o anumita componenta dar in mod individual; si apoi End-to-end testing, unde se testeaza corelat toate componentele precedente care trebuie sa formeze un tot unitar si functional.
La finalul celor 3 etape de automation vine testarea manuala, cu rolul de a verifica strict din perspectiva utilizatorului final acel soft. Chiar daca piramida nivelurilor nu se aplica de multe ori ca in teorie, este foarte util sa o cunoastem, deoarece ne ofera o perspectiva coerenta asupra metodologiei de lucru care sa imbine si sa structureze atat testarea manuala cat si cea automata.
Analiza constanta a obiectivelor si a procesului de testare
O alta buna practica in testare este legata de analiza constanta si (cat mai) obiectiva a tintelor pe care echipa le are de atins, a procesului in sine de testare si a celorlalte lucruri care decurg de aici.
De regula, cel mai intalnit si recomandat mod prin care se poate face aceasta (re)evaluare este printr-o sedinta (una, nu zece), unde sa se discute deschis daca sunt sau nu probleme, sa se faca o trecere in revista a prioritatilor echipei in cadrul SDLC, precum si ce se poate imbunatati pe viitor, in relatiile de lucru, procese etc.
Aceasta analiza retrospectiva este o practica foarte buna si pentru a imbunatati relatiile de lucru cu celelalte echipe, astfel incat sa existe o coeziune cat mai buna, care sa conduca la un progres constant.
Concluzii
In incheiere, e important de stiut ca in testare exista mici sfaturi si trucuri care au statutul de bune practici si care ne ajuta sa realizam mai bine anumite sarcini de lucru, contribuind semnificativ la o mai buna desfasurare a lucrurilor in ceea ce priveste amplul proces de testare.
Teoria, indiferent cat de cuprinzatoare ar fi si cat de bine am repeta-o, nu poate cuprinde toate micile sfaturi ce se pot aplica in practica. Aceasta din urma ne va pune mereu in fata anumitor situatii la care nici nu ne gandeam inainte, si ne va invata constant cum e mai bine sa procedam.
Micile detalii fac diferenta, motiv pentru care nu trebuie sa uitam si/ sau sa subestimam lucrurile de baza care pot diferentia intre succes si esec, intre functional si defect.
Surse suplimentare legate de subiect
Un articol de la Global App Testing si unul de la Novateus despre alte bune practici in testare software.
