PRINCIPIILE

PROCESULUI DE
TESTARE

MAZUR CRISTIAN
 PRINCIPIUL 1.
TESTAREA ARATA PREZENTA DEFECTELOR

Testarea poate sa arate prezenta defectelor dar nu poate sa dovedeasca ca nu sunt defecte. Este
foarte dificil sa arati ca ceva nu exista – oricat de multe lebede albe am vedea nu putem spune cu
certitudine “Toate lebedele sunt albe!”. Insa, in momentul in care vedem o lebada neagra putem
spune “Nu toate lebedele sunt albe.”.

La fel, oricat de multe teste avem in care nu gasim bug-uri, nu putem spune ca nu exista alte teste
care ar putea sa descopere un bug. In momentul in care gasim cel putin un bug, putem spune
“Acest cod are bug-uri.”.
PRINCIPIUL 2.
TESTAREA EXHAUSTIVA NU ESTE POSIBILA

Acest principiu are legatura cu intrebarea: “Cat de multa testare ar trebui sa facem?”
Ce raspunsuri putem avea la aceasta intrebare? Putem sa alegem: testam tot, nu testam nimic sau
testam o parte din software. Un raspuns ideal ar fi sa spunem ca testam totul. Dar trebuie sa ne
gandim daca ar trebui sau daca putem sa testam totul. De cat de multe teste ar fi nevoie ca sa
testam complet un camp numeric pentru o singura cifra? Depinde ce intelegem prin testare
completa. Exista 10 valori numerice valide dar pe langa aceste valori trebuie sa ne asiguram ca
toate valorile care nu sunt valide sunt respinse. Am avea 26 de caractere cu litera mica, 26 de
caractere cu litera mare, cel putin 6 semne de punctuatie precum si situatia in care casuta este
lasata goala. Rezulta cel putin 68 de teste, fara a mentiona caractere speciale.
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.
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.
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.
PRINCIPIUL 6.
TESTAREA DEPINDE DE CONTEXT
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.
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.