Testarea software. Strategia de Testare

Partea a doua a articolului nostru legat de perspectiva economica asupra testarii software. De aceasta data ne uitam la strategia de testare.

Nov 2, 2021 108
Ce inseamna toate ideile discutate in primul articol atunci cand vine vorba de construirea unei strategii de testare software? Trebuie sa repetam asta, testare software nu poate sa fie niciodata finalizata. Ea poate fi doar oprita. Pentru asta avem nevoie de criterii, atat economice cat si tehnice, pe baza carora putem lua aceasta decizie. As indrazni sa spun, ca in mare parte sunt doar economice, dar s-ar putea ca acest lucru sa nu fie acceptabil pentru toata lumea. Exista o diferenta de baza intre ce face un software tester si ce face un programator:

  • Putem programa tot - Posibil
  • Putem testa tot - Imposibil

Programatori pot face asta. Ei pot raspunde la intrebarea “Cat timp iti va lua sa programezi intreaga aplicatie” – 2 luni si jumatate, spre exemplu. Dar de ce se intampla asta? Pentru ca avem 18 functionalitati, si fiecare poate sa fie codata in medie in 3 zile, sa zicem.

Si de cat timp este nevoie ca cei care fac testare software sa gaseasca toate defectele? De cat timp este nevoie ca ei sa scrie toate test cases? De cat timp este nevoie ca sa verifice toate functionalitatile? Nu va fi nicioadata indeajuns timp. Asta inseamna ca trebuie sa spunem cand oprim testarea software si de ce facem asta. Si aceste criterii ar trebui sa fie atat tehnice cat si economice.

Ar trebui sa estimam eforturile cu munca de testare, nu in general ci mai degraba in functie de cat ne trebuie pentru a avea un anumit efect. Trebuie sa fim capabili sa planificam un anumit punct unde testarea sa fie oprita si ne putem astepta sa aducem sistemul software la un anumit nivel sau stare de functionare.

Exemplu: “Daca petrecem X ore de munca, vom avea un anumit nivel de calitate (inseamnand ca nu vor ramane foarte multe defecte). Si daca petrecem mai putin timp, nivelul calitatii va fi mai scazut (vom aveam mai multe defecte).” Asta inseamna ca daca avem 5000 de ore de lucru, vom gasi 97% din defecte. Si daca avem mai putin, vom gasi mai putine defecte. In acest caz, putem vorbi de modul in care ar trebui sa organizam testarea software– daca procesele de software development sunt indeajuns de mature.

Si aici ne-am putea opri. Stim (in termeni pur tehnici) la ce sunt utilizate eforturile de testare software. De obicei sunt folosite pentru urmatoarele activitati:

  • Revizuirea cerintelor
  • Dezvoltarea test cases
  • Rularea manuala a test cases
  • Automatizarea test cases
  • Analiza rezultatelor si generarea rapoartelor

Investitiile in munca trebuie sa ofere in schimb un produs software de calitate (ROI). Stim pe ce trebuie sa cheltuim timp si bani – trebuie sa colaboram cu oameni cu un anumit nivel de experienta, sa platim pentru solutii de automatizare si asa mai departe. Trebuie sa investim in testare software, inclusiv munca de testare propriu-zisa. Dar orice companie va intreba ce primeste in schimb. Si ce putem sa oferim noi in schimb. Un nivel ridicat de calitate.

Software Testing Economics. Testing Strategy.jpg


Unde este impactul?

Hai sa analizam anatomia unui proces de planificare. Ar trebui planificat in asa fel incat toate costurile sa fie realiste (si sa respecte bugetul) si eficiente (genereaza rezultatele dorite). Daca promitem ca avem nevoie de 5000 de ore pentru a testa ceva, atunci vom fi criticati. Daca promitem ca testam ceva in 3 zile dar se dovedeste ca sunt defecte nedescoperite, vom fi criticati si atunci, dar mai tarziu. Este important deci sa ne respectam cuvantul.

Asta inseamna sa folosim anumite metode si modele pentru a estima eforturile de testare. Pe baza acestor estimari, putem planifica activitatile de testare. Ar trebui sa urmarim si procesul de testare pentru a descoperi in timp util orice intarzieri in plan. Si pentru a le corecta

Sa presupunem ca am estimat corect volumul de munca, apoi numarul de ore. Ce se intampla daca lucrurile nu merg asa

S-ar putea sa subestimam eforturile de munca pentru testarea software. S-ar putea sa le subestimam de la inceput. Spre exemplu, am cerut 5000 de ore. Dar acest lucru nu se poate intampla asa ca ni se sugereaza 3500. Sa incercam. Un alt exemplu. Sunt numite lucruri care se schimba tot timpul in proicte, de la cerinte la platforme. Toate aceste cerinte pot deteriora calitatea unui produs software aflat in testare, deoarece am avut un plan initial care a devenit irelevant. Am subestimat lucruri sau circumstantele s-au schimbat. Putem sa fim astfel in situatia unde avem o deteriorare a calitatii produslui, cand nu avem indeajuns de multe capabilitati pentru a testa totul asa cum am planificat si la nivelul de calitate planificate. Ce ar trebui sa facem intr-o asemenea situatie si care sunt capcanele?

De ce ne confruntam uneori cu subestimarea? Spre exemplu, intregul buget pentru proiect a fost subestimat. Alteori, costul resurselor se dovedeste a fi mai mare decat s-a crezut initial. Spre exemplu, am spus ca vom aloca test cases catre junior testers. Cred ca toata lumea, inclusiv eu, si-ar dori ca un junior tester sa poata sa scrie teste corect. Nu am vazut inca asa ceva. Asa ca evident ca va trebui sa le corectezi sau sa le rescrii.

Volumul de munca poate sa fie subestimat datorita un procese imperfecte sau care lipsesc. Factorul uman joaca un rol crucial. Chiar daca avem o echipa stabila, nu este o garantie. Oamenii sunt diferiti, gandesc diferit, isi schimba parea. Astfel ca noi toti – compania, proiectul, software testerii, clientul – putem deveni prizonierii unor circumstante. Pentru a planifica munca corect, trebuie sa avem procese corecte.

Vrei sa incepi o cariera in testare software sau sa iti imbunatatesti abilitatile de testare software? Descopera cursurile noastre.

Alexandr Alexandrov
Software Testing Consultant

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.