Piramida nivelurilor in testarea automata
Asa cum am mai amintit si in trecut cu numeroase ocazii, precum atunci cand am discutat despre Software Testing Life Cycle, testarea reprezinta un proces complex si nu o simpla actiune izolata.
Testarea este de mai multe tipuri, este realizata de catre mai multi testeri in echipe, si se desfasoara treptat. Testarea automata, care presupune scrierea unor scripturi de cod ce ruleaza intr-un framework dedicat si verifica anumite conditii si functionalitati din aplicatie, este organizata in ceea ce este cunoscut astazi drept piramida nivelurilor in testare (testing pyramid).
Ce reprezinta piramida nivelurilor in testare?
Ca sa incercam sa o definim cat mai simplu, piramida testarii automate este un concept dezvoltat de catre Mike Cohn, unul dintre fondatorii Scrum Alliance, in 2009. Propriu-zis, aceasta piramida se refera la principalele tipuri de teste care compun partea de automation in cadrul procesului general de testare, la proportia pe care ideal ar trebui sa o reflecte si ordinea executarii lor logice.
Trebuie mentionat inca din acest punct de inceput ca piramida testarii reflecta o situatie ideala, care in mod clar difera de la o companie la alta, de la o echipa la alta echipa. Nu e neaparat o problema daca nu se respecta intr-un totul de la inceput (precum conceptele si ideile metodologiei Agile), piramida aratand spre ce ar trebui sa tinda procesul de testare automata ca organizare.
Nivelurile piramidei testarii
In functie de fiecare echipa/ companie/ autor, piramida testarii poate imbraca forme usor diferite, cu unele elemente in plus sau in minus, insa esenta ramane aceeasi. In continuare vom vedea care sunt principalele niveluri ce inevitabil intra in constructia piramidei testarii automate.
1. Unit testing
Primul nivel, cel care alcatuieste baza piramidei, este reprezentat de unit testing. Acest tip de testare se refera la testarea facuta de developeri care isi testeaza singuri propriul cod scris de ei. De ce aceasta testare este facuta de programatori si nu de testeri?
Motivele sunt multiple: programatorii cunosc cel mai bine codul sau bucatica de cod pe care au trebuit sa o scrie, si de aceea unit testele pot fi scris cel mai bine, mai rapid si mai eficient de catre acestia. Unit testele verifica strict liniile respective de cod, fara o implementare a lor de ansamblu in cadrul aplicatiei.
Nivelul de unit testing e cel mai mare deoarece se scriu multe teste din acestea, mai mici si automatizate, care sunt prima data rulate pentru a se asigura functionalitatea primara a acelui cod.
2. Integration testing
Al doilea nivel prezent in piramida este cel de integration testing. Daca unit testele verificau parti mici si punctuale din cod, la nivelul de integration testing se urmareste, dupa cum reflecta si numele, modul in care se integreaza piesele de cod intre ele.
Mai precis, daca s-au dezvoltat in paralel 2 functionalitati diferite ale aceleiasi aplicatii, si au fost verificate mai intai prin unit testing, acuma se testeaza daca cele 2 functionalitati merg bine impreuna, eventual si cu alte componente externe, ca sa nu apara blocaje ale aplicatiei pentru useri.
Deoarece nivelul creste, testele de integrare sunt mai putine numeric, se executa mai rar si intr-o viteza mai redusa decat unit testing.
3. UI si End-to-end testing
Al treilea nivel al testarii automate, situat in varful piramidei, este cel care se refera la verificarea UI (User interface) si End-to-end (de la un capat la altul). Acest ultim nivel de testare automata vine cu scopul de a ne asigura ca toate piesele de cod dezvoltate anterior functioneaza unitar si cat mai eficient daca sunt asamblate impreuna.
Scopul acestui nivel este de a verifica ca functiile principale sunt asigurate, ca aplicatia poate indeplini logica de business pentru care a fost conceputa, astfel incat clientii sa fie cat mai multumiti.
Sunt verificate flow-urile principale ale aplicatiei, adica pasii principali pe care un utilizator normal ii executa, ca nu sunt probleme legate de intreruperi in aceste fluxuri sau bug-uri de tip blocker (care fac sa cedeze brusc toata aplicatia).
4. Manual testing
Desi am mentionat la inceputul prezentarii ca piramida nivelurilor se refera la cum e organizata testarea automata, exista si un nivel superior deasupra varfului piramidei, si anume cel al testarii manuale. Aceasta e reprezentata aici cu scopul de a indica urmatoarea etapa a procesului de testare, cel in care aplicatia trebuie verificata „la mana”, exact ca un utilizator obisnuit, simuland o experienta cat mai precisa pentru ce trebuie aplicatia sa livreze.
Aici modurile de realizare a testarii manuale pot fi destul de diverse, unul dintre ele fiind testarea exploratorie (exploratory testing), ce nu are neaparat un plan de testare definit, unde testerul e liber sa verifice cum crede produsul respectiv, sa incerce diverse scenarii in mod liber.
Importanta piramidei si idei gresit intelese
Reprezentand un concept ideal, piramida testarii se reflecta destul de rar in practica exact asa cum este ea reprezentata in majoritatea cazurilor. Unele echipe si companii incearca permanent sa isi imbunatateasca atat suitele de teste automate, cat si procesul in care le aplica, astfel incat testarea sa fie cat mai calitativa in final.
Exista insa si situatii cand companiile nu se raporteaza neaparat corect la acest concept, caz in care piramida nivelurilor capata cu totul si cu totul alte forme, reflectate mai jos. Uneori se neglijeaza partea de integration testing, alteori se porneste de la premisa ca unit testing-ul echivaleaza toata testarea necesara pentru acel proiect.
Aceste cazuri incorecte ale aplicarii conceptului piramidei se pot datora, printre altele, si anumitor idei si stereotipuri care conduc la conturarea unei imagini gresite despre testarea software.
O prima astfel de idee este aceea ca testarea nu e vazuta de toata lumea ca un proces bine dezvoltat si structurat care se desfasoara in timp, ci ca pe o simpla activitate individuala, unde se trece in mare peste aplicatiei, daca aceasta merge si atat. Acest lucru duce la relativizarea importantei acestei componente fundamentale din SDLC, si implicit la minimalizarea sa, afectand in mod direct calitatea finala a produsului software in cauza.
O alta idee inteleasa gresit se refera la testarea facuta de programatori pe codul lor direct prin unit testing. Aici retorica este de ce trebuie si programatorul sa testeze daca exista deja QA angajati pentru sarcina asta? Iar raspunsul, pe care l-am mentionat si anterior la Unit testing, se refera in principal la natura acestui tip de testare.
Programatorul isi cunoaste cel mai bine codul, din punct de vedere tehnic, iar scrierea de unit testing este mai adecvata lor, fiind mai rapida astfel si mai eficienta. Odata scrise, aceste unit teste ruleaza rapid pentru a verifica la nivel primar functionalitatea codului.
De asemenea, am fi tentati sa credem ca daca avem aceasta piramida a testarii drept ghid, atunci testarea este la fel in toate companiile, ceea ce din nou, nu e intru-totul corect. Procesul testarii este diferit de la echipa la echipa, de la un tip de proiect la altul, in functie de cerintele tehnice si de business. De aceea procesul testarii trebuie sa fie unul adaptabil, raportat la context, lucru valabil si pentru piramida testarii automate.
Concluzii
In incheiere, se poate afirma ca acest concept al piramidei nivelurilor in testare este unul important de stiut de catre testeri si nu numai. Chiar daca in teorie este vorba de un concept ideal, e bine sa o cunoastem pentru a sti la ce sa ne raportam si cum sa adaptam munca de automatizare, pentru a imbina criteriile de eficienta, timp, costuri si calitate.
Chiar si la inceputul carierei in QA e important de cunoscut acest subiect, pentru a intelege ulterior mai bine angrenajele din care e compusa munca de testare intr-o companie de IT, si cum pot fi ele adaptate si imbunatatite in timp.
Surse despre subiect
Mai multe surse, informatii si opinii despre piramida testarii sunt 👉 aici, 👉 aici, 👉 aici si 👉 aici.
