In primul articol din aceasta serie am analizat primele doua principii ale testarii software iar in acest articol vom discuta despre principiile trei si patru.

Principiul 3. Testarea timpurie

Activitatile de testare ar trebui sa inceapa cat mai repede posibil in ciclul de dezvoltare al unei aplicatii sau sistem software si ar trebui sa se concentreze pe obiective. Acest principiu se bazeaza pe conceptul de “cost al defectului”. Acest cost creste considerabil pe parcursul ciclului de dezvoltare – cu cat gasim defectul mai devreme cu atat mai usor va fi sa il rezolvam rapid si ieftin.

Daca un defect este detectat la nivel de cerinte, atunci este cel mai putin costisitor sa il rezolvam. Daca defectul este detectat la etapa de design atunci design-ul poate fi corectat cu usurinta. Daca insa un defect apare la nivel de cerinte si este detectat abia in etapa de testare de sistem sau de acceptare atunci va fi mult mai costisitor sa il reparam. Acest lucru se intampla pentru ca este nevoie de refacerea specificatiilor si design-ului inainte de a opera orice schimbari la nivel de sistem. Mai mult decat atat un defect la nivel de cerinte se poate propaga in mai multe arii ale design-ului si codului iar dupa implementare schimbarilor necesare activitatea de testare va trebui repetata. Exista situatii unde defectele sunt detectate in ultimele etape si nu sunt corectate datorita costurilor.

De asemenea, daca un produs software este livrat si indeplineste formal cerintele agreate, dar nu este ceea ce au dorit utilizatorii, poate sa genereze provocari legate de folosirea, vanzarea si implementarea lui. Acest lucru inseamna ca cerintele erau incomplete dar ca eroarea nu a fost detectata. Din acest motiv este important sa incepem testarea cant mai devreme posibil folosind testarea statica.



Un alt avantaj important al testarii timpurii este faptul ca reduce din timp. Poti incepe activitatile de testare si inainte ca prima linie de cod sa fie scrisa. In timp ce specificatiile si cerintele sunt pregatite, testerul poate sa inceapa sa dezvolte si sa revizuiasca test cases. Si in momentul in care prima versiune de testare este gata, le poate pune in practica.

Principiul 4. Clusterele de defecte

Un numar mic de module contin majoritatea defectelor descoperite in etapa de testare inainte de lansare sau vor genera cele mai multe probleme dupa.

Un fenomen pe care foarte multi testeri l-au observat este ca defectele au tendinta sa formeze clustere. Acest lucru se intampla pentru ca o anumita parte din cod este complexa sau pentru ca schimbarea software-ului sau a altor produse tinde sa cauzeze cele mai multe efecte negative. Testerii folosesc aceasta informatie atunci cand fac evaluarea de risc pentru planificarea testelor si se vor concentra pe aceste puncte fierbinti.
Clusterele pot fi identificate in primele etape de dezvoltare atunci cand are loc testarea statica (revizuirea codului sau analiza acestuia). Cand intervine si testarea dinamica, ne putem concentra pe ariile unde am gasit cele mai multe defecte in etapa de testare statica.

Putem sa facem si root cause analysis pentru a preveni aparitia defectele sau pentru a identifica cauza din spatele clusterelor sau viitoarelor clustere.

Vrei sa incepi o cariera in testare software? Descopera cursurile noastre.

Victoria Slinyavchuk
Consultant on Software Testing