TESTAREA SOFTWARE:

Principii, Obiective, Nivele.

3 IANUARIE 2020
MITEA STELIANA TALIDA
Ingineria Calculatoarelor și Comunicațiilor
 Testarea software reprezintă o investigație empirică realizată cu scopul de a
oferi părților interesate informații referitoare la calitatea produsului sau serviciului
supus testării, luând în considerație contextul operațional în care acesta din urma va fi
folosit. Testarea software pune la dispoziție o viziune obiectivă și independentă asupra
produsului în dezvoltare, oferind astfel businessului posibilitatea de a înțelege și
evalua riscurile asociate cu implementarea produsului soft. Tehnicile de testare includ,
dar nu sunt limitate la, procesul de execuție a programului sau aplicației în scopul
identificării defectelor/erorilor de software. Testarea software mai poate fi definită ca
un proces de validare și verificare a faptului că un program/aplicație/produs software
corespunde business cerințelor și cerințelor tehnice care au ghidat proiectarea și
implementarea lui și rulează și se comportă corespunzător așteptărilor.

Cele 7 principii ale testării software sunt:

Principiul 1. Testarea arata prezenta defectelor

Testarea poate sa arate prezenta defectelor dar nu poate sa dovedească ca nu

sunt defecte. Este foarte dificil sa arați ca ceva nu exista – oricât de multe lebede albe
am vedea nu putem spune cu certitudine “Toate lebedele sunt albe!”. Însă, in
momentul in care vedem o lebăda neagra putem spune “Nu toate lebedele sunt albe.”.
La fel, oricât de multe teste avem in care nu găsim Bug-uri, nu putem spune ca
nu exista alte teste care ar putea sa descopere un Bug. In momentul in care găsim cel
puțin un Bug, putem spune “Acest cod are Bug-uri.”.
Dar asta nu înseamnă ca testarea este lipsita de sens si nu poate creste gradul
de certitudine cu privire la calitatea codului. Testarea reduce probabilitatea defectelor
nedescoperite care pot fi găsite intr-un soft dar chiar si atunci când nu găsim defecte
acest lucru nu este o dovada a corectitudinii codului.

Principiul 2. Testarea exhaustiva nu este posibila

Acest principiu are legătura cu întrebarea: “Cat de multa testare ar trebui sa

facem?”

Ce răspunsuri putem avea la aceasta întrebare? Putem sa alegem: testam tot,

nu testam nimic sau testam o parte din software. Un răspuns ideal ar fi sa spunem ca
testam totul. Dar trebuie sa ne gândim daca ar trebui sau daca putem sa testam totul.
De cat de multe teste ar fi nevoie ca sa testam complet un câmp numeric
pentru o singura cifra? Depinde ce înțelegem prin testare completa. Exista 10 valori
numerice valide dar pe lângă 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 puțin 6 semne de punctuație precum si situația in care căsuța este lăsata
goala. Rezulta cel puțin 68 de teste, fără a menționa caractere speciale.
Aceasta problema devine si mai grava pe măsura ce ne uitam la exemple mai
realiste. In practica, sistemele au mai mult de un câmp si au dimensiuni variate. Aceste
teste sunt in plus pe lângă cele necesare pentru a vedea cum rulează sistemul in diferite
medii. Daca luam un exemplu unde avem 15 câmpuri, fiecare cu 5 valori posibile,
atunci pentru a testa toate combinațiile valide am avea nevoie de 30 517 578 125 (515)
teste! Este puțin probabil ca deadline-urile vreunui proiect sa permită numărul acesta
de teste.
Folosind partiții de echivalenta putem reduce numărul textelor, deoarece
testarea câmpului care are o singura valoare numerica cu valorile 2, 3 si 4 nu ne-ar
oferi mai multe informații fata de testarea cu -3 spre exemplu.
In viată reala, presiunile pe proiect la nivel de timp si buget precum si
presiunea de a livra soluții tehnice care sa rezolve nevoile clientului nu permit o testare
completa. Clienții si Project managerii vor vrea ca testarea sa dureze o perioada de
timp care sa ofere un return on Investment. Acest lucru include prevenirea eșecurilor
după lansare care sunt mereu costisitoare. Testarea completa – chiar daca clienții si
project managerii cer acest lucru – nu este ceva ce își pot permite.
In loc sa încercam sa testam tot, trebuie sa avem o strategie care oferă nivelul
necesar de testare pentru proiect, clienți (si alte parți implicate) si software. Atunci
când decidem nivelul de testare trebuie sa luam in considerare nivelul de risc, inclusiv
riscuri tehnice si de business legate de produs sau proiect precum timp si buget.
Evaluarea riscului si managementul acestuia sunt unele dintre cele mai importante
activități in orice proiect si acestea ne permit sa variem efortul de testare pe baza
riscului.
Mai mult decât atât, testarea ar trebui sa ofere informații suficiente către
părțile implicate pentru a lua decizii informate despre lansarea produselor sau predarea
către clienți.

Principiul 3. Testarea timpurie

Activitățile de testare ar trebui sa înceapă cat mai repede posibil in ciclul de

dezvoltare al unei aplicații sau sistem software si ar trebui sa se concentreze pe
obiective. Acest principiu se bazează pe conceptul de “cost al defectului”. Acest cost
creste considerabil pe parcursul ciclului de dezvoltare – cu cat găsim defectul mai
devreme cu atât mai ușor va fi sa li rezolvam rapid si ieftin.
Daca un defect este detectat la nivel de cerințe, atunci este cel mai puțin
costisitor sa li rezolvam. Daca defectul este detectat la etapa de design atunci design-ul
poate fi corectat cu ușurința. Daca însă un defect apare la nivel de cerințe si este
detectat abia in etapa de testare de sistem sau de acceptare atunci va fi mult mai
costisitor sa îl reparam. Acest lucru se întâmpla pentru ca este nevoie de refacerea
specificațiilor si design-ului înainte de a opera orice schimbări la nivel de sistem. Mai
mult decât atât un defect la nivel de cerințe se poate propaga in mai multe arii ale
design-ului si codului iar după implementare schimbărilor necesare activitatea de
testare va trebui repetata. Exista situații unde defectele sunt detectate in ultimele etape
si nu sunt corectate datorita costurilor.
De asemenea, daca un produs software este livrat si îndeplinește formal
cerințele agreate, dar nu este ceea ce au dorit utilizatorii, poate sa genereze provocări
legate de folosirea, vânzarea si implementarea lui. Acest lucru înseamnă ca cerințele
erau incomplete dar ca eroarea nu a fost detectata. Din acest motiv este important sa
începem testarea cant mai devreme posibil folosind testarea statica.

Un alt avantaj important al testării timpurii este faptul ca reduce din timp. Poți
începe activitățile de testare si înainte ca prima linie de cod sa fie scrisa. In timp ce
specificațiile si cerințele sunt pregătite, testerul poate sa înceapă sa dezvolte si sa
revizuiască test cases. Si in momentul in care prima versiune de testare este gata, le
poate pune in practica.

Principiul 4. Clusterele de defecte

Un număr mic de module conțin majoritatea defectelor descoperite in etapa de

testare înainte de lansare sau vor genera cele mai multe probleme după.
Un fenomen pe care foarte mulți testeri l-au observat este ca defectele au
tendința sa formeze clustere. Acest lucru se întâmpla 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 informație atunci
când fac evaluarea de risc pentru planificarea testelor si se vor concentra pe aceste
puncte fierbinți.
Clusterele pot fi identificate in primele etape de dezvoltare atunci când are loc testarea
statica (revizuirea codului sau analiza acestuia). Când intervine si testarea dinamica, ne
putem concentra pe ariile unde am găsit cele mai multe defecte in etapa de testare
statica.
Putem sa facem si root cause analysis pentru a preveni apariția defectele sau
pentru a identifica cauza din spatele clusterelor sau viitoarelor clustere.

Principiul 5. Paradoxul pesticidelor

Daca același 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
apărea in alta parte. De ce se întâmpla asta?
Aceasta analogie a fost propusa de Boris Beizer in 1983. El a oferit ca exemplu
folosirea pesticidelor.
Pesticidele omoară dăunătorii, dar daca folosim același pesticid in același loc
de prea multe ori, dăunătorii care au mai rămas vor deveni imuni – in cele din urma își
vor dezvolta rezistenta si pesticidul nu va mai funcționa. Aplicarea repetata a acelorași
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 parți ale sistemului. Acest
lucru ne va ajuta sa identificam mai multe defecte.

Principiul 6. Testarea depinde de context

Testarea se face diferit in funcție 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 noțiunea de risc. Ce este riscul mai exact? Riscul
reprezintă de fapt o problema potențiala. In viitor probabilitatea ca un risc sa se
întâmple este intre 0% si 100% si are un anumit impact. Atunci când analizam un risc
ne uitam de fapt la doua aspecte – probabilitate si impact. Spre exemplu, de fiecare
data când traversam strada exista un risc de a fi calcați de mașina. Probabilitatea ca
acest lucru sa se întâmple 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 mașinile, de echipamentul de protecție pe care îl avem,
vârsta noastră, starea de sănătate etc. Astfel putem sa identificam gradul de risc pentru
o anumita persoana si sa dezvoltam cea mai buna strategie de a traversa strada.
 Același lucru este valabil si pentru un software: diferite sisteme au diferite
nivele de risc si impactul problemelor variază. Anumite probleme sunt triviale dar
altele pot cauza costuri mari – timp, bani sau reputația afacerii – sau pot duce si la
situații mai grave.
Nivelul de risc influențează 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 îndeplinește așteptările si cerințele utilizatorilor.
Cei care urmează sa folosească software-ul – oamenii si organizațiile care
cumpăra si îl folosesc in activitățile de zi cu zi – nu sunt interesați de defecte sau de
numărul lor decât atunci când sunt afectați in mod direct de ele. Nu ii interesează cat
de multe din cerințele documentate sunt îndeplinite de software. Oamenii care îl
folosesc sunt mai degrabă interesați ca programul sa ii ajute sa își îndeplinească
sarcinile eficient. Software-ul trebuie sa le îndeplinească nevoile si acesta este criteriul
pe baza căruia ei îl evaluează.

Chiar daca am făcut toate testele si nu am găsit defecte, acest lucru nu

garantează faptul ca software-ul îndeplinește nevoile si așteptările utilizatorilor.
Cu alte cuvinte, verificare si validare.
Verificarea tine de evaluarea sistemului pentru a vedea daca îndeplinește
cerințele. Validarea tine de evaluarea sistemului pentru a determina daca îndeplinește
nevoile si așteptările utilizatorilor si daca si-a îndeplinit scopul. O parte din activitatea
de testare trebuie sa se concentreze pe verificare si o parte pe validare.
   In teorie daca cerințele au fost colectate si analizate corect si nu au apărut
probleme la nivel de arhitectura software sau dezvoltare de cod, atunci nu ar trebui sa
avem situații delicate. Dar uneori teoria nu se potrivește cu practica.
 Obiectivele testării

• Personal implicat: programatori, inginerii de testare, directorii de proiecte si clienții;

• Procesul de testare din diferite perspective:

– Ce funcționează: programatorii testează unitățile si sistemul după integrare in

vederea demonstrării funcționalității acestuia;
– Ce nu funcționează: după testarea funcționalității urmează mai multe teste
pentru evidențierea defectelor de unitate sau sistem;
– Reducerea riscului de defectare: cu cat sistemele sunt mai complexe poate apare
noțiunea de defectare din timp in timp, si deci de rata de defectare;
– Reducerea costurilor testării: costuri de proiectare si execuție a cazurilor de
testare; costuri de analizare a rezultatelor testelor; costuri de realizare a
documentației in vederea testării si de raportare a testelor;
• Cu cat numărul de teste este mai mare cu atât va creste si costul testării – necesitatea
selecționării si construirii corecte a testelor
• Testarea este activitatea de:
– Concepere a cazurilor de test
– Execuție a testelor
– Evaluarea rezultatelor testelor In diferite etape ale ciclului de viată al PP.

Nivelele testari

• Testarea pe componente/ component testing

– defectele sunt cautate in componenta testata;
– se face verificand si codul si avand in permanenta suportul unui dezvoltator;
– nu se inregistreaza incidentele;
– o variatie este “Unit testing”;
• Testarea integrarii componentelor/ integration testing
– se testeaza interdependentele dintre componente, interactiunile dintre diferite
parti ale sistemului;
– poate sa includa si testare non-functionala;
• Testarea sistemului/ system testing
– comportamentul intregului sistem/produs definit ca scop al proiectului sau
programului dezvoltat;
– mediul de test trebuie sa corespunda cu mediul de productie;
– se vor testa atat cerintele functionale, cat si cele non-functionale;
• Testarea de acceptanta/ acceptance testing
– realizata adesea de consultanti sau de clienti, insa pot fi implicate si alte parti;
– are scopul de a stabili increderea in sistem si de a raspunde la intrebarea “Este
produsul destul de bun incat sa fie livrat catre client?”;
– nu se pune accent pe gasirea de defecte, insa in testarea de acceptanta se poate
evalua instalarea si utilizarea sistemului;

Bibliografie
Testarea software si asigurarea calitatii - Conf.dr.ing. Ioana FAGARASAN
https://ro.wikipedia.org/wiki/Testare_software
https://www.luxoft-training.ro