Trecerea de la testare manuala la cea automata (Automation QA)

Cariera de software tester (QA) poate capata diferite forme in timp, in functie de mai multe variabile: nivelul de cunostinte, nivelul de senioritate, atributii, natura proiectului/ proiectelor, cultura organizationala a companiei etc.

Din punct de vedere al tipurilor de task-uri executate, un punct esential in cariera unui QA este cel al tranzitiei de la testarea in mod manual a functionalitatilor unei aplicatii la automatizarea scenariilor de testare (Automation QA).

Inceputul in testare manuala

Orice lucru trebuie sa aiba un inceput, iar cazul meseriei de software tester/ QA engineer nu face exceptie. Inceputul natural pentru un aspirant al acestei ramuri este pe partea de testare manuala, prin interactiunea directa cu produsele software respective, folosind eventual anumite tool-uri ce nu implica cod.

O formula de inceput aici poate fi jobul de game tester, axat doar pe testarea jocurilor video, sau un job de manual software tester, unde scopul e verificarea produselor soft generalist si executarea sarcinilor de baza (scriere de testcase-uri, raportarea bug-urilor etc).

Tranzitia spre partea de Automation QA

Etapa urmatoare celei de testare manuala este reprezentata de trecerea spre partea de testare automata. Aceasta presupune folosirea instrumentelor de automatizare (limbaje de programare, framework-uri de testare sau tool-uri grafice interactive) pentru a rula in mod automat, fara interventia umana directa, a diverselor feature-uri din aplicatii.

Desigur, dupa cum se poate intui, realizarea acestei tarnzitii nu se face cat am bate din palme. Partea de automation este extrem de vasta si de complexa, sunt foarte multe lucruri de invatat si necesita timp si rabdare.

Ea se diferentiaza in functie de multe variabile, de la interesele personale (ce vrem sa invatam la inceput), la proiectele pe care lucram (ce reguli si tool-uri s-au stabilit de la inceput), si pana la companie in sine (ce resurse pune la dispozitie).

Code vs. Low-Code vs. No-Code Automation

Testarea automata poate fi conceputa cu ajutorul mai multor modalitati generale, care pot fi sintetizate in 3 categorii: (full) code automation, low-code automation si no-code automation.

Prin (full) code automation intelegem varianta “clasica” a acestui tip de testare, si anume scrierea cu ajutorul preponderent al unui limbaj de programare (Java, JavaScript, Python etc.) si al unui framework de testare (Selenium, Cypress, Playwright etc.) acele scenarii de test care ulterior ruleaza si verifica functii.

La polul opus, varianta no-code reprezinta ceea ce ii spune si numele, automatizarea anumitor cazuri de testare dar fara a scrie cod efectiv intr-un IDE, ci prin folosirea unor instrumente cu interfete grafice intuitive, de tip drag-and-drop. Acestea sunt mai usor de folosit, dar nu au aceeasi adaptabilitate precum versiunile full code automation.

La mijloc intre cele 2 categorii mentionate anterior se afla low-code automation. In cazul acesteia, se folosesc cateva comenzi de cod, dar intr-un mod minoritar, deoarece majoritatea actiunilor sunt realizate tot din interfata grafica a tool-ului respectiv, prin drag-and-drop. Un tool care ofera, printre multe altele, si parte de low-code automation este BrowserStack.

Astfel, cand ne decidem ca vrem sa invatam si sa facem testare automata, e important sa avem in vedere si cu ce modalitate sa incepem, ca o etapa premergatoare a acestei tranzitii de la manual QA la automation QA.

Etapele trecerii spre testarea automata

1. Notiunile de programare

Prima etapa in acest proces de tranzitie la partea de automation (versiunea full code, dar extrem de mare ajutor si pentru celelalte) este deprinderea notiunilor de baza in programare. Acest lucru este extrem de important deoarece testele automate sunt in esenta niste bucati de cod care executa anumiti pasi pe care noi, in calitate de QA, ii definim.

Iar pentru a putea gandi, scrie si eventual corecta teste automate, trebuie sa avem cunostinte despre conceptele de baza in programare: variabila, clasa, constructori, obiecte, functii etc.

2. Alegerea unui framework de testare

Dupa ce am inteles si deprins notiunile fundamentale in programare, urmatoarea etapa in acest proces este alegerea unui instrument dedicat cu ajutorul caruia sa automatizam efectiv testele noastre.

Aici plaja de optiuni este extrem de larga, si conteaza din nou ce interese personale avem noi (de exemplu ce limbaj de programare cunoastem), ce framework-uri foloseste compania respectiva in proiecte si asa mai departe.

Invatarea unui framework de testare nu este chiar super simplu si rapid, dar cu rabdare si exercitiu se poate ajunge la rezultate foarte bune prin parcurgerea de documentatii si a diverselor tutoriale. Printre cele mai populare optiuni se numara Selenium, Cypress, Playwright sau WebDriverIO.

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

3. Dezvoltarea unor teste automate proprii

Practica constanta ramane cel mai bun mod de a invata ceva structurat pe termen mediu si lung, iar zona de automation nu face exceptie. Pentru a putea corela notiunile de programare si cele legate de framework-ul de testare ales, e bine sa dezvoltam cat mai multe astfel de scenarii, crescand in timp complexitatea lor.

Nu trebuie sa fie aplicate pe niste produse super complexe, astfel ca putem incepe sa automatizam ceva pe niste site-uri pe care le folosim noi in mod curent (un magazin online, o retea de socializare, un site turistic etc.).

Ulterior, pe masura ce vrem sa facem lucruri din ce in ce mai complexe, vom fi curiosi sa cautam in documentatii cum se face treaba X, si astfel intram in profunzimea acelor tool-uri de automation.

Iar munca noastra poate fi organizata intr-un portofoliu de proiecte de testare automata care sa ne puna in valoare noile skill-uri dobandite, mai ales daca publicam acest portofoliu pe GitHub si LinkedIn.

4. Implicarea in task-urile echipei

Ca sa putem sa facem pana la capat tranzitia spre a fi un automation QA, pasul final este sa punem in practica aceste skill-uri intr-un mediu profesional. Aici exista fie optiunea de a aplica pentru un post dedicat de tester automat, ceea ce poate necesita mult timp, energie si aplicari pentru astfel de job-uri, fie sa incercam, in masura posibilului, sa ne implicam in task-urile de automation ale echipei din care faci deja parte.

Aceasta varianta din urma poate fi mai simpla si abordabil, presupunand ca lucrezi deja in IT, pe o pozitie de testare manuala sau in general una tehnica. Acest lucru ar permite lucrul gradual, de la sarcini mai simple si progresand treptat pana la cele mai complexe, urmand ca in timp sa se definitiveze aceasta tranzitie si sa devii un automation QA “cu acte in regula”.

Desigur, nu e o regula, deoarece in unele companii e posibil ca echipele si ierarhiile sa fie prea stricte si rigide si sa nu se permita astfel de sarcini de munca de tranzitie. Dar ideea merita retinuta si incercata.

Cat dureaza si de ce e importanta tranzitia de la testare manuala la cea automata?

Multa lume se intreaba, in mod firesc, cam cat ar dura acest proces de tranzitie de la testare manuala la automata. Iar raspunsul, ca la multe alte intrebari ce tin de sfera IT in general, este ca depinde.

Nu exista o reteta unica, magica si universal valabila pentru toti oamenii. Pentru unii s-ar putea potrivi mai bine o varianta precum low-code automation, altii sa invete mai rapid notiuni de programare, altii sa mearga mai greu cu intelegerea framework-ului de testare si tot asa.

La intrebarea privind durata, 6 luni poate sa fie la fel de valid ca 2 ani, totul depinde de la caz la caz, insa clar nu e imposibil, iar rabdarea e cheia in aceasta ecuatie. Cunostintele generale de testare (manuala) pot fi de mare folos in acest proces.

Din punct de vedere al carierei, este un pas important trecerea de la testarea exclusiv manuala la cea care automatizeaza scenariile. Din aceasta pozitie cunostintele tehnice vor fi mult mai avansate, vei intelege mai bine cum functioneaza codul in aplicatie si implicit cum apar bug-urile, si vei putea descoperi unele probleme cu ajutorul instrumentelor de automatizare.

Desigur, automatizarea nu trebuie sa fie un scop in sine, ci sa fie corelata cu celelalte metode de verificare pentru a depista la timp bug-uri si a le corecta cat mai rapid, ca sa nu ajunga la clienti.

Concluzii

In incheiere, tranzitia de la pozitia de tester manual la cea de automation QA reprezinta un proces cu mai multe etape si intrebari. Cu siguranta cunostintele de programare sunt de mare ajutor, si trebuie insotite de cunoasterea altor tool-uri si multa practica. Acest proces nu are o durata fixa, poate sa dureze saptamani, luni sau ani, de la caz la caz.

Insa reprezinta un avans important in cariera de QA, deoarece permite cunoasterea in profunzime a unor probleme mai tehnice, car pot fi rezolvate (si) cu ajutorul testarii automate. Scopul final insa este si trebuie sa ramana calitatea finala a produselor software supuse verificarii si validarii.

Surse aditionale

Articol comparativ full code vs. low-code vs. no-code automation

Un articol de pe LinkedIn cu privire la viitorul low-code/ no-code automation