Testarea continuă este o sintagmă din ce în ce mai utilizată. Dar oare câți dintre noi știm la ce se referă? Multă lume tinde să o confunde cu testarea automată sau să o considere doar un termen mai evoluat pentru același lucru.
Testarea continuă și testarea automată sunt diferite; dacă veți înțelege diferențele veți fi pregătiți pentru a asigura calitatea aplicațiilor într-o epocă în care testarea tradițională pare să devină irelevantă. Veți fi, de asemenea, pregătiți să faceți trecerea de la rolul reactiv al testării pentru validarea cerințelor la un rol mai proactiv de "inginerie a calității", axat pe protejarea și optimizarea afacerii.
Testarea automată presupune crearea unui artefact menit să testeze o funcționalitate, un caz de utilizare (use case) sau o cerință izolată, conceput pentru a confirma în mod repetat dacă rezultatele reale în anumite puncte de control se potrivesc cu rezultatele așteptate (în funcție de cerința utilizatorului). Testarea automată este efectuată în mod tradițional la nivelul UI prin instrumente de scriere și/sau înregistrare-redare.
Testele de UI necesită constant actualizare pe măsură ce aplicația evoluează. Astfel, dacă aplicațiile se schimbă frecvent, întreținerea testelor devine o sarcină care consumă mult timp. Odată ce sarcinile de întreținere iau amploare, echipele abandonează adesea eforturile de automatizare a testelor și revin la testarea manuală. Puține echipe de testare au reușit să atingă niveluri satisfăcătoare de automatizare a testelor - chiar și în procesele clasice, de tip Waterfall. Cercetarea din industrie arată că nivelul mediu de automatizare a testelor se situează constant în jur de 20% de câțiva ani buni de zile.
Astăzi, schimbările din întreaga industrie necesită mai multă testare, în timp ce automatizarea testării este mai dificil de realizat prin instrumentele și metode tradiționale. Arhitecturile de aplicații sunt din ce în ce mai distribuite și mai complexe, cuprinzând cloud, API-uri, microservicii etc., și creând combinații practic nelimitate de protocoale și tehnologii diferite într-o singură tranzacție. Datorită evoluțiilor din Agile, DevOps și Continuous Delivery, multe aplicații sunt acum lansate și updatate unele o dată la două săptămâni, altele chiar de câteva mii de ori pe zi. Ca urmare, timpul disponibil pentru proiectarea, întreținerea și, în special, pentru execuția testelor, scade dramatic. Acum, când software- ul a devenit interfața primară a afacerii, o eroare a aplicației este un eșec al afacerii, și chiar o scăpare aparent minoră poate avea repercusiuni grave, dacă influențează experiența utilizatorului.
Testarea continuă este procesul de executare a testelor automate, ca parte a procesului de livrare a software-ului, pentru a obține cât mai rapid posibil și continuu feedback cu privire la riscurile de afaceri ale unui potențial candidat pentru lansare în producție (release candidate). Aceste informații pot fi apoi utilizate pentru a determina dacă software-ul este gata să progreseze prin procesul de dezvoltare la un moment dat.
Testarea continuă se concentrează pe riscul afacerii și oferă o perspectivă asupra deciziei de a lansa sau nu release-ul. Pentru a realiza această schimbare, trebuie să încetăm să ne întrebăm: "Am testat suficient?" și, în locul acestei întrebări, să ne concentrăm pe întrebarea: "Are release candidate- ul meu un nivel acceptabil de risc pentru afacere?"
Principalele diferențe dintre testarea continuă și testarea automată pot fi grupate în trei mari categorii: risc, amplitudine și timp.
Businessurile de astăzi nu numai că au expus multe dintre aplicațiile lor interne utilizatorilor finali, dar au dezvoltat, de asemenea, cantități mari de software suplimentar care extinde și completează aceste aplicații. Expunerea la utilizator a mai multor funcționalități inovatoare este acum un diferențiator competitiv, dar, de asemenea, crește numărul, varietatea și complexitatea potențialelor puncte de defectare. "Erorile de software" de scară largă au consecințe atât de grave asupra afacerii încât riscurile legate de aplicații sunt acum componentele proeminente ale rapoartelor financiare ale afacerilor.
Pentru a aborda provocările legate de risc, testerii ar trebui:
să înțeleagă riscurile asociate portofoliului complet de aplicații;
să mapeze riscurile cu componentele și cerințele aplicației, care sunt apoi asociate testelor;
să creeze o colecție de teste care atinge cea mai mare acoperire a riscurilor posibilă cu cel mai mic număr de testcase-uri;
Chiar dacă o afacere reușește să evite erori de software de scară largă, care ajung pe prima pagină a ziarelor, chiar și apariția unor greșeli minore poate provoca probleme în zilele noastre. Dacă oricare din părțile experienței utilizatorului nu reușește să-și îndeplinească așteptările, nu numai că riscați să pierdeți acel client în favoarea unui concurent, dar, de asemenea, puteți risca daune de imagine a mărcii, dacă acel utilizator decide să-și expună problemele pe rețelele sociale.
Pentru a răspunde provocările legate de amplitudine, testerii ar trebui:
să poată defini și executa teste End-To-End, care testează aplicația din perspectiva utilizatorului;
să asigure suport integrat pentru toate tehnologiile implicate în tranzacțiile cu utilizatorii cheie (web, mobil, API, SAP și pachete de aplicații etc.);
să folosească virtualizarea serviciilor pentru a simula componentele dependente care sunt necesare pentru a efectua tranzacții complete End-To-End, dar nu sunt disponibile sau configurabile pentru testare repetitivă;
să genereze și gestioneze datele de testare pentru a se asigura că testele (și componentele serviciilor de virtualizare) sunt populate cu date realiste și valabile, la fiecare executare a testelor;
Acum, când viteza cu care organizațiile livrează software-ul a devenit un diferențiator competitiv, marea majoritate a organizațiilor se îndreaptă spre Agile și DevOps pentru a accelera procesele lor de livrare a software-ului. Acum, când procedurile Agile devin normă, testarea trebuie să înceapă în paralel cu developmentul. Dacă organizația dvs. a adoptat Agile, DevOps și efectuează Continuous Delivery, software-ul poate fi lansat la fiecare oră sau chiar mai frecvent. În acest caz, feedbackul la fiecare etapă a procesului nu poate fi doar "rapid"; trebuie să fie aproape instantaneu.
Pentru a aborda presiunilor legate de timp, testerii ar trebui:
să poată identifica care teste sunt esențiale pentru abordarea riscurilor de vârf;
să poată defini și dezvolta rapid testele deoarece aplicația este modificată constant;
să execute testarea la nivel API (de circa 100 de ori mai rapidă decât cea de UI);
să integreze testarea în procesul de livrare a produsului software;
să asigure execuția distribuită a testelor pe mai multe mașini virtuale, calculatoare de rețea sau în cloud;
În concluzie, testarea continuă înseamnă mai mult decât testarea automată, este o evoluție, un increment al acesteia (de aici și titlul articolului) care necesită eforturi considerabile și schimbări semnificative. Este important să admitem că în momentul actual nici un instrument sau tehnologie nu oferă instantaneu testarea continuă și că, precum Agile și DevOps, aceasta impune schimbări în rândul oamenilor, proceselor și tehnologiei. Vom aborda instrumentele actuale în articolul următor.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
