Categorie: blog

QA automation- pastile greu de înghițit

Subiecte ale acestui articol: servicii de testare software, QA automation, QA testing în software development. 

Despre autor: Răzvan Vușcan este QA Automation engineer pe divizia noastră de Travel&Hospitality Software 

Ideea acestui articol mi-a venit după mai multe experiențe și lecții învățate de-a lungul timpului, făcând  QA automation pentru servicii software în travel. Majoritatea aplicațiilor web au un impact mare asupra gestionării unui software de călătorie. Când am început pentru prima dată, eram dornic să învăț, să explorez, dar și să încerc să fac totul ca la carte.  M-am gândit că trebuie să automatizez totul și am simțit că limbajul de programare și instrumentele folosite la acea vreme (Java și Selenium Webdriver) sunt biletul meu către succes. Cel puțin pentru că aproape toată lumea le folosea. Chiar credeam că sunt cele mai potrivite pentru automation testing și nu aveau concurență vreo altă aplicație web. Și teoria mea a funcționat …pentru o vreme. 

Procesul serviciilor de testare software 

 Apoi vremurile s-au schimbat. Serviciile de testare software au devenit mai complexe, iar principalele aplicații web de călătorie la care am lucrat la început, au început să se îndepărteze de structura lor monolitică.  Acelea scrise folosind limbaje de programare convenționale, cum ar fi Java sau .Net. Limbile de scripting precum Javascript au început să câștige din ce în ce mai mult teren. Interfețele utilizatorului erau mai rapide, fluxul convențional care ducea utilizatorii de la o pagină la alta se îndrepta către aplicații cu o singură pagină, care erau toate încărcate pe aceeași pagină în mod asincron. 

Desigur, acest lucru complica lucrurile și am simțit că instrumentele pe care le-am folosit deveneau prea pretențioase pentru noile interfețe de utilizator. Testele deveniseră neplăcute, deoarece nu puteau suporta încărcarea corectă a evenimentelor sau sincronizarea animațiilor și apelurilor. 

Așa că, inițial, am început să găsesc soluții tehnice la aceste probleme. Întrucât la vremea respectivă făceam doar QA automation testing pentru software de gestionare a călătoriilor și nici o testare manuală, nu îmi puteam permite să implementez tot felul de piese de logică pentru a face față problemelor tehnice din cadrul testului. Dar mentenanța începea să devină un coșmar. Simțeam că nu ajung nicăieri. Ulterior, am început să înțeleg mult mai bine cadrul testului și am început să folosesc mult mai mult limbajul de programare decât pentru scrierea testelor. 

Am construit chiar mai multe cadre noi de la zero pentru a experimenta diferite teorii și abordări. De asemenea, am lucrat mult mai mult la conductele de integrare continuă, încercând să le grăbesc, să le împart pentru a deveni mai eficiente și a genera rapoarte mai bune cu un timp de transformare rapid. 

Nu vă uitați rădăcinile  

Dar, pe măsură ce am avansat pe această cale de developer/ ca DevOps, mă îndepărtam de rolul meu inițial de tester. Soluțiile mele tehnice deveneau din ce în ce mai complexe. De exemplu, Mă concentram prea mult asupra modului de a scrie logica pentru a ocoli o problemă de încărcare, în loc să accept doar că, probabil, pagina / codul este anormal de lent și  ar fi bine să vorbesc cu developerii să se uite la bug și să găsească o comună. 

Așa că acesta a fost momentul meu de ”aha!”: petreceam prea mult timp să găsesc soluții prea complicate la probleme evidente de utilizare care ar putea deranja pentru un utilizator, precum și să fac prea multă mentenanță pe framework-ul procesului de testare automată și a conductelor de integrare continuă. 

Ceva trebuia făcut. Așadar, am început să fac niște introspecții. Am început prin a-mi revizui sistemul de valori și a-mi da seama de ce vreau să fiu tester în primul rând. Mi-am amintit că lucrurile ar trebui să fie alb-negru când vine vorba de testare: fie este o eroare, fie nu. Desigur, următorul pas a fost să revizuiesc testele automate din software-ul de travel la care lucram. Am observat că acestea deveniseră prea lungi și prea complexe, luând prea mult timp pentru a funcționa așa că trebuia să găsesc o soluție. Pe scurt, mi-am dat seama că, de multe ori, erau din start predispuse la eșec pentru că în loc să se ruleze de la început la sfârșit, se opreau foarte des întâmpinând probleme. Așa că a trebuit să-mi dau seama de o soluție de fragmentare a acestor teste care au devenit mamuți, în biți atomici independenți, care se concentrează pe testarea unui singur lucru. 

Fii deschis la nou 

În cele din urmă, cel mai greu a fost să recunosc că instrumentul de testare și limbajul de programare pe care îl foloseam nu se potriveau nevoilor menționate mai sus. Aplicații: Interfațele utilizatorului erau acum transformate prin puterea ” React” sau ”Angular”. Lucruri precum GWT sau Drupal au fost abandonate în favoarea primelor două. Așadar, am avut nevoie să găsesc un instrument de testare care să funcționeze bine cu apelurile asincrone de JavaScript pe o pagină web, pentru a petrece mai puțin timp făcând întreținere și mai mult timp făcând scripturi de test pentru proiectul dat al serviciilor de testare software. 

În cele din urmă, am găsit ceva care a funcționat pentru mine: NightwatchJs, care este un cadru de test de la un capăt la altul scris în NodeJs. Curba de învățare nu a fost atât de dificilă și trecerea de la Java și Selenium Webdriver nu este la fel de dureroasă cum mă așteptam inițial. Mi-a plăcut mult faptul că Nightwatch era ușor de integrat cu Cucumber și putea oferi rapoarte de testare scrise într-un text care poate fi citit de om, pe care orice utilizator l-ar înțelege. 

De asemenea, a acceptat caracteristici împărțite în scenarii descriptive cu pași clari. 

În total, un cadru de testare puternic, dar ușor de utilizat și de menținut, ceea ce mi-a permis să mă concentrez mai mult pe scrierea testelor de la un capăt la altul pentru interfața cu utilizatorul, dar a avut și potențialul de a scrie teste de strat API, din cauza scrierii în Nodejs. 

Lecția 

Cred că cea mai mare lecție pe care am învățat-o a fost că uneori trebuie să renunți și să o iei de la capăt, în loc să rămâi blocat folosind un singur instrument de testare sau limbaj de programare. 

Cel mai bun instrument pentru meserie nu este întotdeauna ceea ce folosește masele. Așadar, nu vă fie teamă să căutați ceva mai potrivit pentru proiectul dvs., deoarece am încercat să îl găsesc pe cel potrivit pentru software de gestionare a călătoriilor, în cazul meu. Dacă ajungeți să pierdeți prea mult timp cu soluții tehnice sau să faceți întreținere, atunci ar trebui să vă regândiți la abordare și să analizați direcția pe care o urmați înainte de a fi prea târziu.