Poate că unii dintre voi vă întrebați de ce am ales acest titlu. Răspunsul scurt este că nu sunt prea mulți testeri care să-și dorească să învețe programare, deși aceștia ar prefera testarea automată în locul celei manuale. Dar am o veste bună! Cu toate că pare dificil la început, testarea automată fără programare este posibilă, iar acest lucru se poate realiza utilizând testarea bazată pe modele, în care testerul creează modele pentru controalele pe care dorește să le utilizeze. De exemplu, într-o aplicație web, un model pentru teste și un model pentru date. Prin urmare, ca expert în testarea bazată pe modele, la NTT Data Romania, doresc să vă împărtășesc din experiența mea.
În primul rând, trebuie precizat că nu putem vorbi despre testare automată care să nu utilizeze deloc programarea. Conform Tricentis, Tricentis Tosca este o platformă de testare continuă ce accelerează testarea pentru a ține pasul cu Agile și DevOps. Utilizând cele mai inovatoare tehnologii de testare funcțională, Tricentis Tosca sparge barierele uneltelor convenționale de testare software.
Mai concret, Tricentis Tosca este o aplicație ce permite scrierea de teste utilizând funcționalitate de tip drag-and-drop, ce stochează și gestionează datele de test, ce execută teste automate sau manuale și care generează rapoarte. În acest fel, se acoperă o mare varietate de sisteme ce pot fi testate: web, desktop, mobil, cu suport avansat pentru tehnologiile Java FX, SAP, .Net sau HTML. De asemenea, oferă posibilitatea testării bazate pe imagini (image-based testing), dar și suport pentru tehnologii non-UI (API). Desigur, Tricentis Tosca poate fi extins pentru a facilita și testarea sistemelor BI precum și load testing. Toate acestea sunt posibile după doar câteva săptămâni de training, spre deosebire de testarea automată tradițională ce utilizează OOP și programare, care necesită o perioadă de instruire de o mai lungă durată. Din toate aceste motive, Tricentis Tosca este o unealtă cu adevărat impresionantă.
Totuși, să nu ne lăsăm purtați de val și să vorbim despre aspectele evidente ale testării bazate pe modele: mai întâi trebuie create modele ale obiectelor ce vor fi folosite în test. De exemplu, să zicem că vrem să automatizăm o simplă căutare pe Google, din rațiuni SEO, de exemplu.
Acest lucru presupune că trebuie mai întâi să creăm un model al elementelor ce vor fi folosite. Acest lucru înseamnă scanarea paginii de start din Google pentru a identifica elementele pe care dorim să le folosim. De exemplu, caseta de căutare (search input box). Identificarea unui element web se face utilizând cunoștințe de HTML de bază, întrucât cunoștințe mai avansate de HTML sunt necesare doar dacă aplicațiile web sunt complexe sau problematice. Pe scurt, fiecare element cu care interacționăm se numește control, deci fiecare control HTML- dar nu numai - este modelat într-un control mapat pe Tosca.
Al doilea aspect evident al testării bazate pe modele este că testele consumă modelele obiectelor care determină acțiunea sau interacțiunea, implicația fiind că testele doar consumă modelele. Deci, până acum avem: elemente web mapate pe controale și incluse în module, precum și teste ce conțin controale abstractizate. Poate părea dificil la început, dar este logic să avem containere pentru modele, iar aceste containere se numesc module. De exemplu, un modul login conține numele de utilizator și parola drept câmpuri, împreună cu butonul de login și, poate, linkul pentru recuperarea parolei uitate. Acest construct are sens, în timp ce un construct unde fiecare controler are propriul modul nu are sens cu excepția situației în care vreți să aveți de-a face cu o complexitate zdrobitoare.
Mai mult, testele în sine sunt abstractizări ale unor colecții de module. Așadar, pentru a putea monitoriza unde se află fiecare element, trebuie să înțelegem cum utilizează Tricentis abstractizările:
Controalele aplicației sunt mapate pe controalele Tosca, controalele aplicației sunt abstractizate în controalele Tosca.
Controalele Tosca se află în colecții numite module, acest nivel de abstractizare permițând reutilizarea controalelor.
Al treilea aspect evident al testării bazate pe modele este că datele pot fi - și de obicei chiar sunt
- modelate, implicația fiind că testele utilizează atât modele de obiecte, cât și modele de date, ceea ce are sens deoarece în testare avem aproape mereu obiecte ale aplicației și date de test. Este același lucru. Dar lucrurile merg mai departe de atât. Din moment ce utilizăm abstractizări pentru controale și pentru date, de ce să nu folosim și pentru teste, pentru a permite crearea de teste automate?
Implementarea este următoarea: crearea unui template/ tipar de test și furnizarea de date de test către acesta duce la instanțierea testului propriu-zis. Deci, template + fișa de date de test = instanțe de teste, deoarece un tipar/ template conține instanțe ale datelor conținute în fișa de test, ceea ce face ca numărul de teste să fie egal cu numărul de instanțe existente în foaia de date de test. Așadar, un test este creat din date de test, pe baza unui tipar/ template, în timp ce un tipar/ template de test este un model generic - o abstractizare - pentru teste.
Dar lucrurile sunt mai profunde decât ar părea la prima vedere, deoarece abstractizările ne permit realmente să scriem teste pentru multe tipuri de aplicații, nu doar web. În exemplul din video-ul de mai jos, vom crea infrastructura de test utilizând controale pe baza imaginilor, de exemplu pentru aplicații ce rulează pe VDI.
În concluzie, este fezabil să scriem teste automate fără utilizarea efectivă a unui limbaj de programare. Aceasta se aplică nu doar pentru aplicațiile web, ci și pentru aplicațiile mobile, API/ OSV și chiar aplicații desktop, păstrând totodată un mod de gândire mai puțin tehnic, dar introducând viteza testelor automate cu efort minim și nivel calitativ ridicat.
Evident, există și anumite trucuri pe care le-am folosi pentru a ne face testarea mai ușoară dar, sincer, ce poate fi mai frumos decât să faci testare automată fără programare?
de Mircea Vădan
de Emilia Toma
de Melania Duma
