In aceasta ultima parte din seria noastra de articole despre cele sapte principii ale testari vom analiza ultimele trei principii.

Principiul 5. Paradoxul pesticidelor

Daca acelasi set de teste este repetat de foarte multe ori in cele din urma nu vor mai fi identificate defecte. Clusterele despre care vorbeam in articolul anterior vor aparea in alta parte. De ce se intampla asta?
Aceasta analogie a fost propusa de Boris Beizer in 1983. El a oferit ca exemplu folosirea pesticidelor.

Pesticidele omoara daunatorii, dar daca folosim acelasi pesticid in acelasi loc de prea multe ori, daunatorii care au mai ramas vor deveni imuni – in cele din urma isi vor dezvolta rezistenta si pesticidul nu va mai functiona. Aplicarea repetata a acelorasi teste si metodologii va duce in cele din urma la un produs cu defecte care nu mai pot fi identificate cu aceste teste si metodologii.

Pentru a rezolva acest paradox, testele existente trebuie revizuite regulat si trebuie sa scriem teste noi si diferite pentru a testa diferite parti ale sistemului. Acest lucru ne va ajuta sa identificam mai multe defecte.

Principiul 6. Testarea depinde de context

Testarea se face diferit in functie de context. Spre exemplu testarea unor sisteme software critice se face diferit fata de testarea unui website de e-commerce spre exemplu.

Acest principiu tine de notiunea de risc. Ce este riscul mai exact? Riscul reprezinta de fapt o problema potentiala. In viitor probabilitatea ca un risc sa se intample este intre 0% si 100% si are un anumit impact. Atunci cand analizam un risc ne uitam de fapt la doua aspecte – probabilitate si impact. Spre exemplu, de fiecare data cand traversam strada exista un risc de a fi calcati de masina. Probabilitatea ca acest lucru sa se intample depinde de factori precum nivelul de trafic, traversarea regulamentara, cat de bine vedem sau de cat de repede putem traversa. Impactul depinde de cat de repede merg masinile, de echipamentul de protectie pe care il avem, varsta noastra, starea de sanatate etc. Astfel putem sa identificam gradul de risc pentru o anumita persoana si sa dezvoltam cea mai buna strategie de a traversa strada.



Acelasi lucru este valabil si pentru un software: diferite sisteme au diferite nivele de risc si impactul problemelor variaza. Anumite probleme sunt triviale dar altele pot cauza costuri mari – timp, bani sau reputatia afacerii – sau pot duce si la situatii mai grave.

Nivelul de risc influenteaza alegerea metodologiilor, tehnicilor si tipurilor de testare.

Principiul 7. Absenta erorilor

Identificarea si rezolvarea defectelor nu ajuta foarte mult daca sistemul este inutilizabil sau nu indeplineste asteptarile si cerintele utilizatorilor.

Cei care urmeaza sa foloseasca software-ul – oamenii si organizatiile care cumpara si il folosesc in activitatile de zi cu zi – nu sunt interesati de defecte sau de numarul lor decat atunci cand sunt afectati in mod direct de ele. Nu ii intereseaza cat de multe din cerintele documentate sunt indeplinite de software. Oamenii care il folosesc sunt mai degraba interesati ca programul sa ii ajute sa isi indeplineasca sarcinile eficient. Software-ul trebuie sa le indeplineasca nevoile si acesta este criteriul pe baza caruia ei il evalueaza.

Chiar daca am facut toate testele si nu am gasit defecte, acest lucru nu garanteaza faptul ca software-ul indeplineste nevoile si asteptarile utilizatorilor.

Cu alte cuvinte, verificare si validare.

Verificarea tine de evaluarea sistemului pentru a vedea daca indeplineste cerintele. Validarea tine de evaluarea sistemului pentru a determina daca indeplineste nevoile si asteptarile utilizatorilor si daca si-a indeplinit scopul. O parte din activitatea de testare trebuie sa se concentreze pe verificare si o parte pe validare.
  
In teorie daca cerintele au fost colectate si analizate corect si nu au aparut probleme la nivel de arhitectura software sau dezvoltare de cod, atunci nu ar trebui sa avem situatii delicate. Dar uneori teoria nu se potriveste cu practica.

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

Victoria Slinyavchuk
Consultant on Software Testing