Dupa mai bine de 2 ani si jumatate, iata ca am ajuns la articolul cu numarul 100 semnat pentru Blog De IT, dorind sa multumesc tuturor celor care au citit si apreciat articolele de pe site. Cu aceasta ocazie, pentru subiectul acestui articol m-am gandit sa abordam un subiect ce a revenit constant (ca sa fiu ironic, nu cred ca a disparut niciodata) in discutiile de pe LinkedIn (un exemplu), forumuri si bloguri dedicate IT-ului.

Astazi discutam despre recurenta intrebare care (mai) este rolul unui QA in industria IT de astazi? Mai are QA-ul vreun rol fundamental intr-o echipa de dezvoltare software, sau a devenit acea piesa complet dispensabila la nevoie, pentru ca „nu ne ajuta” sau e „prea scump”? Reluam aceasta dezbatere in continuare, sa vedem cum stam.

Manifest pentru calitate

Dincolo de celebrarea a 100 de articole pentru blog, motivatia scrierii acestuia articol este aceea de a aduce din nou in prim planul discutiei ideea ca un produs software trebuie sa treaca prin mai multe etape obligatorii inainte de a fi trimis catre clienti (SDLC).

Acesta trebuie atat verificat, sa ne asiguram ca functioneaza, dar si validat, adica ca functioneaza cum trebuie, in acord cu ce s-a cerut sa se faca. Cu alte cuvinte, ideea acestui articol se doreste a fi un manifest, o pledoarie pentru calitatea produselor software, calitate care sigur ca se manifesta in multe aspecte, dar unde QA-ul are un rol esential.

De foarte multe ori am observat ca multi oameni, fie aflati la inceput de drum in IT sau care aveau deja foarte multa experienta pe anumite pozitii, nu cunosc care ar trebui sa fie rolul adevarat al unui QA si atributiile sale in contextul unei industrii IT puternic afectata in ultimii ani, si dupa integrarea treptata a unor noi tehnologii relativ noi precum AI-ul. Raspunsuri simpliste precum “da click-uri in aplicatie” sau “raporteaza bug-uri” sunt cu totul insuficiente raportat la adevaratul sau rol.

De aceea, in continuare vom relua acele idei care se pierd in legatura cu rolul de QA si care ar fi consecintele relativizarii si minimizarii ariei de Quality Assurance, mai intai in mentalul public si apoi la nivelul domeniului.

De ce este si va fi nevoie de QA in industria IT?

Sa o luam cu inceputul, si sa pornim cu intrebarea de ce este nevoie de testeri si ingineri QA (manual sau automation, nu conteaza) in cadrul companiilor care dezvolta diferitele produse software si/sau hardware pentru multiplele categorii de clienti. Aici cel mai usor de inteles raspuns poate fi dat prin a ne gandi la principalele diferente dintre QA si ceilalti oameni care lucreaza la dezvoltarea produsului, cu precadere programatorii.

Acest lucru survine tot din faptul ca majoritatea opiniilor care zic ca nu mai avem nevoie de QA dedicati care sa se ocupe de testare si calitate se bazeaza pe argumentul ca programatorii pot ei sa testeze in loc, sa verifice acel produs sau feature prin diferitele Unit teste scrise chiar de programatori sau sa verifice ei din perspectiva celorlalte tipuri de testare: sa verifice UI-ul, performanta sistemului, cat de usor se integreaza toate piesele sale si ce experienta (UX) ofera in final utilizatorilor.

Aceasta parte sustine si relativizarea implicita a testarii prin faptul ca ea poate fi integrata putin cate putin in toate etapele procesului de dezvoltare software (idee corecta in esenta, la care voi reveni mai jos), si astfel nu mai e nevoie de QA dedicati si pregatiti special in acest sens, simplificand considerabil procesul de dezvoltare si de livrare a respectivului feature.

Principala diferenta intre un QA si un programator de unde deriva si modul in care primul reuseste sa fie mult mai constient de eventualele probleme si riscuri ale produsului respectiv este mindset-ul. Mentalitatea unui programator este una focusata exact pe bucatica pe care lucreaza el, sa iasa bine acel cod si sa isi doreasca sa mearga. Desigur, sunt si exceptii care incearca sa aiba o viziune mai de ansamblu, dar sunt relativ rare.

Prin comparatie, mentalitatea unui QA porneste de la cea a unui potential client, trebuie sa fie constient de produs ca un intreg, unde toate componentele trebuie testate. De aici, un QA trebuie sa aiba un fel de scepticism fata de ceea ce se zice ca „ar functiona” in aplicatie, si sa puna la indoiala acest lucru pana cand nu realizeaza o testare proprie, cat mai aplicata. Cu alte cuvinte, sa demonstreze mereu o gandire critica aplicata la produsul testat.

A doua diferenta este ca un QA are rolul de a incerca sa se transpuna intr-un client care este nevoit sa foloseasca aplicatia sau componenta respectiva, si atunci trebuie sa gandeasca in avans ce anume ar putea sa nu functioneze, unde ar putea aparea probleme de intelegere sau functionare, si sa previna – un atribut esential – acele probleme prin raportarea lor de dinainte.

Aceasta nevoie, a acestui mindset de QA nu poate fi inlocuita de alte categorii de job-uri in IT, pur si simplu pentru ca nu acela este rolul lor. E ca si cum la fotbal am renunta la portar si am delega rolul ultimei aparari fundasilor, doar pentru ca joaca si ei in treimea proprie si sunt oricum focusati pe faza defensiva.

Un programator poate fi biased fata de codul sau si sa incerce mereu in a convinge ca merge (pana la proba contrarie), insa un QA trebuie sa aiba acea „atitudine sceptica a unui pesimism profesional”, dupa cum zice literal manualul ISTQB, care sa ii spuna mereu ca pana nu arunca un ochi si nu face niste minime teste, acolo se pot ascunde bug-uri severe.

Aceasta discutie a fost intretinuta si de propagarea in spatiul public a diferitelor forme de marketing a unor scoli de IT sau mentori, care au sustinut perpetuu ca „testarea este calea cea mai usoara de a intra in IT” (nu-i asa ca ati auzit si voi asta de multe ori?). Acest lucru i-a facut pe multi oameni sa creada ca oricine, indiferent de skill-uri si pregatire, poate deveni QA, iar testarea poate fi realizata de absolut oricine, lucruri ce nu sunt adevarate in mod absolut. Chiar daca nu e nevoie de cele mai inalte studii pentru a deveni QA, este nevoie de o pregatire corespunzatoare inainte, iar testarea software, daca e facuta pe bune si cu responsabilitate, nu e asa usoara cum se tot transmite in spatiul public.

Cu un lucru pot fi de acord din ce transmit cei care zic ca pot functiona foate bine fara QA: calitatea trebuie sa se regaseasca in fiecare etapa a procesului de dezvoltare software, de la discutarea teoretica a cerintelor de business, pana la codarea propriu-zisa, si pana la release-urile finale, chiar si dupa.

Ea este un proces continuu si nu trebuie sa cadem in capcana ca se executa in bloc dupa ce s-a codat tot ce era nevoie, ca in modelul Waterfall. Un QA bun trebuie sa isi faca simtita prezenta in toate etapele ciclului de viata al dezvotarii software, sa puna intrebari si sa discute cu toti actorii echipei.

Sarcinile si atuurile unui QA intr-o echipa

Acum ceva timp am scris un articol dedicat aici pe blog in care am descris la modul foarte general ce face un QA la job intr-o zi. Aceste lucruri sunt perfect adevarate si reprezinta acele atributii standard, de manual, pe care un QA trebuie sa le faca pentru a-si putea face treaba.

Insa acestea nu sunt singurele, iar in spatele lor stau de fapt acele mici actiuni care diferentiaza o echipa ce pune pret pe calitate de una care vrea doar sa livreze cat mai mult si cat mai repede catre clienti, dar nu mereu si ce e mai bine.

O prima sarcina sa zicem asa informala a unui QA care se dovedeste a fi un atu pe termen lung intr-o echipa este aceea de a pune intrebari despre un produs sau feature, cat mai multe intrebari care sa clarifice existenta dezvoltarii lui. In spatele oricarui banal „de ce asa?” sau „cum va functiona chestia X?” sau „ce legatura va fi intre componenta asta si Y?” se pot ascunde detalii care sa faca diferenta intre un feature nefunctional, plin de bug-uri ori inutil, si unul util clientilor care chiar sa aduca valoare pentru acestia.

De regula, programatorii care se ocupa de feature-ul X vor fi interesati strict de ce are legatura cu acesta, ca sa stie cum sa il dezvolte, dar QA-ul trebuie sa vina cu intrebarile referitoare la integrarea tuturor componentelor. Cand ceva nu e clar despre un anumit AC al unui feature, imediat un QA trebuie sa mearga si sa intrebe, sa discute cu partile implicate (programatori, product owner, product managers etc.) ca sa lamureasca cum va testa si cum va functiona acea parte.

Acest lucru desi poate parea banal este de fapt esenta dezvoltarii unui produs. Aceste discutii aduc mai multa valoare decat scrierea codului in sine. Asa cum mi s-a zis de multe ori in acest rol, daca noi in calitate de QA nu stim cum functioneaza un anumit produs, nu putem avea pretentia de la clienti nostri ca vor stii acest lucru, asta fiind o lectie foarte valoroasa.

O a doua sarcina super importanta deriva din ceea ce am zis mai sus, si anume mindset-ul de client. Un QA interesat de munca lui trebuie sa inteleaga in ansamblu un produs ce face, cum il va ajuta pe client, cat de intuitiv e de folosit, nu doar sa stie ce face un buton de pe o pagina si atat. Aceasta viziune de ansamblu este cruciala, pentru ca asa un QA devine legatura intre partile ce se dezvolta pentru un produs in cadrul unei echipe.

De asemenea, rolul unui QA este si acela ca in anumite momente, justificate desigur, sa aiba curajul sa iasa si sa zica „nu”. Iar aici ma refer mai exact la acele situatii cand din dorinta de a livra cat mai mult si cat mai repede catre clienti, ca acestia sa fie cat mai satisfacuti ca primesc lucruri noi si sa plateasca in continuare pentru serviciile companiei, exista riscul ca tocmai calitatea produsului sa fie sacrificata. Iar aici intervine QA-ul, sa vina si sa zica ca exista riscuri majore care fara o testare temeinica (caci completa nu va fi niciodata) se pot transforma in situatii neplacute pentru clienti si pot conduce inclusiv la outage-uri.

De multe ori, feeling-ul unui QA se poate dovedi corect, deoarece el testeaza produsul final, il simte cum se comporta, cat de fiabil este si poate avea o parere avizata despre acesta, pe care restul echipei s-ar putea sa nu o aiba.

Tot aici se cuvine a mai fi mentionata o idee. Intorcandu-ma in trecut, primul meu articol pentru Blog de IT a fost despre etica in IT si de ce avem nevoie de ea. Astfel, prezenta echipelor de QA in cadrul echipelor de development are si un rol etic, acela de a se asigura ca nu se incalca in mod vadit reguli si proceduri care sa asigure calitate produsului si de a le livra in mod intentionat clientilor produse pline de bug-uri care ar putea sa le faca viata un cosmar.

Etica si respectul sunt esentiale si in industria IT ca pentru oricare alt domeniu in care relatiile inter-umane primeaza. In lipsa acestora, exista riscul sa apara derapaje grave si incalcari ale intelegerilor legate de produse si servicii, iar ambele parti sa aiba de suferit. Iar un QA, prin pozitia sa, are si acest rol, de a se asigura ca regulile sunt respectate si ca in lipsa unor situatii exceptionale, calitatea primeaza in fata oricaror alte beneficii.

Testarea, incotro?

Desigur, e greu de prezis ce va fi cu exactitate in viitor referitor la testarea software si asigurarea calitatii. Nu s-a pus si nici nu cred ca se va pune prea curand problema ca peste tot sa se renunte sau neglijeze partea de QA in industrie, insa cateva consideratii de bun-simt se pot face.

Tot intr-un articol trecut dezbateam problema daca mai avem nevoie sau nu de testare manuala. Si acolo discutia era una veche de peste 15 ani, unii sustinand inca de la finalul anilor 2010 ca testerii manuali vor disparea si toata testarea va fi complet automatizata, iar altii care aveau niste insight-uri mai realiste din interior aveau pozitii mai nuantate.

Evident, testarea manuala, si testarea in general nu au disparut, insa cum aminteam si in finalul respectivului articol, rolul de QA probabil se va transforma si va capata forme, atributii si skill-uri noi fata de cele standard pe care le cunoastem noi astazi.

Un prim aspect este acela ca nu cred ca vor mai exista in viitor asa multe roluri separate, de Manual Tester si de Automation Tester, iar trendul va fi mai degraba de a avea ingineri QA care sa le faca in mod hibrid pe ambele: sa stie sa testeze un produs exact ca un client, sa indentifice la prima mana bug-urile, si apoi sa automatizeze scenarii si procese din cadrul acestuia folosind un stack tehnic adecvat.

Acest lucru sigur ca are avantaje financiare si pentru companii, dar cred ca este o tendinta fireasca care poate ajuta si calitatea finala, deoarece din pozitia de QA poti cunoaste astfel foarte bine si produsul, si stack-ul tehnic folosit pentru a asigura testarea de regresie a acestuia si nu numai.

Un alt factor care cu probabilitate foarte mare va influenta rolul de QA este Inteligenta Artificiala (AI). Aceasta poate fi un factor care sa creasca per ansamblu productivitatea celor care lucreaza in IT si implicit sa conduca la o rata de livrare mult imbunatatita a produselor si serviciilor catre clienti.

AI-ul poate ajuta in mod direct si latura de QA prin reducerea timpilor morti sau prin ajutorul oferit la anumite task-uri ce consumau timp, precum sintetizarea documentatiilor stufoase, scrierea de test cases sau refactorizarea codului pentru testare automata.

Indiferent care ar fi viitorul nisei de QA, cuvantul central este „adaptabilitatea”. Ceea ce facea un QA in 2005 nu va mai fi egal cu ce va face un QA in 2030 (daca se va mai numi asa pozitia respectiva), si de aceea e important sa fim deschisi la schimbare, la noile tehnologii, dar fara a sacrifica deloc calitatea finala, scopul primordial al unui produs software ce doreste sa aduca plusvaloare si profit.

Concluzii

In incheiere, ceea ce vreau sa transmit inca o data este idee de a pune pret pe calitatea produselor software in orice moment, fara a o sacrifica prin unica idee simplista ca „nu mai avem nevoie de QA” din varii motive materiale sau financiare.

Rolul QA-ului nu a fost nicicand mai important. A fost si va ramane o componenta super relevanta in orice echipa, cu conditia sa isi exercite acele atribute informale ce le aminteam mai sus. Un QA nu trebuie sa fie un simplu checker care sa bifeze la foc automat cat mai multe task-uri si teste, ci sa isi ia acel ragaz sa se uite cat mai atent la produs, sa il inteleaga si sa spuna unde crede ca ar putea aparea probleme.

Iar calitatea trebuie sa ramana misiunea principala a oricarei companii IT, dincolo de profit si prestigiu, nemaizicand ca acestea din urma se pot dobandi foarte bine prin asigurarea unor procese functionale fata de calitatea produselor dezvoltate de catre ea.

Referinte

Tin sa ii multumesc in mod special managerei mele Patricia Taudan pentru faptul ca de cand am devenit QA in mod constant imi reaminteste, mie si colegilor de echipa, care trebuie sa fie adevaratul nostru rol de QA.

Surse aditionale

Las aici 2 articole interesante de la Virtusa si Qualizeal despre viitorul testarii si al QA-ului.

Un articol foarte fain pe Medium despre cariera de QA, cum va evolua si de ce e o optiune foarte buna.