Ce face un tester (QA) la job?

Dupa cum am mai mentionat si in articolele precedente, testarea software este una dintre ramurile principale din cadrul industriei IT, iar un tester (QA) are un rol fundamental in procesul de dezvoltare a produselor software (SDLC).

De multe ori insa, imaginea publica, generala despre munca unui QA si despre ce face el concret la job este putin distorsionata. Fie din necunoastere sau din lipsa de interes, munca unui tester este fie minimizata ca importanta, fie exagerata in cantitate. Evident, lucrurile sunt nuantate, asa ca in continuare vom vedea ce face un tester (QA) intr-o zi de lucru, ce atributii are si cat de mult testeaza efectiv produsele software.

Cum arata o zi de lucru pentru un QA

Ca o observatie de bun-simt, trebuie sa mentionam de la inceput ca pentru un QA nicio zi nu seamana cu alta. Activitatile pe care se concentreaza si sarcinile de lucru sunt extrem de variate si pot sa se schimbe in functie de ce se prioritizeaza, astfel incat intr-o zi poate face sarcina X, a doua zi sa nu mai continue nimic cu X si sa faca Y.

Activitatile unui software tester sunt destul de diversificate, prin comparatie de exemplu cu ce ar putea sa faca un game tester, unde diversitatea sarcinilor nu e la fel de mare, si atunci munca este mult mai repetitiva (de exemplu: sa testeze aceeasi misiune dintr-un joc toata ziua).

Astfel, activitatea unui tester (QA) se poate structura pe mai multe lucruri intr-o zi, dupa cum urmeaza.

Analiza si documentarea cerintelor tehnice

Atunci cand se discuta despre aducerea unor imbunatatiri sau adaugarea unor noi functionalitati (improvements / stories), cei din echipa de testare trebuie si ei sa se documenteze despre ce vor presupune acestea.

De aceea, in vederea pregatirii testarii propriu-zise, un QA citeste documentatia tehnica despre noile adaugiri (daca e sistematizata in scris undeva), cauta sa inteleaga criteriile de acceptare (Acceptance Criteria) pentru acele functionalitati.

Ideal, discuta eventual cu programatorii sau cu cei din zona de management (ex: cu Product Owner-ul) pentru a intelege conceptual cum ar trebui sa functioneze / arate noile lucruri sau produse dezvoltate, ca o etapa premergatoare verificarii si validarii.

Sedinte, sedinte, si iar sedinte…

Nelipsite din nicio companie de IT, din niciun departament, si din nicio echipa sunt sedintele. Desigur, acestea sunt necesare, nu se poate lucra in echipa (sau pe mai multe echipe) daca nu exista sedinte de lucru unde sa se discute deschis si sa se comunice probleme si solutii.

Dar chiar si asa, numarul lor tinde mereu sa fie unul mare. Un tester participa in multe sedinte, unele necesare, in altele mai mult din obligatie. Metodologia Agile aplicata cu framework-ul Scrum organizeaza munca in sprinturi de 2 saptamani, iar asta presupune si multe sedinte.

Acestea de regula sunt concentrate la inceputul sprintului, cand se planifica si se estimeaza noile task-uri de lucru, si la finalul acestuia cand se trage linie, se discuta ce poate fi trecut in urmatorul sprint, exista de regula si o sedinta de analiza retrospectiva a sprintului (ce a mers bine sau ce ar merita imbunatatit).

Pe langa acestea, sunt si multe sedinte in cadrul echipelor, unele sedinte pot fi mai degraba ad-hoc, atunci cand un QA discuta cu un developer despre un bug mai complex de exemplu, sau cu unii clienti. Recordul meu personal pana acuma a fost de 5 (da, cinci) sedinte intr-o singura zi de lucru, care au insumat putin peste 2 ore.

Timpii (aproape) morti

Intr-un mod inevitabil apar frecvent si acele perioade scurte in care nu apuci sa faci nimic din ce aveai planificat sa lucrezi, nu neaparat ca nu ai vrea, dar pur si simplu se intampla alte lucruri care modifica programul.

Printre exemplele frecvente care conduc la timpii morti sunt sedintele care se prelungesc destul de mult din cauza lucrurilor discutate (trebuia sa dureze 30 minute si tine peste 1 ora), sau atunci cand pentru a completa un task ai nevoie de anumite informatii de la un coleg, dar acesta nu raspunde imediat la mesaj si trebuie sa astepti, pentru ca fara nu poti continua.

In alte cazuri, intre doua sedinte este o pauza de 10-15 minute, dar in care nimeni nu apuca sa faca nimic de lucru, ci mai mult e o pauza de relaxare. Alteori specificul unor teste necesita un astfel de repaus fortat, de exemplu daca una din conditii sau un anumit pas este sa pui computer-ul in Sleep Mode timp de 30-60 minute.

Scrierea de cazuri de test (test cases)

Una dintre activitatile de baza pentru un tester este gandirea si elaborarea de cazuri de test (test cases) pe baza carora sa se ghideze cel putin formal atunci cand testeaza un anumit produs, sau o functie nou dezvoltata.

Unele cazuri de test se pot dezvolta intuitiv, simuland experienta pe care ar trebui sa o aiba utilizatorul, unele sunt scrise pe baza cerintelor din Acceptance Criteria, altele pe baza unor bug-uri descoperite anterior.

Test case-urile au importanta lor evidenta, insa testarea in sens larg nu trebuie sa se rezume doar la urmarirea acestora, daca produsul bifeaza cerintele tehnice si atat. Privirea de ansamblu si incercarea unor scenarii la care nu se gandeste oricine ar trebui sa caracterizeze, de asemenea, procesul de testare, pentru o verificare cat mai temeinica a calitatii finale, iar un QA sa propuna sugestii de imbunatatire a produsului final.

De obicei, cazurile de test sunt printre primele sarcini de lucru de la inceputul unui sprint, pentru a fi pregatite atunci cand functionalitatea cea noua va fi finalizata de catre programatori si gata de testare.

Raspunsul la mesaje

Dupa participatul la sedinte, probabil a doua activitate indirecta pe care un tester o face recurent (ca de altfel aproape toata lumea din IT) este sa trimita si sa raspunda la mesaje, pe email sau in anumite grupuri de lucru.

Aici nu exista nicio regularitate, poate sa treaca o zi intreaga si sa fi primit doar 2 email-uri, sau se poate intampla sa primesti 10 mesaje de la 10 persoane in 2 ore… Ritmul de lucru nu este mereu (de fapt, cam niciodata) unul extrem de ordonat, sa stii precis cand primesti un mesaj, cand scrii un email.

Multe se succed una dupa alta, de aceea skill-ul general de time management este foarte important pentru un QA, pentru a sti cum sa isi organizeze treaba cat mai bine, si sa nu iroseasca timpul avut la dispozitie.

Testarea efectiva si raportarea de bug-uri

In sfarsit, ajungem la ce cred multi oameni ca face un tester (QA) 8 ore pe zi, si anume testarea produselor software si raportarea de bug-uri. Lasand ironia deoparte, chiar daca aceasta este una dintre sarcinile sale fundamentale din fisa postului, un tester nu va face niciodata doar asta timp de 8 ore pe zi.

Motivele se regasesc si in paragrafele anterioare: apar foarte multe activitati pe langa munca de testare propriu-zisa, de la discutii, analize de cerinte, pana la sedinte si email-uri. Acestea sunt la fel de necesare, pentru ca munca in IT este una de echipa in cea mai mare parte, iar comunicarea este esentiala, in diferite forme.

Insa chiar si asa, verificarea si validarea produselor software, precum si raportarea defectelor tehnice nu este deloc preponderenta intr-o zi normala de munca pentru un tester, nu pentru ca nu ar vrea, ci pentru ca sunt multe alte lucruri de facut in acel interval de timp.

Uneori unele bug-uri depistate sunt destul de complexe iar rezolvarea lor necesita mai mult timp, mai multe discutii tehnice. Alteori apar alte lucruri prioritare in program si lansarea unor noi functionalitati pentru testat se lasa asteptata. Una peste alta, esenta este ca un QA nu sta 8 ore in continuu testand si scriind rapoarte pentru defectele identificate.

Automatizarea testelor

O alta sarcina de lucru extrem de importanta mai ales pentru testerii care cunosc programare si framework-uri speciale este aceea de a automatiza anumite teste si scenarii de testare. Si acesta este un task destul de frecvent, dar care nu se realizeaza chiar in fiecare zi.

De multe ori, mai intai se scriu cazurile de test pentru functionalitatea respectiva, se testeaza mai intai manual, pentru a intelege exact ca un user cum functioneaza (si cum nu ar trebui sa functioneze), si apoi se automatizeaza cu un framework special, precum Cypress, Selenium, Playwright etc.

Desigur, nu toate cazurile de test pot fi automatizate, si in acest sens se face o analiza si o selectie riguroase de catre echipa de testare.

Pauzele…cheia marilor succese

Bineinteles, intr-o zi de munca din IT, inclusiv in testare, nu lipsesc pauzele. Acestea, dincolo de glumele aferente, sunt necesare pentru orice om. In primul rand, dupa 1.5 – 2 ore petrecute in fata calculatorului, un QA sau programator trebuie sa faca o scurta pauza pentru a-si odihni ochii, adica sa nu isi concentreze atentia acum pe telefonul mobil. Si spatele trebuie relaxat dupa un timp lung petrecut in scaun, pentru a preveni aparitia durerilor.

De asemenea, la pranz de regula este o pauza de masa de 30-60 minute, un timp foarte bun pentru a mai socializa cu un coleg sau de a mai bea o cafea. Pauzele au si rolul de a odihni mintea, astfel incat aceasta sa poata reveni si sa gaseasca noi solutii la problemele pe care le avem de rezolvat la job, desigur fara a exagera.

Mentenanta testelor si a documentatiei

Un alt aspect de care se mai poate ocupa un software tester este acela ca regulat face mentenanta cazurilor de test. Mai precis, la cateva saptamani / cateva sprinturi, are loc o reevaluare a cazurilor de test si a testelor automate.

Acestea pot fi updatate in functie de noile conditii tehnice dezvoltate, pot fi subimpartite daca situatia o cere sau pot fi sterse cu totul, daca sa zicem functionalitatea respectiva a fost eliminata cu totul din produs. Si testele automate trec constant printr-un proces de mentenanta, fie sunt dezvoltate, unele sunt sterse, la unele se modifica datele de testare si asa mai departe.

Aceasta activitate, chiar daca nu e una care sa se intample extrem de des, este necesara, pentru a pastra actualizate suitele de cazuri de test, si de a nu pierde timpul printre lucruri care sunt scoase din uz (deprecated). La fel si documentatia tehnica trebuie reactualizata si dezvoltata, daca e cazul.

Concluzii

In incheiere, ziua de lucru pentru un tester (QA) este destul de diferita de la caz la caz, existand o multitudine de activitati pe care acesta le poate face, sau lucruri la care este obligat sa ia parte, precum numeroasele sedinte. Insa in mod aproape sigur, un software tester nu va petrece niciodata 8 ore pe zi doar testand lucruri si raportand bug-uri.

Timpul este de multe ori fragmentat de multe alte task-uri, sedinte, mesaje, pauze sau alte activitati specifice testarii. Insa tocmai aici este provocarea faina oferita de ramura testarii, si anume cum sa gestionezi cat mai eficient timpul de lucru, astfel incat sa existe o calitate cat mai mare a produselor la finalul procesului.