La UiPath dezvoltăm platforma numărul 1 de Robotic Process Automation (RPA), platformă utilizată în prezent de mii de companii din toată lumea pentru a-și automatiza procesele. În mod natural, suntem primii utilizatori ai acesteia. "Roboții" noștri software rulează procese de HR, de achiziții sau care țin de departamentul juridic, ajutându-i pe colegii noștri să se poată concentra pe activitățile cu valoare adăugată mai mare. Totuși, nu numai colegii din aceste departamente beneficiază de serviciile roboților noștri software, ci chiar și echipele de dezvoltare utilizează platforma pentru procesul de software development - orientat către partea de testare. Acest articol dorește să vă arate unul din modurile în care noi ne testăm munca cu propriul produs.
Ecosistemul UiPath este foarte mare, iar o primă împărțire o putem face din punct de vedere funcțional:
UiPath Studio - mediul de dezvoltare (sau IDE-ul). Este platforma bazată pe Microsoft Workflow Foundation în care se creează procesele de business sub forma unor diagrame (asemănător cu Microsoft Visio) și care permite rularea acestor procese. Modul de lucru este simplu: prin acțiuni de tip drag and drop se aleg activitățile care formează procesul, acesta urmând a fi rulat ulterior de roboti printr-o simplă comandă, de exemplu, o apăsare de buton sau un job programat. Activitățile sunt acțiuni care își propun să imite procese simple (uneori și mai complexe) în prezent rulate manual de către utilizatori; spre exemplu, în pachetul de activități pentru Excel găsim: Read Cell (citește celula), Read Column (citește coloana), Write Cell (scrie în celulă), Copy Sheet (copiază tabelul) ș.a.m.d.
Roboții UiPath - execută procesele definite în Studio, imitând utilizatorul. Sunt de două tipuri: supervizați și nesupervizați.
În cele ce urmează, vă vom arăta cum decurge procesul de testare pentru o activitate dezvoltată de UiPath și cum încorporăm roboții în procesul de testare. Ca structură pentru această prezentare vom folosi piramida nivelurilor de testare definită în ISTQB:
Imaginea 1: Piramida nivelurilor de testare
Obiectul prezentului articol îl reprezintă testarea unor activități ce vor fi folosite ulterior în procese construite cu UiPath Studio.
Din punct de vedere structural, șablonul pentru implementarea unei activități conține trei componente dispuse ca proiecte individuale într-o soluție de MS Visual Studio. Prima componentă conține logica de business din spatele activității, fără detalii de implementare a activității propriu zise. Această din urmă sarcină revine celorlalte două componente specifice infrastructurii Workflow Foundation, respectiv o componentă care conține implementarea comportamentului activității, și o a doua care conține implementarea interfeței activității. Odată implementate cele trei componente, activitatea poate fi compilată și publicată pe feeduri de NuGet spre utilizarea în procese.
Acum că am lămurit ce testăm și cum vom prezenta întregul proces, putem începe.
Testele de componentă, implementate în special prin unit teste, cad în sarcina programatorilor. Din punct de vedere funcțional, ele se împart în două categorii:
unit teste pentru logica de business care face obiectul activității;
O parte din testele dezvoltate de programatori ar putea fi catalogate drept teste de integrare, implementate pe infrastructura de unit teste, întrucât pentru a satisface nevoile de testare a funcționalității, ele interacționează printre altele și cu sistemul de fișiere.
Imaginea 3: Testarea unei activități în izolare
Odată trecute testele de componentă, intrăm în tărâmul testerilor. Testele de integrare au loc în timpul sprintului și urmează în mare parte etapele clasice ale unui proces de testing dintr-un sprint Agile sau Kanban: etapa de creare de cazuri de test, de executare a testelor, validarea defectelor iar, la final, testarea regresiilor.
Urmează partea și mai spectaculoasă: automatizarea făcută cu ajutorul RPA. Marele avantaj al automatizării testelor cu RPA îl reprezintă faptul că putem avea siguranța că scenariile automatizate vor reflecta acțiunile reale ale utilizatorilor. Până la urmă, avem de testat activități ce vor fi folosite într-un context de RPA, așa că, ce altă modalitate mai bună de a imita scenariile decât folosind RPA? Pe lângă acest aspect, natura testelor automate oferă contextul perfect pentru a ne îndepărta de modelul clasic (unii ar zice învechit) de testare, cu cazuri de test mari, pline de informații, greu de întreținut, raportare elaborată și de multe ori inutilă, în favoarea unor acțiuni inspirate din Rapid Software Testing: o modelare a obiectului testat bazată pe euristici, o testare mai creativă, orientată pe explorare.
Imaginea 4: Modelul de test pentru o funcționalitate
Imaginea de mai sus reprezintă modelul de test pentru o funcționalitate (Classify Document) după ideea promovată de James Bach, SFDIPOT. Ea presupune descrierea sau înțelegerea produsului în funcție de structură (Structure), funcții pe care le îndeplinește (Functions), date de intrare/ieșire (Data), interfețe (Interfaces), platforme (Platforms), operații pe care produsul le executa (Operations), dependența de timp (Time) - aceasta din urmă nefiind tratată în exemplu, pentru că nu se aplică în acest caz.
Pentru ca beneficiile să fie maximizate, a fost nevoie de o uniformizare a efortului de testare automată la nivelul întregii companii, în toate părțile componente ale produsului. Astfel că, după ce testele trec de review în GitHub, sunt merged în repository-ul corespunzător (testele de activități în repository-ul de activități, testele de Studio în cel de Studio, ș.a.m.d.), de unde vor fi rulate în diverse pipeline-uri din Visual Studio Team Services, pe diferite mașini virtuale cu varii combinații de sisteme de operare:
un pipeline ce rulează de fiecare dată când se face un "merge" - permite depistarea timpurie a problemelor ce pot apărea din mai multe proiecte care formează o componentă și oferă o viziune a legăturilor dintre aceste proiecte.
De asemenea, de-a lungul timpului s-au ridicat o serie de întrebări: cum putem optimiza testele astfel încât să fie scrise într-o manieră data-driven (orientată pe date), cum putem reduce codul duplicat generat de acțiunile necesare înainte și după rularea testelor, cum putem să depanăm mai bine problemele detectate de teste, cum putem exporta mai bine rezultatele. Astfel, s-a creat un cadru de rulare al testelor care permite filtrarea, controlul frecvenței de rulare, generarea de capturi de ecran sau video la apariția unei probleme, și altele.
Mai jos vă prezentăm un exemplu de test automat făcut în UiPath Studio pentru funcționalitatea Taxonomy Manager, un wizard de Studio care permite crearea și editarea de taxonomii (taxonomia este un fișier de tip JSON în care se definesc tipurile de document care urmează să fie procesate și câmpurile de interes pentru fiecare tip). Testele sunt scrise sub forma inspirată din principiile TDD de a scrie unit teste Arrange-Act-Assert (aranjare-acționare-verificare), fapt care ajută la structurarea uniformă a testelor și îmbunătățește lizibilitatea lor.
Intrând mai în detaliu, în secvența Arrange sunt grupate activitățile care nu au impact funcțional: se iau numele și identificatorul testului, se loghează începerea testului și se fac verificările necesare.
Urmează partea de acționare. Aici se efectuează pașii din care obținem rezultatul care va fi verificat: se deschide fereastra Taxonomy Manager, se creează grupul, categoria și tipul de document, iar apoi câmpul de tipul "Name" pe care vrem să-l testăm
Am ajuns și la verificarea rezultatelor, lucru care se face simplu, printr-o activitate de tip If, unde se compară taxonomia obținută în secvența anterioară cu o taxonomie salvată pe disk.
Testele de sistem sunt realizate de o echipă specializată numită (ironic pentru structura în care am ales să prezentăm procesul) echipa de integrare.
Aici, din nou, automatizarea joacă un rol central. Este punctul în care se strâng informații și scenarii automatizate de la toate echipele, iar testele sunt rulate într-o varietate de combinații de componente noi și vechi, pe diverse sisteme de operare. Acum se verifică, spre exemplu, și integrarea corespunzătoare a activităților noastre cu toate variantele de UiPath Studio, cum interacționează cu UiPath Orchestrator și cu un număr mai mare de roboți. Astfel se asigură atât stabilitatea produsului, cât și corecta funcționare și comunicare între numeroasele linii de dezvoltare.
Acest ultim nivel de testare este realizat de consumatori. Problemele sau sugestiile sunt comunicate fie pe forumul UiPath (cel mai folosit forum de RPA la ora actuală) sau pe canalele de suport de pe Slack.
În articolul de față am descris un nou caz în care folosirea tehnologiei RPA dă rezultate concrete și ușor de măsurat. Într-adevăr, în cazul de față automatizarea procesului de testare cu RPA se potrivește ca o mănușă. Încheiem, însă, cu mențiunea că tehnologia RPA este în plină expansiune, iar un cadru pentru a susține testarea automată în mai multe direcții (aplicații web, desktop) va fi disponibil în viitorul apropiat. Ne referim la pachetul de activități de Computer Vision dezvoltat de UiPath, care folosește Machine Learning pentru a identifica componentele unui UI (interfață grafică) într-o manieră similară cu un utilizator, ceea ce va avea un impact major în stabilizarea testelor care interfațează cu UI-uri.
de Ovidiu Mățan
de Ioana Negruț
