In trecut am mai vorbit aici pe blog despre subiecte care au atins diversele tipuri de testare pe care le putem pune in practica atunci cand lucram in IT, fie ca suntem QA sau nu. Am vorbit despre subiectul piramidei testarii automate, care reflecta la modul general cum ar trebui organizata testarea automata, precum si despre Unit testing, primul tip de automation din aceasta schema.

Astazi ne vom uita spre partea superioara a acestei piramide si vom discuta despre un alt subiect de mare interes, dezbatut constant in mediul online printre QAs, si anume testarea end-to-end.

Ce reprezinta testarea end-to-end?

Sintagma ”end-to-end” (E2E) se traduce in mod uzual prin „de la un capat la altul”, fiind folosita preponderent in testare, dar si in alte zone din IT, precum in zona de cybersecurity, unde de exemplu exista conceptul de criptare end-to-end (deci securizata in ambele sensuri).

Testarea end-to-end se refera la verificarea si validarea acelor flow-uri / scenarii in care un utilizator interactioneaza cu mai multe componente ale unei aplicatii si realizeaza un flow mai complex, in care executa diverse actiuni pentru atingerea unui anumit scop de business.

Practic, testarea end-to-end este componenta finala care survine dupa interventia testelor unitare si a celor de integrare, care verifica stabilitatea componentelor de baza in mod individual.

Logica este una structurala. Luand ca exemplu o prajitura, mai intai testam individual fiecare ingredient in mod unitar (zaharul, faina, laptele etc.), apoi testam fiecare componenta mai mare rezultata din integrarea mai multor unitati (crema, blatul, siropul, frisca etc.), iar la final testam rezultatul final, o felie de prajitura din mai multe perspective: aspect, gust, cat de usor se taie sau se mananca, rezultatul combinarii ingredientelor si altele.

Un exemplu tehnic de scenariu care apartine testarii end-to-end ar fi unul legat de un magazin online in care utilizatorul:

1. Se logheaza in contul sau cu username si parola
2. Cauta produsul X in campul de Search al platformei
3. Filtreaza rezultatele oferite dupa cateva criterii (pret, review-uri)
4. Selecteaza un produs
5. Citeste descrierea sa
6. Il adauga in cos
7. Se duce la cosul de cumparaturi
8. Selecteaza finalizarea tranzactiei (eventual introduce un cod de reducere)
9. Completeaza detaliile livrarii (adresa unde sa fie livrat produsul)
10. Initiaza plata
11. Plateste cu cardul
12. Primeste confirmarea pe email.

In acest scenariu avem extrem de multe actiuni diferite, care in prima faza trebuie verificate individual (prin unit testing) si apoi impreuna, in formule combinate care sa valideze scopurile aplicatiei puse la dispozitie pentru utilizatori.

Scopul principal al testarii end-to-end

Scopul testarii end-to-end este deci acela de a testa produsul software in forma sa finala, de a verifica comportamentul majoritatii pieselor integrate in etapele anterioare si mai ales de a valida din punct de vedere a cerintelor de business daca deserveste nevoile clientului in cauza. Degeaba livram o prajitura excelenta cu ciocolata, daca noi trebuia sa livram una cu fructe exotice, exprimandu-ne in aceeasi linie metaforica.

Daca principiul de baza pentru testele unitare si cele de integrare este acela de a verifica (in mod automat) o singura actiune, fara a le combina, in cazul testelor E2E situatia se schimba. Prin definitie, acestea au tocmai rolul de a verifica acele scenarii ce presupun mai multe actiuni, nu doar apasarea unui buton si atat. Aceasta e o distinctie importanta a E2E testing, la care vom reveni mai incolo.

De asemenea, un QA nu trebuie sa fie pasiv si sa testeze doar happy path-urile (adica cele mai evidente scenarii si usecase-uri), ci sa incerce sa fie activ si sa se gandeasca la ce alte cazuri de test pot fi relevante pentru folosirea aplicatiei respective de catre useri. Cu alte cuvinte, un QA trebuie sa incerce sa anticipeze actiunile clientului, pentru a le testa si valida. Iar acest lucru este apanajul testarii end-to-end.

Procesul de E2E are si scopul de a valida din perspectiva cerintelor de business un produs software, nu de a-l verifica ca merge si atat, pentru aceasta din urma functia principala revine testelor automate unitare si de integrare.

Validarea este o etapa extrem de importanta a procesului de testare, fara de care nu putem spune ca un produs este pregatit sa fie livrat clientilor. Un produs care nu face ce se cere sau ce se asteapta de la el este la fel de nociv ca un produs care nu functioneaza din punct de vedere tehnic – ambele sunt inutile in practica.

Bune practici, tool-uri si metrici de urmarire a procesului de E2E testing

Ca sa intelegem si sa ne familiarizam mai bine cu testarea end-to-end, in continuare vom vedea cateva detalii specifice acesteia, pentru a vedea cum anume se poate pune ea in practica si cum ajuta efectiv in cadrul mai largului ciclu de viata al testarii software.

Cateva bune practici legate de punerea in practica a testarii end-to-end ar fi:

• Crearea de testcase-uri in suita proiectului bazat pe cerintele formulate in documentatia produsului, in Acceptance Criteria. Nu trebuie sa scriem testcases doar de dragul de a le scrie, ci cu scopul de a nu uita care sunt functionalitatile principale ale aplicatiei, sa nu le uitam cu alte cuvinte.
• Automatizarea testcase-urilor scrise la pasul anterior. Dupa cum se poate evidentia din exemplul oferit mai sus de scenariu E2E, acestea sunt de regula complexe, lungi si cu multi pasi de executie. Ar fi foarte greu spre imposibil sa le testam mereu manual, la fiecare release, mai ales daca au si un setup premergator mai complicat. De aceea, cheia este automatizarea lor, pe cat posibil.
• Review constant al testcase-urilor si al testelor automate end-to-end. De multe ori, anumit flow-uri devin redundante, inutile pe alocuri sau iesite din uz, motiv pentru care e bine sa se discute si sa se reactualizeze lista lor.
• Concentrarea pe acele scenarii care sunt cel mai probabil de folosit de catre useri. Acest lucru e necesar din motive de timp, o resursa care trebuie gestionata atent in IT. Sigur, pot cu timpul sa apara si alte scenarii care in prima faza pareau secundare si care sa devina integrate in suita de teste automate, dar esenta este sa ne concentram mai intai pe cele mai importante.
• Folosirea de conturi si date de test cat mai apropiate ca realitate de cele care se vor folosi de catre clienti in mediul de Productie. Testarea end-to-end este cea care trebuie sa simuleze cat mai realist din toate punctele de vedere utilizarea produsului in conditii reale, fara alte impedimente si workaround-uri.
• In mod ideal, testarea E2E vine dupa executarea testelor de Unit si Integration. Acestea din urma au rolul sa descopere primele probleme, cele de la nivelul codului, in mod individual, si abia apoi se trec la scenariile mai complexe. Sigur, pot aparea si unele exceptii in functie de contextul specific, dar ordinea principala asta trebuie sa fie: unit, integration, E2E testing.

Dupa cum aminteam mai sus, testele end-to-end sunt de regula mari si complexe, motiv pentru care e bine sa incercam sa le automatizam, pentru a economisi timp si a fi eficienti, atunci cand trebuie validata o iteratie noua.

Pentru automatizarea lor, trebuie sa avem in vedere tool-urile de automation corespunzatoare, care sa ne ajute sa realizam acest lucru. O parte dintre cele mai importante astfel de tool-uri, despre care am mai discutat si aici, sunt (fara a exista o ierarhie intre ele):

• Selenium WebDriver
• Cypress
• Playwright
• Robot Framework
• JMeter (pentru testele de performanta)
• Puppeteer etc.

Daca vrei un punct de plecare spre partea de testare automata, aici sunt 2 cursuri foarte bune pe Udemy adresate incepatorilor: 
1. Testare software (manual si automata) 
2. Testare automata cu Python si Selenium

Exista si cateva metrici utile care ne pot ajuta sa urmarim mai clar procesul de testare end-to-end, pentru a vedea cum decurge aceasta, in ce ritm se desfasoara, care e test coverage-ul si daca sunt probleme de vreun fel. Astfel, putem vorbi despre:

• Numarul de testcase-uri, aici fiind vorba de acele cazuri care acopera flow-urile end-to-end, pregatirea lor dinaintea unei validari si un review constant, pentru a se vedea care mai sunt relevante si care nu.
• Progresul / desfasurarea testarii, care sa ne arate constant ce si cate teste au fost executate, ce status au, ce test coverage s-a realizat.
• Numarul de bug-uri identificate de testele manuale sau automatizate, care sa ne arate care e situatia produsului respectiv, cat de mari sunt probleme identificate si daca pot constitui blockere pentru urmatorul release.
• Durata testarii, sigur fara a pune neaparat presiune pe a face testarea pe repede inainte si a taia ce nu e esential, dar e important sa stim cat dureaza o eventuala verificare si validare, cat dureaza testele automate, astfel incat sa echipele de development sa stie sa isi planifice si ele munca.

E2E testing vs. Unit testing

Exista foarte multe opinii legate de testarea end-to-end, daca e sau nu obligatorie, si daca poate sau nu sa fie lasata deoparte in cadrul procesului mare de testare, bazandu-ne exclusiv pe primele categorii de teste automate, in special pe testele unitare.

Pentru a oferi si la aceasta idee un punct de vedere, trebuie mai intai sa intelegem foarte bine care sunt diferentele dintre unit testing si testarea end-to-end.

Prima deosebire fundamentala dintre cele doua este data de cine se ocupa de aceste tipuri de testare. In mod indiscutabil, testarea unitara este exclusiv in sarcina programatorilor, pe cand testarea de la un capat la celalalt se afla in sarcina inginerilor QA.

De aici deriva in mod aproape organic si a doua deosebire, si anume scopul lor: testele unit au scopul sa verifice codul de baza in mod unitar, individual, sa depisteze problemele „de la firul ierbii”, pe cand testarea E2E are sarcina sa verifice si sa valideze produsul din perspectiva clientului, cat mai aproape de modul in care l-ar folosi acesta, si eventual sa anticipeze anumite flow-uri ce le-ar putea folosi clientii.

O alta deosebire este data de modul cum sunt construite aceste 2 tipuri de teste. Testele unitare in 99,99% din cazuri sunt automatizate, pe cand testele end-to-end pot fi si manuale, si automate. Desigur, in masura in care se poate, se recomanda ca testele E2E sa fie automatizate deoarece sunt lungi si complexe si pot dura prea mult sa fie executate manual, dar depinde sigur de timp si posibilitati.

Tot in aceasta nota, automatizarea testelor unitare poate fi ceva mai simpla si rapida intrucat au un grad mai scazut de complexitate, pe cand cele E2E pot lua ceva mai mult timp. Din punct de vedere al executiei, testele unit pot fi rulate in paralel deoarece ele folosesc date de tip mock, pe cand cele end-to-end folosesc date reale, asemanatoare cu cele  din productie, pot fi rulate rand pe rand, secvential, daca nu sunt mai multe conturi.

Mai mult, o diferenta la fel de importanta este data de limitarile pe care cele doua nivele de testare le au. Testele unitare pot verifica cel mult o bucatica de cod, daca livreaza sau nu un anumit rezultat, insa nu pot depista erori cand vine vorba de imbinarea mai multor componente ale aplicatiei. In partea cealalta, testarea end-to-end implica foarte multe actiuni si subcomponente, in prima faza poate nu evidentiaza clar unde anume la nivelul codului se produce eroarea.

Importanta testarii end-to-end

Dupa prezentarea tuturor detaliilor despre testarea end-to-end, revenim la ideea principala care se discuta constant in spatiul online, in comunitatile tech si de QA: (mai) avem nevoie de testare end-to-end sau ne putem baza doar pe testele automate unitare si de integrare?

In mod evident, sunt opinii si argumente atat pro, cat si contra. In opinia mea, cred ca nivelul testarii end-to-end este unul esential, chiar crucial in desfasurarea unui proces de testare cat mai cuprinzator si care sa conduca la o crestere a calitatii produsului final.

Nu cred ca ne putem baza doar pe unit teste ca sa inlocuiasca testele E2E din simplul motiv ca rolul lor e cu totul altul si nu pot fi intr-atat de complexe incat sa suplineasca modul in care testele E2E sunt gandite tocmai pentru a valida flow-urile mai complexe, apropiate de actiunile clientilor.

Da, procesul de testare poate fi supus discutiei si dezbaterii in cadrul echipei, sa se discute constant despre optimizarea sa constanta, si ce teste sa fie prioritizate. Mereu vor fi mai multe teste unitare, automatizate si care sa verifice intr-o prima faza, chiar pe parcursul development-ului modul in care se comporta codul.

Dar trebuie in final executate si teste E2E, pentru a desavarsi acest proces. Ar fi ca si cum dupa ce am testat fiecare ingredient in parte si am gatit prajitura ceruta, noi nu o gustam deloc, nu ne uitam deloc la ea si o servim direct clientului, lucru care nu e posibil, riscand sa ii livram cele mai „gustoase” defecte.

Astfel, fie ca noi concepem mai multe sau mai putine scenarii end-to-end, fie ca le prioritizam mai mult ca metrici sau nu, sau ca le formulam intr-o maniera mai complexa sau mai simplificata, testarea end-to-end mereu trebuie sa se regaseasca intr-o echipa de development, unde inginerii QA au un rol central cu aceasta deoarece sunt granita dintre cei care concep produsul si clienti.

Nici macar din perspectiva economica, pentru reducerea de costuri financiare sau de timp, nu se justifica renuntarea la testarea end-to-end, deoarece creste exponential riscul de a nu depista la timp bug-uri majore, si care vor costa mai mult pentru a fi reparate ulterior.

Concluzii

In incheiere, testarea end-to-end reprezinta nivelul superior al modelului sintetic de organizare a testarii automate denumite generic Piramida testarii. Ele sunt cele mai putin numeroase comparativ cu testele unitare si de integrare, insa sunt si cele mai apropiate de modul in care produsul poate fi utilizat de catre un client, astfel incat sa valideze cerintele de business.

Aceasta este si functia principala a testarii E2E, de a valida si de a incerca sa anticipeze eventualele scenarii de utilizare ale unui produs software, pentru a depista cat mai din timp eventualele erori si defecte, inainte sa ajunga la utilizatorii finali.

Surse pe subiect

Informatii mai generale sau mai detaliate despre end-to-end testing pot fi gasite pe paginile Guru99, TechTarget, PayProGlobal si BrowserStack.