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

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

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.