Asa cum am mai discutat in trecut aici pe blog, testarea reprezinta un proces amplu, care incepe inca din faza de discutii despre un anumit feature nou si trebuie sa fie prezenta permanent in cadrul etapelor din structura unui Software Development Life Cycle.

O componenta foarte importanta in cadrul verificarii si validarii unui produs sau functionalitati software o reprezinta testele automate. Acestea au rolul de a economisi timpul de testare al anumitor functionalitati deja implementate, pentru a ne asigura ca inca functioneaza si sunt valide in noile iteratii ce se lanseaza pentru clienti, deci ca nu s-a stricat ceva ce functiona deja.

Testele automate sunt insa utile in egala masura in care sunt si actualizate si mentinute corespunzator, asa ca astazi vom discuta despre ce inseamna procesele de automation review si refactorizare a codului.

Procesul de automation review

Le vom lua pe rand, iar primul proces despre care discutam este cel de automation review. Acesta reprezinta verificarea testelor automate care ruleaza in cadrul unui proiect (framework) de testare automata pentru a le inspecta si observa gradul lor de incredere (reliability) si consistenta a executiei (sunt passed sau failed, si din ce cauze, justificate sau intamplatoare).

Atunci cand se implementeaza si se adauga noi teste automate pentru anumite functionalitati ale unei aplicatii, este extrem de important sa ne asiguram ca ele sunt valide, adica ca verifica ceea ce s-a cerut de la acea functionalitate si eliminam astfel posibilele situatii de rezultate nevalide, dar si inconsistentele din rularea lor pentru a nu avea teste automate flaky, despre care am mai povestit in trecut aici pe blog.

Insa daca am adaugat teste automate noi in proiect, nu inseamna ca treaba noastra vis-a-vis de ele s-a terminat. Este important sa ne asiguram ca ele raman valide si consistente, si ca ne putem folosi de ele in anumite task-uri din cadrul procesului de testare, cel mai frecvent exemplu fiind atunci cand trebuie validat un release nou al unei iteratii care contine (si) functionalitatea noua.

Iar pentru a nu rula mereu aceleasi teste manuale si a pierde timp cu ele, se incearca automatizarea lor (desigur, in masura posibilului) si atunci ele economisesc timp cand se face o noua validare a unei aplicatii in mediul de testare (Staging) sau Productie (unde sunt clientii).

Daca insa testele noastre nu au mai fost verificate de mult timp, sunt neactualizate, inconsistente ca rezultate si poate chiar incomplete, atunci nu ne putem baza pe ele pentru a creste viteza de validare a noilor produse software, si deci devin inutile si inutilizabile. De aceea e necesar si obligatoriu ca in cadrul procesului prin care adaugam teste automate noi, o data la un interval de timp stabilit in echipa de development / testare sa se faca o revizuire (review) a testelor automate.

Ca procedura in sine, desi nu exista o reteta universala si depinde extrem de mult de numarul si tipul de teste automate ale proiectului, exista cateva lucruri de care trebuie tinut cont cand se face test automation review.

In primul rand, pentru a avea o imagine de ansamblu a situatie testelor din framework-ul de automation, acestea trebuie rulate toate, integral, intr-un mediu stabil care sa nu impacteze clientii in vreun fel. Rezultatele rularii acestora trebuie in paralel inregistrate si sintetizate, pentru a avea un raport cat mai clar al situatiei acestora: cate au trecut, cate sunt failed, la ce situatie / pas / metoda a picat fiecare test, cu ce eroare au picat etc.

Dupa ce au rulat testele, ideal cu un anume timp inainte de vreun release, pentru a nu grabi in mod nejustificat procesul de review, trebuie facuta analiza si corectia erorilor din rulare testelor automate. Iar aici sunt mai multe situatii comune ce trebuie avute in vedere:

• Locatorii din proiect s-au schimbat: destul de frecvent mai ales la testele de UI, dar o situatie destul de comuna si usor de corectat.
• Bug-uri pe anumite flow-uri: cum aminteam si la inceput, testele automate ne ajuta sa verificam ca ceea ce mergea in trecut nu s-a stricat. Iar pentru asta trebuie sa fim mereu alerti ca bug-urile se pot strecura oriunde.
• S-au schimbat anumite flow-uri din cadrul aplicatiei: poate inainte cand se apasa butonul A, se intampla situatia B, iar acum butonul a disparut fiind inlocuit de un meniu cu mai multe optiuni, si deci logica testului trebuie updatata in concordanta.
• Executie lenta a unor actiuni: UI si locatorii au ramas aceeasi, dar exista probleme la partea de performanta a aplicatiei, poate se incarca mai greu, exista slowness in executie si asta duce la inconsistente si alte probleme de performance.
• Alte probleme ale mediului de rulare: poate sunt probleme cu alte servicii, pe partea de backend care nu raspund corespunzator, sau daca ruleaz acele teste pe o masina virtuala ori fizica sa exista probleme de configurare pe acestea si care trebuie rezolvate pentru o rulare impecabila.

Fixarea problemelor din codul de de automation poate fi destul de provocatoare, si in general mai grea decat simpla adaugare de teste automate noi cu o logica proprie, construita de la 0. Automation review-ul presupune intelegerea unor probleme specifice, unele cu care te intalnesti poate pentru prima data, si care necesita fie solutii in cod, fie rezolvari out-of-the-box.

Review-ul nu trebuie sa se rezume aici numai la corectarea testelor automate, ci si la (re)verificarea suitei de test cases, pentru ca de aici pornesc inconsistentele si situatiile de invalidare a unor flow-uri. De aceea e important sa fim atenti cand modificam un test automat (sa zicem ca ii adaugam un pas ce verifica un detaliu anume), sa modificam si test case-ul aferent pentru a avea un proiect cat mai up-to-date.

Procesul de refactorizare a codului si a testelor automate

Al doilea proces despre care vorbim este cel de refactorizare a codului testelor automate. Acesta se afla in stransa legatura cu procesul de automation review, de multe ori confundandu-se unul cu celalalt, dar exista niste deosebiri importante.

Refactorizarea codului este acel proces prin care se incearca modificarea si updatarea unui cod deja implementat pentru a-i spori eficienta si rapiditatea sa, pentru a fi mai curat (clean code) si mai usor de intretinut de acum incolo, fara a-i schimba insa comportamentul (sau output-ul) sau.

Ca exemple de refactorizarea codului, in acest caz al codului pentru teste automate, putem enumera:

• Parametrizarea unor pasi / metode ce contineau date hardcodate pentru 1 singur caz, astfel incat sa fie adaptabile si la alte cazuri asemanatoare din testele respective.
• Stergerea din proiect a codului ce nu mai este deloc folosit (unused code). Nu merge cu argumentul „il lasam acolo ca nu stim niciodata cand ne trebuie”, codul trebuie sa fie cat mai suplu si usor de gestionat.
• Refolosirea unui cod prin includerea anumitor elemente suplimentare care sa il faca usor de refolosit pe viitor. Un exemplu frecvent, daca o metoda contine un IF pentru un singur caz, acel IF poate fi inlocuit cu un SWITCH case pentru a include si altele asemenea, si a nu le generaliza prin codul din ELSE.
• Corelarea si stergerea metodelor / pasilor duplicati, care de-a lungul timpului au fost adaugate din neatentie, in loc sa se (re)foloseasca ceea ce exista deja.
• Stabilizarea locatorilor mai ales in acele puncte unde poate nu sunt suficient de „unici” si pot aparea rezultate flaky.

Refactorizarea poate fi inclusa extrem de bine in cadrul procesului de automation review, deoarece cuprinde situatii si solutii intalnite la comun si care conduc spre stabilizarea suitei de teste automate. Insa in sine este o situatie distincta pentru ca ea se poate face prin task-uri separate, si care nu conduc uneori la alte rezultate ale testelor, comportamentul lor asteptat (expected output) ramane acelasi.

De exemplu, sa zicem ca facem review la teste si aveam 5 teste failed, am actualizat locatorii, acum sunt 5 teste passed. La refactorizare sa presupunem ca testele respective oricum rulau ok si erau passed, dar am parametrizat anumite metode, am sters altele nefolosite, si acuma testele sunt tot passed, dar codul proiectului este mai suplu, mai curat si mai usor de fixat pe viitor, daca va fi nevoie, pentru ca va fi mai usor de inteles la nivel general.

Ideea de baza este ca lucrurile simple sunt mult mai usor de intretinut cu timpul decat cele complexe. In trecut am vorbit despre mai multe bune practici privind testarea automata tot aici pe blog.

Procesul de code refactoring este si el la fel de necesar precum cel de review in cadrul testarii automate, si este un skill esential pentru un Automation QA. De multe ori nu trebuie adaugat ceva extra cat de regandit anumite situatii in cod, pentru a le eficientiza si a nu ramane cu un cod mostenit, greu de inteles si care va fi si mai dificil de refactorizat cand chiar va fi cazul.

Refactorizarea codului de automation si nu numai este solutia la una din cele mai frecvent intalnite probleme din zona de development in IT, si anume Technical Debt („datoria tehnica”). Acesta presupune implementarea pe repede inainte si la o calitate indoielnica a unui cod (functionalitate noua, cod de testarea automate sau altele) care ajunge sa aiba mari probleme de eficienta in timp si va deveni greu de intretinut si reparat.

„Datoria tehnica” apare din multe motive, fie graba de a face cat mai multe lucruri sau din lipsa intelegerii anumitor probleme sau requirements din Acceptance Criteria, cuvantul de ordine aici fiind cel de „compromis” – cu cat se fac mai multe compromisuri tehnice, cu atat lucrurile de reparat se vor inmulti.

Refactorizarea codului facuta in mod constant, temeinic si consistent poate conduce la reducerea acesteia. Desigur, in mod ideal ar fi sa nu existe deloc, in practica e foarte greu acest lucru dar e importanta gestionarea ei prin acest proces facut regulat in timp, poate o data la cateva sprint-uri.

Importanta proceselor de review & refactoring

Coroborand toate argumentele si exemplele anterioare, procesele de autoamtion review, respectiv de refactorizare a codului de testare automata au o importanta deosebita in cadrul oricarei echipe de QA.

Ele asigura in primul rand consistenta si utilitatea testelor automate adaugate in trecut, astfel incat echipa de testare sa se poata baza in continuare pe acestea atunci cand vor sa faca verificari punctuale sau trebuie sa valideze release-uri ale unor versiuni noi ale aplicatiilor software in cauza.

De asemenea, cele doua asigura un grad redus de Technical Debt pe partea de cod si mentin curat codul de automation, astfel incat sa fie cat mai usor de intretinut, sa nu dureze o vesnicie fixarea problemelor care apar cu timpul in acesta, si sa fie abordabil si de catre alti membri care vin in echipa respectiva.

Mai mult, aceste procese sunt un bun antrenament si pentru skill-urile de programare ale unui Automation QA care vrea sa invete sa rezolve probleme in codul existent, sa stie sa fixeze diverse probleme care apar sau sa optimizeze un cod care a fost scris pe fuga si nu la cele mai bune standarde.

Concluzii

In incheiere, procesele de automation review si code refactoring sunt 2 componente esentiale si necesare in cadrul oricarei echipe de testare care dezvolta si suite de teste automate pentru validarea noilor feature-uri si release-uri in cadrul SDLC.

Aceste procese ajuta ca testele automat sa ramana actuale, functionale raportat la noile adaugiri din cadrul aplicatiilor, consistente sub raportul rularii lor (sa fie passed sau failed cand trebuie si nu intamplator / flaky), si valide din punct de vedere al cerintelor de business, fata de ce trebuie sa ajunga la clienti.

Fara aceste procese executate in mod constant, testele automate ar deveni irelevante sub toate aspectele si ar creste exponential timpii de testare si verificare a functiilor deja implementate in cadrul produselor software.

Surse

Un articol detaliat cu etapele si detaliile unui process de automation review de la TestDevLab

Despre ce trebuie prioritizat la automation review

Tehnici si bune practice despre refactorizarea codului (code refactoring)