Preconceptii si idei gresite despre testarea software

Odata cu cresterea popularitatii sectorului IT si a dorintei oamenilor de a face tranzitia spre acesta, au aparut tot mai multe articole care fie popularizeaza beneficiile si partile faine ale anumitor job-uri din acest sector (programator, QA, designer etc.), fie raspandesc idei ce sunt fundamental gresite.

Problema cea mai mare este ca multi oameni iau drept adevarate anumite stereotipuri despre aceste meserii, iar domeniul testarii software nu a facut exceptie, ba dimpotriva. In continuare vom discuta despre cele mai intalnite preconceptii despre testare software, si despre realitatea faptica din teren.

Preconceptii si idei gresite despre rolul testarii

Cel mai probabil ideile preconcepute (si gresite) despre testarea software se datoreaza mai multor factori, de la lipsa de intelegere a acestui domeniu in cadrul procesului de lansare a software-ului (SDLC), superficialitatea in documentare si simplificarea anormala a rolului de QA, mai ales de catre cei care nu au lucrat ca sau cu acesti specialisti. Sa vedem care sunt printre cele mai intalnite conceptii gresite pe care eu si nu numai le-am intalnit despre testare.

1. „In testarea software se cauta doar bug-uri”

La intrebarea aparent banala „ce face un tester / inginer QA la job?”, cei mai multi ar gandi ca acesta cauta bug-urile din aplicatiile testate. Lucru partial adevarat, insa nici pe de parte nu constituie un raspuns complet.

Mai demult am vorbit intr-un articol dedicat aici pe blog despre cum arata o zi la job pentru un QA. Ideea e ca activitatile pe care acesta le desfasoara si de care se ocupa pentru a asigura calitatea produselor ce le are pe mana este foarte mare, identificarea bug-urilor fiind doar o mica piesa din acest puzzle.

De exemplu, un QA caruia ii pasa de calitatea si forma finala a produselor testate va cauta sa vina cu sugestii si imbunatatiri, sa adauge noi feature-uri, sa gaseasca hibele inca din faza de requirements astfel inca sa previna in mod proactiv si cat mai din timp remedierea unor eventuale probleme tehnice sau de utilizare, fara ca acestea sa ajunga la clientii companiei.

2. „Un QA nu are un rol la fel de important precum un programator”

O comparatie intalnita extrem de frecvent in mediul online si propagata in special de anumite academii ce ofera cursuri de recalificare in IT pentru a-i face pe viitorii cursanti sa „inteleaga” rolul unui tester este accea intre zona de QA si cea de development. Comparatie din care aproape mereu rolul de QA iese ca fiind inferior unui programator, ceea ce iarasi nu este adevarat.

Motivul este acela ca se zica ca e mai usor sa intri in IT drept QA decat programator, ca ai nevoie de mai putine studii, si ca e o activitate lejera (iti aduce aminte, „testarea doar cauta bug-uri”, nu?). Desigur, aceste lucruri sunt trunchiate si in buna parte lipsite de adevar.

Ceea ce se poate spune cu siguranta este ca cele doua roluri, de QA si developer, sunt diferite, presupun anumite skill-uri comune dar multe specifice fiecaruia, si se bazeaza pe un mindset complet diferit. Un QA trebuie sa vada aplicatia exact ca un user final, sa o priveasca in ansamblu si sa incerce sa anticipeze unde ar putea aparea problemele de utilizare, astfel incat sa discute cat mai din timp cu echipa de dezvoltare si nu numai.

Deci, un QA nu este inferior niciunui alt rol din IT, vorbim doar de pozitii diferite dar toate extrem de necesare, cu scopul lor bine definit, exact ca intr-o echipa de fotbal, unde un portar nu poate fi comparat cu un atacant – ambii sunt necesari si au rolul lor bine definit.

3. „Oricine poate fi tester”

Continuand stereotipurile raspandite mai sus cu scopul de a atrage cursanti pentru recalificari scumpe in QA, exista si ideea potrivit careia absolut oricine poate sa profeseze drept tester.

Ca in orice alta ocupatie, nu oricine poate deveni QA in lipsa anumitor cunostinte si aptitudini minimale care sa ofere angajatorului o anumita garantie ca poate executa sarcinile de lucru. Atentie, nu ne referim la studiile formale, acelea putand sa fie diferite ca background educational de la un caz la altul si discutabil daca chiar conteaza, ci doar la pregatirea specifica pentru a fi QA tradusa in a cunoaste tehnici si tipuri de testare, cum sa scrii testcases, despre metodologia Agile si modurile de lucru in IT, cum sa lucrezi cu documentele specifice, cum sa automatizezi niste scenarii si asa mai departe.

Ori afirmatia potrivit careia oricine poate sa fie tester este pe o parte periculoasa deoarece ridica foarte mult pretentiile viitorilor candidati si scade dorinta de a se pregati cat mai bine inainte de a aplica la job-urile de QA.

4. „Testarea trebuie sa verifice absolut totul in aplicatie”

O alta conceptie gresita despre scopul testarii software este aceea ca ea trebuie sa verifice cu prisosinta absolut totul, de la A la Z, intr-un produs pentru a depista toate bug-urile, inainte ca acesta sa ajunga la client. Ceea ce se poate spune despre aceasta afirmatie este ca e una complet idealista, realitatea practica cotidiana infirmand-o.

Conform unui dintre principiile testarii software despre care am mai vorbit in trecut, testarea exhaustiva este imposibila. Chiar daca ne dorim foarte mult si ne straduim in consecinta pentru acest scop, prin activitatea de testare nu avem cum sa cuprindem absolut toate detaliile dintr-o aplicatie si implicit nici sa depistam toate bug-urile.

O aplicatie software are foarte multe layere, componente, servicii, API-uri si functionalitati care o compune, fiecare cu multiplele sale sub-cazuri si situatii care se pot naste singular sau in mod relational cu celelalte, rezultand un numar de cazuri de testare urias.

Iar cum timpul (care in business inseamna bani) si energia oamenilor sunt limitate, rezulta deci ca nu se pot acoperi absolut toate cazurile, fiind nevoie de o prioritizare a acestora si de testarea lucrurilor mai importante care pot impacta serios utilizarea, prin eficientizarea procesului.

5. „Testarea este un proces fix”

O idee gresita din punct de vedere al metodologiei de lucru si a business-ului este aceea ca testarea e un proces fix, ce poate fi planificat extrem de exact si estimat cu precizie, astfel incat sa se stie exact cat va dura ca timp si cat va costa din punct de vedere financiar. Desigur, vorbim de o alta perceptie gresita fata de testare.

Adevarul este ca testarea nu e deloc un proces fix ci complex, variabil si fluid care evolueaza in raport cu foarte multe variabile. Depinde de cati QA sunt in echipa, de cat de complex este proiectul respectiv, ce feature-uri se implementeaza, si care sunt potentialele riscuri ale acestora pentru clienti. Uneori pot aparea foarte multe bug-uri surpriza ce se leaga unele de altele, si atunci release-ul trebuie amanat.

Desigur, e bine sa existe o planificare cel putin teoretica, sa se aiba in vedere ce functionalitati se vor testa, cu ce tehnici si resurse, si macar sa existe un orizont de timp, ca sa nu se exagereze cu amanarile. Insa in alta ordine de idei, e foarte greu de prezis cu exactitate cat dureaza testarea, motiv pentru care ea trebuie sa intervina cat ma idin timp, din faza de elaborare a cerintelor tehnice. Cu siguranta e mai usor de anticipat care ar fi consecintele fara testare.

Ce aduce in plus testarea software?

Trecand in revista cateva dintre principalele conceptii si idei prost intelese despre testare, merita sa amintim si ce aduce ea cu adevarat in plus. Dupa cum aminteam si mai sus, un QA trebuie sa citeasca documentatia si sa o inteleaga, astfel incat sa incerce sa depisteze inca din faza de requirements acele erori care pot fi remediate atat de timpuriu, pentru reduceri cat mai eficiente de costuri. El poate sa vina si sa treaca sugestii pentru anumite feature-uri sau chiar sa scrie improvement-uri in Jira (alaturi de rapoartele de bug), astfel incat sa fie avute in vedere de catre developement.

Apoi, un QA nu trebuie sa se rezume la a testa ce face butonul X si atat. El trebuie sa incerce sa verifice ce face butonul X, ce se intampla cand nu e folosit acesta, eventual cat de util este pentru user si ce se intampla in anumite situatii combinate, deci sa gandeasca si in lateral, nu doar din perpectiva checking-ului si atat. Uneori testerii pot sa tina Demo-uri, adica prezentari scurte in care sa arate altor persoane din echipa cum (se presupune ca) functioneaza un anumit feature (de multe ori acest lucru se face si de catre programatori).

Astfel, rolul unui QA este complex, existand foarte multe activitati in care acesta trebuie sa fie implicat pentru a se evita probleme majore pe mai incolo, care ar costa financiar extrem de mult.

Concluzii

In incheiere, se poate afirma ca in ultimii cativa ani buni, in mediul online s-au raspandit si au persistat mai multe preconceptii despre testarea software care au condus la o imagine gresita pe care aceasta o are. De la reducerea pana la absurd a rolului ei in procesul de software development (SDLC), pana la faptul ca ea ocupa mult timp si consuma inutil resurse, aceste idei sunt periculoase pe termen mediu si lung, putand conduce la probleme foarte grave pentru utilizatori.

Incidentul de vineri, 19 iulie (2024) in care sistemele cu Windows au fost paralizate ca urmare a unui update venit la partea de cloud de la compania Crowdstrike este elocvent, si exista anumite suspiciuni rezonabile ca nu a fost ceva testat temeinic (asteptam mai multe detalii pentru confirmarea sau infirmarea acestei supozitii). Deci, testarea necesita resurse, dar lipsa testarii consuma si mai multe resurse.

Surse suplimentare

Mai multe conceptii gresite despre testarea software si explicatiile corespunzatoare gasesti aici, aici si aici.

Daca vrei sa incepi sa inveti testare software manuala si automata, aici sunt 2 optiuni cu Cypress sau cu Selenium.