Un punct extrem de important în percepția pe care un utilizator o are despre o aplicație este reprezentat de UI și componentele vizuale ale ei. Luând în calcul faptul că UI/UX este văzut ca o componentă importantă în cadrul procesului de dezvoltare a produsului, în raport direct proporțional crește și riscul de a apărea probleme în cadrul aplicației, în timpul sau după finalizarea funcționalităților implementate.
Mai jos, regăsim câteva aspecte importante referitoare la importanța UI/UX în cadrul unei aplicații și a modului în care acestea sunt percepute de către utilizatori:
94% din prima percepție a unui site este dată de către componentele de design.
Este cel mai probabil ca peste 74% dintre utilizatori să revină după ce au accesat un site care este mobile-friendly.
73% dintre companii investesc în design pentru a deosebi brandul lor față de cel al competitorilor.
66% dintre utilizatori preferă să acceseze un site cu un design plăcut dacă au nevoie de mai mult de 15 minute pentru a vizualiza conținutul său.
Cunoscându-se importanța pe care o poate avea un UI/UX de calitate în cadrul unei aplicații, este esențial ca și testarea să se asigure că cerințele venite din partea echipei de design sunt corect implementate în cadrul aplicației și că viitoarele modificări nu vor avea un impact asupra ei.
A asigura o validare a elementelor de design, aplicând o abordare clasică, adică prin utilizarea unor elemente DOM și a atributelor pe care acestea le au, nu este fezabil în contextul unei aplicații complexe. Aceasta, din cauză că, în timp, va genera o suită de teste care vor fi extensive din punctul de vedere al duratei de test. Lângă asta se adaugă creșterea riscului de a avea teste care vor cădea aleatoriu din cauza încărcării elementelor în UI sau a tranzițiilor/animațiilor care vor trebui luate în considerare în cadrul testelor.
O altă abordare utilizată pentru a putea valida componentele de UI dintr-o aplicație este compararea de imagini. Și anume, o validare făcută la nivel de pixel între o imagine inițială și o imagine din timpul execuției testelor automate. În cazul în care există o diferență între cele două imagini, testul va cădea, iar diferența va fi expusă într-un raport împreună cu restul detaliilor din cadrul testului.
Pentru a ajunge la implementarea unei suite de teste vizuale automate sunt necesari câțiva pași pe care îi putem regăsi mai jos:
În realizarea acestui demers este foarte important să identificăm atât aspectele care vor fi luate în considerare pentru decizia finală, cât și ponderea acestora.
În cazul de față, factorii și ponderea acestora sunt următorii:
Costul soluției de testare;
Durata testelor;
Această pondere este extrem de importantă deoarece în scenariul de față a fost esențial în decizia finală, întrucât a schimbat locul în clasament între o soluție oferind mai multă accesibilitate și o altă soluție oferind un plus din punctul de vedere al duratei execuției testelor.
Este necesar să existe mai multe opțiuni cu diferite caracteristici specifice, cum ar fi open source sau ușor de implementat. De reținut că lista finală de soluții va trebui să conțină suficient de multe opțiuni încât să nu se prelungească următoarea etapă.
Cel mai important pas este încercarea de integrare a fiecăreia dintre soluții în ecosistemul actual de testare automată. Acest lucru se face, de obicei, prin instalarea cerințelor specifice fiecărei soluții, crearea unui mediu de testare și definirea unui set de teste care să atingă diferite arii ale aplicației care va fi testată.
Bineînțeles că un aspect important și obligatoriu al acestei etape este format din măsurarea și documentarea funcționalității fiecărei soluții de testare pentru a fi folosită ulterior în determinarea performanței acestora.
Pe lângă pașii de mai sus, este vital să păstrăm un contact permanent cu furnizorul soluției de testare pentru a ne asigura că setările pe care le facem și modul în care o integrăm e cel care ne oferă maximul de performanță.
După încheierea tuturor pașilor anteriori, ultimul pas este acela de a alege soluția potrivită din punctul de vedere al cerințelor tehnice și business.
În acest pas, rezultatele anterioare și analiza lor sunt prezentate factorilor decizionali.
După parcurgerea tuturor pașilor, soluția aleasă în cadrul procesului nostru de testare a fost Playwright Visual Comparisons.
Fig. 1. Sursa: https://medium.com/@kbalaji.kks/visual-testing-using-playwright-50943c57736a
Playwright este un framework de testare web și automation. El permite execuția de teste prin Chromium, Firefox sau WebKit prin utilizarea unui singur API. Acesta este construit pentru a permite o testare cross-browser capabilă, solidă și rapidă. Principalele motive care au stat la baza alegerii Playwright au fost:
Durata execuției testelor;
Ușurința integrării cu actuala soluție de teste, care folosește tot Playwright;
Pentru a începe este de ajuns execuția unei singure acțiuni în linia de comandă:
npm init playwright@latest, care va genera un set de teste UI și fișierul de configurare specific Playwright.
Pe acesta din urmă va fi nevoie să-l modificăm pentru a ne permite execuția de teste vizuale. Pentru acest lucru va fi necesar să definim următoarele proprietăți:
snapshotPathTemplate;
suprascrierea librăriei de aserții pentru a ne permite definirea unei margini de eroare prin setarea unui număr maxim de pixeli;
Înainte de începerea implementării scenariilor de test, un pas important constă în definirea acestora. Acest lucru va ajuta la stabilirea unei arhitecturi care ne va permite extinderea facilă a scenariilor în viitor.
După ce lista de teste a fost definită și au fost extrase din aceasta testele care vor fi automatizate, se va începe implementarea acestora în cadrul soluției.
Pentru a avea ușurință în a adăuga teste ulterioare, dar și pentru a putea menține o bună performanță a soluției de testare, este preferabilă utilizarea unor scenarii de test cât se poate de granulare care vor valida componente individuale de UI.
Aceasta va ajuta și la citirea rezultatelor de test putând să identifice rapid zona aplicației unde au apărut modificări și să treacă la remedierea acestora.
De asemenea, această granularitate este vitală în a menține complexitatea testelor în cazul în care o componentă UI este afectată. Astfel, granularitatea favorizează izolarea acelor teste de restul suitei, fără a fi nevoie de modificări complexe până în punctul în care diferența semnalată de teste este remediată.
Când scenariile de test sunt gata pentru a fi executate, prima execuție a acestora va crea un set de imagini de bază. Acestea vor avea rol de referință în restul execuțiilor ce vor urma, devenind puncte de validare față de imaginea care va fi făcută în timpul rulării testului.
Pentru o mai facilă gestionare a imaginilor de referință, se pot crea mai multe directoare care să permită organizarea acestora în funcție de sistemul de operare sau de alte aspecte.
O mențiune importantă privind sistemul de operare în acest context al testelor vizuale este legată de faptul că, dacă se dorește execuția de teste între mai multe sisteme de operare, va exista o diferență mică, aproximativ 1 pixel, datorată diferenței de font între sistemele de operare. Această opțiune de a crea mai multe imagini de bază în funcție de sistemul de operare pe care rulează testele reprezintă una dintre soluțiile de a rezolva această inconveniență.
Acest lucru se poate face și prin setarea unei valori pe proprietatea de "snapshotPathTemplate" în interiorul fișierului de configurare al Playwright, prin fixarea unei locații dinamice unde să fie create imaginile în funcție de mai multe aspecte precum platforma de rulare, proiectul de test, numele testului, descrierea acestuia sau calea către fișierul de test.
snapshotPathTemplate:'visual-tests/base-images/{platform}/{testFilePath}/{projectName}-{arg}{ext}'Acest pas este important de definit pentru a putea crea o soluție ușor de întreținut. Fără a fi făcut acest pas, Playwright în configurația de bază va crea un director additional în cadrul celui de test unde vor fi păstrate/actualizate imaginile de bază, ceea ce va genera un grad adițional de complexitate în întreținere, în special în cazul soluțiilor cu o structură complexă.
Integrarea se face la fel ca la orice altă suită de teste care utilizează Playwright, singura diferența este dată de faptul că va fi nevoie să fie specificat fișierul de configurare creat pentru suita de teste vizuale.
El poate fi setat ușor prin adăugarea unui parametru în cadrul acțiunii din linia de comandă.
npx playwright test --config playright.visual.config.tsPlaywright dispune de suport pentru mai multe soluții de raportare precum Allure sau Report Portal. El dispune, de asemenea, și de un raport propriu care este destul de explicit în cazul testelor vizuale, și poate fi ușor de setat în cadrul fișierului de configurare al Playwright.
reporter: [['list'],['html']]În cazul în care există teste care au semnalat o diferență, acesta va genera o pagina HTML care va conține informații referitoare la excepția apărută, pașii de test și o imagine în punctul în care a fost semnalată excepția.
Pentru raportul de teste vizuale vor exista încă trei imagini adiționale:
O imagine care reprezintă imaginea de bază;
Imaginea reprezentând starea în care se află componenta de UI în punctul în care s-a făcut validarea în test;
Pot exista cazuri în care un element pe care le regăsim în UI să sufere modificări, în acest caz e nevoie ca și imaginea de bază să fie modificată conform ultimelor cerințe.
Pentru a putea face acest lucru nu există o cale directă în cazul librăriei de test oferită de Playwright, ci doar prin parcurgerea unor pași cum ar fi:
Ștergerea imaginii existente;
Rularea unui test afectat de modificările de UI, care, la rândul său, va genera o nouă imagine de bază;
Evaluarea manuală a conformității imaginii de bază;
Pentru a ușura utilizarea soluției de către orice membru din cadrul echipei, se poate face o implementare de stocare a imaginilor de unde vor fi folosite sau descărcate în timpul testelor.
Un alt aspect important care poate apărea atât în timpul implementării testelor, cât și în cazul întreținerii acestora, este dat de elementele dinamice din pagină, precum animații de încărcare, cronometre sau bare de progres, care, din cauza naturii lor, este aproape imposibil să aibă aceeași stare în cadrul mai multor iterații de test.
Pentru a reduce riscul unor excepții care pot apărea aleatoriu în timpul execuției testelor sau a validării imaginilor din timpul testului cu cele de bază, există două metode, în funcție de ce componente de UI trebuie validate în timpul testului.
Dacă elementul dinamic nu trebuie să fie luat în considerare în cadrul comparației finale de imagini, el poate fi mascat utilizând o setare expusă în cadrul metodei care ajută în crearea imaginii în timpul testului.
screenshot({mask: [testPage.locator('.class-to-ignore')]}) screenshot({animations: 'disabled'})În concluzie, utilizarea soluției de testare vizuală oferită de către Playwright este una facilă, performantă și ușor de scalat. Aceasta presupune muncă adițională față de alte soluții curente doar în cazul întreținerii imaginilor de bază și a componentelor dinamice de UI.
Agile Craftsmanship
joi, 24 Octombrie, ora 18:30
Colors in Projects (București)
Facebook Meetup StreamEvent YouTubeAgile Leadership &
Ways of Working
miercuri, 30 Octombrie, ora 18:00
ING Hubs Romania (Cluj)
Facebook Meetup StreamEvent YouTubede Nóra Dobre
