Bune practici in testarea automata

Testarea software este un proces complex, idee repetata constant de-a lungul timpului cu scopul de a-i face pe toti oamenii sa inteleaga importanta si necesitatea ei in cadrul oricarei echipe ce dezvolta un anumit produs sau serviciu.

Desii unii oameni inca mai cred ca testarea nu e asa importanta, ea este o componenta fundamentala a dezvoltarii oricarui produs si se bazeaza pe metodologii si reguli. Un subiect important de stiut este ca si testarea automata prezinta anumite reguli de bun simt numite bune practici, despre care vom discuta in continuare.

De ce avem nevoie de astfel de reguli in Automated Testing?

In trecut am mai discutat aici pe blog despre bune practici in testarea software generala, iar atunci ziceam ca desi in teorie sunt multe sfaturi mentionate si e bine sa le cunoastem, totusi practica efectiva ne va dezvalui mereu unele moduri mai adecvate de lucru, care poate nu sunt cuprinse in teorie.

Astfel, chiar si in testarea automata avem astfel de reguli de bun simt care au fost validate de-a lungul timpului in practica si care ne pot face viata mai usoara in multe situatii. Desigur, nu exista o reteta perfecta despre cum sa aplicam testarea automata, si oricand putem adauga si valida noi idei.

De aceea, in continuare vom vedea cateva bune practici mai generala legate de partea de Automation QA, si de ce sunt ele necesare atunci cand incercam sa dezvoltam seturi de teste automate care verifica diferite functionalitati in aplicatiile noastre.

Exemple de bune practici in testarea automata

Sa vedem deci, intr-o ordine cat de cat logica si cronologica, care ar fi anumite bune practici legate de testarea software automata, pe care le putem aplica oricand in munca noastra de zi cu zi in acest domeniu.

1. Alegerea celor mai bune instrumente pentru testare automata (technical stack)

Primul pas cand incepem orice proiect de testare automata este sa ne alegem cu grija instrumentele de lucru, in special cele care ne vor ajuta sa punem la punct arhitectura proiectului si a scripturilor de rulare automata.

Este important sa decidem impreuna cu echipa ce tool de automatizare sa folosim in functie de ce anume se va testa preponderent, interfata grafica (UI – Selenium, Cypress, Playwright etc.), partea de API (Postman, SoapUI etc.) sau pe partea de mobile (Appium). Conteaza daca folosim anumite plug-in-uri care sa ne ajute sa controlam mai bine fisierele si dependintele noastre (Maven, JUnit, TestNG, Cucumber si Gherkin etc.), si desgiru limbajul de programare folosit (Java, JavaScript, Python, Typescript etc.). Daca vrei sa inveti bazele tesatarii automate, exista cursuri introductive foarte bune cu Cypress sau Selenium.

Odata ce proeictul a ajuns la maturitate si contine deja cateva sute de teste automate, e mai greu sa tranzitionam spre alt instrument si/sau limbaj, de aceea e important sa luam aceste decizii impreuna cu echipa la inceput. Scopul este sa cream un framework de testare eficient si functionabil pe termen mediu si lung.

2. Prioritizarea cazurilor de test ce merita automatizate

Oricat de dezvoltate ar deveni tehnologiile pentru testare automata sau cele aditionale, precum Inteligenta Artificiala, un lucru este sigur: nu toate cazurile de test pot fi automatizate. Desigur, aici exista o defalcare ce trebuie explicata. Unele testcases nu pot fi automatizate din punct de vedere tehnic pentru ca nu exista un suport 100% functionabil pentru acestea, precum testele ce presupun updatarea unei versiuni a produsului.

Insa alte cazuri de test nu merita a fi automatizate, chiar daca d.p.d.v. tehnic acest lucru este posibil. Iar aici explicatia este data de faptul ca resursele de bani, timp si energie ale echipei sunt limitate.

Si atunci trebuie analizat foarte clar care sunt acele cazuri si functionalitati ce trebuie automatizate cat mai rapid pentru a economisi timp pe termen lung, dar si pentru a nu sacrifica verificarea umana a unor detalii ce pot fi cu adevarat critice (ex: un sistem de notificare a securitatii contului).

3. Organizarea nivelurilor de testare folosind Piramida testarii

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.

4. Folosirea unor useri de test bine construiti

Ca sa ne rulam testele automate intr-un mod cat mai safe, dar apropiat de realitatea faptica din mediul de Productie unde aplicatia este folosita de utilizatorii finali, trebuie sa folosim niste useri de test dedicati pentru testare.

Acestia trebuie sa fie corect construiti, sa reprezinte niste conturi care sa nu afecteze in mod negativ mersul lucrurilor in testare, sa aiba acces la feature-urile pe care le pot avea si clientii. Ideal ar fi ca aceste conturi de test sa fie cat mai realist construite, fara workaround-uri care ar putea distorsiona rezultatele acelor teste, si deci sa ascunda bug-uri.

5. Gruparea testelor automate dupa feature-uri

Ajungem in punctul in care avem deja framework-ul de testare implementat, totul e bine la pus punct, screirea testelor merge fara sincope. Dar numarul acestora creste in mod constant si e din ce in ce mai greu sa navigam prin ele. Ce facem in aceasta situatie?

Evident, este nevoie de o reorganizare a lor prin gruparea acestora. Astfel, este extrem de util sa ne sistematizam testele automate in mai multe file-uri, in care sa le categorisim in functe de functionalitatea / feature-ul verificat. De exemplu, daca avem un website de e-commerce cu functia de Search, atunci taote testele care verifica aceasta functie de cautare pot fi puse intr-o signura fila, cu un nume distinct.

Aceasta sistematizare a testelor ajuta ca acestea sa fie dezvoltate mai usor in functie de feature=urile care se implementeaza, si pot fi ulterior luate la reverificat si “reparat” pe categorii, ceea ce asigura o ordine mai mare in munca echipei.

6. Aplicarea unui pattern de testare automata (POM)

Tot legat de organizarea testelor automate, este extrem de important si de util sa aplicam un pattern de organizare a testelor automate atunci cand incepem proiectul, cu acelasi scop, de a usura partea de mentenanta a a cestora si a intelege ulterior mai usor ce trebuie facut.

Un astfel de design pattern in automation este Page Object model, despre care am mai discutat tot aici in trecut. In acest caz, testele noastre automate sunt construite in doua parti distincte, care separa pasii propriu-zisi de logica de executie care e mentinuta separat (filele cu variabile, locatori, metode etc.).

Folosirea POM sau a altor pattern-uri structurale intr-un proiect de automation conduce la o mai buna intelegere a proiectului. E greu ca dupa ce ai scris un test ce implica 3 variabile, 4 locatori si 5 metode sa mai tii minte exact ce si cum ai facut dupa un timp, si mai ales sa le cauti prin tot proiectul. Refolosirea si mentenanta sunt 2 componente cheie ale unui proiect de succes.

7. Testarea automata continua prin CI / CD

Un alt best practice super important si util de-a lungul unui proiect care se intinde pe un timp mai indelungat si este mai complex ca structura si teste, este sa testam cat ma idevreme si continuu produsul dezvoltat.

Acest sfat deriva din incadrarea testarii automate ca o componenta esentiala in cadrul procesului de Continuous Integration / Continuous Delivery, unde dezvoltarea, implementarea, testarea si lansarea unor versiune de aplicatii se face in timp real, continuu, fara a se astepta perioade prea lungi de timp.

Testarea continua, zi de zi, prin rularea testelor automate, si din fazele timpurii ale aplicatiei asigura descoperirea din timp a eventualelor defecte tehnice sau a lucrurilor ce merita a fi imbunatatite din perspectiva calitatii generale a produsului.

8. Mentenanta regulata a testelor automate

O ultima buna practica despre care vom vorbi cand vine vorba de testarea automata este aceea a executarii regulate a mentenantei acestor teste. Acest lucru este mai mult decat necesar deoarece produsele IT, prin nautra lor, evolueaza constant si sufera modificari la nivel de complexitate si feature-uri noi implementate pentru clienti.

De aceea, si testele automate trebuie mereu revizuite si updatate, sa urmareasca constant modificarile din aplicatia testata si sa preintampine eventualele probleme ce se pot strecura. Prin mentenanta se pot corecta inclusiv acele teste flaky din automation, care pot reprezenta o adevarata bataie de cap pentru echipa de QA.

Daca nu exista nicio mentenanta regulata a testelor automate, ele vor deveni la un moment dat deprecated, scoase complet din uz, nu vor mai functiona, si deci vor fi inutile, obligand la executia lor manuala de catre testeri.

Concluzii

In incheiere, exista mai multe bune practici pentru zona de testare automata care pot usura in mod semnificativ munca unui tester. Cele mai multe dintre ele sunt sfaturi de bun simt, nu sunt rocket science, si se poate discuta oricand pe marginea lor cu colegii de echipa, astfel incat sa fie luate si aplicate cele mai bune decizii pentru proiectul de testare automata in cauza.

Surse consultate

Despre bune practici legate de testarea automata, exista detalii pe SauceLabs, BrowserStack si Medium.com

Despre bune practici generale in testare, Piramida testarii automate, Page Object model si flaky tests