1. Ce este testarea software? Generalitati Testarea este un proces de evaluare a unui sistem ori a unei componente a unui sistem pentru a se vedea… [603421]

1. Ce este testarea software? Generalitati

Testarea este un proces de evaluare a unui sistem ori a unei componente a unui sistem
pentru a se vedea daca acesta indepliniste cerintele clientului. In consecinta, in timpul procesului
de testare, practic se cauta in aplicatia aflata sub control, defecte, inconsistente, devieri de la
cerintele clientului sau furnizeaza informatii despre riscul implementarii software.
Testarea implica verificarea si validarea unui sistem sau al unei componente software.
Aceasta poate determina corectitudinea softului sub presupunerea ipotezelor specifice.
In urma procesului de testare nu vor putea fi identificate toate erorile si defectele deoarece nu se
poate testa pentru toate combinatiile de intrari si preconditii.

2. Cand se incepe procesul de testare?

Procesul de testare este recomandat sa se inceapa cat mai devreme. Cu cat un defect este gasit
mai repede cu atat se reduc costurile si timpul necesar fixarii acestuia.
Momentul inceperii testarii depinde si de modelul de lucru folosit pentru dezvoltarea software
ului.

3. Cand se poate opri procesul de testare?

Este greu de realizat cand procesul de testare poate lua sfarsit. In general nu este nimeni care
poate declara ca un software a fost 100% testat. Mereu pot exista scenarii noi la care un tester nu
s-a gandit. Dar, intr-un mediu de lucru testare trebuie sa ia sfarsit la un moment dat, daca sunt
indeplinte unele dintre criterii :
1. Ajungerea la termenul limita a perioadei de testare.
2. Executarea tuturor cazurilor de test care sunt scrise.
3. Rata de defecte scade sub nivelul impus de catre client.

4. Verificare versus validare

Acestia sunt doi termeni care in general produc confuzii in randul oamenilor.
Verificarea este realizata de developeri (cei care dezvolta produsul). Aceasta este facuta in
primul rand pentru a raspunde la intrebarea : ‘Construiesti produsul corect?’. Prin verificare
developerii se asigura ca sistemul intruneste toate cerintele prin verificarea documentatiei si a
codului scris de catre ei.

Validarea este realizata de catre cei care testeaza produsul. Aceasta este facuta in primul rand
pentru a raspunde la intrebarea: ’Construiesti produsul corect?’ . Este un proces care implica
activitati dinamice cum ar fi executarea cazurilor de test cu multa atentie pentru a se descoperi
daca produsul intruneste cerintele clientuli si daca functioneaza corect.

5. Testare vs debugging.

Testarea implica doar indentificarea si raportarea unui defect sau al unei erori insa fara
corectarea acesteia.
Debugging – Implica identificarea, izolarea si fixarea problemelor. Developerii care dezvolta
produs conduc si actiunea de debugging. Aceasta actiune face parte din testarea white box si din
testarea de tip unit.

6. Testarea manuala. Generalitati

Testarea manuala este un tip de testare unde testerii executa manual cazuri de test fara a se folosi
de instrumente de automatizare. Orice aplicatia trebuie in primul rand testata manual, inainte de a
se incepe automatizarea daca este cazul. Unele erori aparute, pot avea severitatea atat de mare
incat pot impiedica pe deplin automatizarea.
Practic, persoana care face testarea manuala se pune in locul unui utilizator normal si foloseste
aplicatia astfel incat sa vada daca totul merge conform cerintelor.

Un prim pas pe care un tester manual trebuie sa il faca este acela de a intelege care sunt cerintele
si dorintele clientului in ceea ce priveste functionarea aplicatiei. Astfel, se poate identifica mai
usor ce si cum trebuie testat si daca un anumit comportament al aplicatiei poate fi clasat ca si
defect sau nu. Se poate spune ca aceasta este una dintre cele mai importante parti ale procesului
de testare. Cu cat persoana in cauza a inteles mai bine modul corect de functionare a aplicatiei si
cerintele clientului cu atat este mai probabil ca softul rezultat la final sa fie mai calitativ.

Un al doilea pas al procesului de testare manuala este acela de scriere a cazurilor de test (test
cases). O data ce cerintele si specificatiile au fost intelese, se poate incepe scrierea propriu-zisa a
cazurilor de test.
Un test case este un set de conditii si variabile cu ajutorul caruia testerul determina daca sistemul
indeplineste toate cerintele si daca este lipsit de erori.
Cu alte cuvinte, acestea sunt scenarii pe care un utilizator normal le-ar putea face si au rolul de a
ghida testerul prin functionalitatile aplicatiei si de a garanta faptul ca testarea a avut o acoperire
mare in aplicatie. De asemenea scrierea de cazuri de test are rolul de a ghida viitori testeri prin
aplicatie, de a le usura munca si de a asigura intelegere.
Continutul unui test case :

1. ID-ul proiectului din care face parte.
2. Numarul test case ului: Acesta ar trebui sa fie unic in cadrul proiectului pentru care este
scris.
3. Rezumatul testului (poate fi considerat ca si titlu).
Din acest sumar al test case ului este necesar sa se inteleaga clar si concis la ce
componenta/functionalitate se refera si ce se testeaza.

5. Preconditiile necesare pentru a putea fi executat testul.
In cazul in care testul nostru necesita o conditie diferita pentru a putea fi executat decat testele
precedente acest lucru trebuie specificat la inceputul test case ului.
Ca exemple de preconditii intalnite des putem enumera: un anumit de cont, GPS- ul dispozitivul
pornit sau oprit, diferite tipuri de conexiune la internet (date mobile, WI-FI, 3G, 4G), diferite
dimensiuni ale ecranelor dispozitivelor etc.
Nu este obligatoriu ca un test sa aiba preconditii.

5. Pasii de executare.
Acest pas este unul foarte important. Testerul ar trebui sa descrie cu exactitate pasii pe care ii
face pentru a ajunge la un rezultat. Decrierea exacta si la obiect a pasilor faciliteaza executarea
pe viitor a acolor teste si de catre alti testeri.

6. Rezultatele asteptate.
In aceasta rubrica, se descrie rezultatul care este asteptat in urma executarii testului.

7. Rezultatele reale
In cazul in care rezultatul testului nu indeplineste rezultatele asteptate, atunci se mai adauga o
rubrica in care se noteaza rezultatele reale obtinute cu descrierea exacta a comportamentului
inadecvat al programului.

8. Statusul testului.
Dupa executarea testului se trece in aceasta rubrica ‘Passed’ in cazul in care rezultatele obtinute
corespund asteptarilor, sau ’Failed’ in cazul in care rezultatele reale nu corespund cu rezultatele
asteptate. In acest caz, mai exista insa si optiunea ca testul sa fie trecut ‘Blocked’ in cazul in care
exista un impediment in executarea acestuia.

9. Comentarii
In cazul in care este nevoie sa se specifice ceva in legatura cu un test, se folosete rubrica cu
comenatrii. Aici se poate explica sucit spre exemplu, de ce testului i s-a pus un anumit status sau
daca exista ceva ce ar putea fi important de luat la cunostinta cu privire la acesta.

10. Numele celui care a creat testul.
11. Data in care a fost creat testul.
12. Numele celui care a executat testul.
De cele mai multe ori, creatorul testului si executantul testului pot fi persoane diferite.
13. Data executarii.
14. Mediul de test.
Este foarte important sa cunoastem aceasta informatie, deoarece indiferent de ce tip de aplicatie
se testeaza, ar trebui sa fie testata in mai multe medii. Spre exempu o aplicatie WEB nu este
suficient sa fie testata pe un singur motor de cautare sau pe o singura versiune a acestuia. Ar
trebui sa fie acoperite cat mai multe, spre exemplu: Mozila, Firefox, Chrome, Internet Explorer,
Safari etc.
In cazul testarii aplicatiilor mobile, ideal ar fi sa fie acoperite toate tipurile de dispozitive. Cum
acest lucru este aproape imposibil deoarece exista foarte multe tipuri de telefoane, se urmareste
testarea pe sistemele principale de operare (Android, iOS, Windows Phone) dar un aspect
important este si tesarea pe dispozitive care au dimensiuni diferite de ecran.

Al treilea pas este testarea propriu-zisa. O data test case urile scrise si mediul de testare pregatit,
se incepe efectiv testarea. Acest procedeu, in general, consta in urmarirea fiecarui test case in
parte si se marcharea lor ca ‘Passed’, ‘Failed’ sau ‘Blocked’ in functie de situatie. In timpul
testarii manuale, este foarte important sa se tina notite cu ceea ce se intampla cand un test
esueaza.

Un al patrulea pas in procesul de testare este raportatrea defectelor si erorilor gasite in urma
procesului de testare. Acest lucru este facut cu ajutorul instrumentelor si platformelor
specializate in gestionarea rapoartelor defectelor.
Un raport corect contine :
1. Titlul – trebuie sa fie scurt si la obiect dar ar trebui sa se inteleaga doar din citirea lui atat
zona afectata a a plicatiei cat si problema.
2. Pasii de reprodcere
Avand in vedere ca acest raport al defectului va ajunge la developer, totul trebuie descris pas cu
pas si cu toate amanuntele necesare pentru ca developerul sa il poata reproduce cu usurinta. 3.
Rezultatele asteptate
In acest pas se descrie care ar trebui sa fie comportamentul aplicatiei sau care ar trebui sa fie
rezultatul unei anumite actiuni facute asupra sistemului aflat sub test.
4. Rezultatele actuale
In acest pas se descrie comportamentul deficitar al aplicatiei. De asemenea este recomandat sa se
ataseze capturi de ecran, inregistrai sau documente aditionale care au rolul de a ajuta intelegerea
exacta a problemei.

In general, testarea manuala necesita un efort mare, oamenii fiind predispusi sa sara
anumite parti, sau sa incerce mereu sa automatizeze totul. Dar adevrul este ca desi testarea
automata este foarte utila si ajuta foarte mult, nu putem acoperi tottul cu ajutorul ei. In fond,
oameni reali vor fi cei care vor folosi aplicatia, de eceea este indicat existenta macar unei
persoane care face testare manuala intr-un proiect. O persoana care se ocupa de acest tip de
testare, de cele mai multe ori va gasi anumite tipuri de defecte care in urma testarii automate nu
vor fi gasite.

7. Testare automata
Testarea automata este testarea facuta cu ajutorul unui soft special care ajuta la
exacutarea automata a testelor si compararea rezultatelor actuale cu cele reale, rezultate in urma
testarii.
Desi unele intrumente folosite in procesul de testare automata pot fi scumpe, acest tip de tesare
este unul foarte util, deoarece o data scrise testele automate, ele pot fi rulate oricand din nou (ex:
in cazul testelor de regresie), fara vreun alt efort suplimentar.
Cand vine vorba de proiecte complexe este imposibil ca totul sa fie automatizat. In
primul rand, este recomandat ca testele automate sa se concentreze pe partile cele mai utilizate
ale aplicatiei si pe cele pe care exista sansa sa le folosesaca multi utilizatori simultan (paginile de
logare, paginile de creare conturi, functionalitatile principale ale aplicatiei etc.)
Testarea automata ar trebui sa fie pusa in practica in urmatoarele situatii :
1. Cand se dezvolta procese complexe
2. Cand se lucreaza la proiecte care necesita testarea acelorasi functionalitati frecvent.
3. Cerintele clientului cu privire la arhitectura si interfata aplicatiei nu se schimba frecvent
4. Cand softul este stabil si a fost testat manual precedent.
5. In momentul in care se dispune de suficient timp.

7. Clasificarea generala a tipurilor de testare.

Domeniul testarii este unul desosebit de complex. Exista numeroase tipuri de testare care se
clasifica dupa urmatorele criterii :

1. Daca privim care este obiectivul testarii avem urmatoarele tipuri: functional testarea
functionala si testare non functionala.
2. In functie de tipul de cunoastere pe care il avem asupra sistemului : white box testing,
black box testing, grey box testing.
3. In functie de metoda de executie: manuala, automata, semi automata.
4. In functie de nivelul la care este testata aplicatia: component testing, integration testing,
system testing.

5. In functie de nivelul de dezvoltare al proiectului in care este facuta testarea : alpha
testing, beta testing, regression testing, acceptance testing, smoke test.
6. In functie de tipul de scenariu : testare cu scenarii pozitive si testare cu scenarii negative
7. In functie de gradul de pregatire pentru tesatre : documentation testing, exploratory
testing, ad-hoc testing.
8. In functie de baza pe care este facuta testarea : testare bazata pe test case-uri si testare
bazata pe experienta.

https://www.utest.com/articles/the-classification-of-types-of-software-testing

8. Testarea de tip “Black box”.
In cadrul testarii de tip black box, nu este cunoscut codul sursa al programului. In timpul
acestui tip de testare se interactioneaza cu interfata sistemului, facand actiuni pe care un
utilizator normal le-ar putea face si examinand rezultatele. In cele mai multe cazuri, acest tip de
testare se bazeaza pe test case-uri. In aceasta categorie putem incadra si testarea functionala si
non functionala.

8.1 Tehnici de testare black box
Aceste tehnici au rolul de a ajuta testarea produsului si de a minimiza numarul de test case-uri.
1. Tehnica partitiilor echivalente (equivalence partitioning)
Utilizand aceasta tehnica se reduce foarte mare parte din munca. Procesul consta in gruparea
conditiilor de test in grupuri mai mici, astfel incat sa fie testata doar o singura valoare din cadrul
unei partitii, nu toate.
2. Analiza valorilor limita (boundary value analysis)
In cazul acestei tehinici, la fel ca la tehnica precedenta se impart conditiile de test in partitii,
diferenta fiind ca aici se testeaza doar valorile limita (superioara si inferioara) si o valoare de
mijloc. Spre exemplu, daca un utilizator are dreptul sa isi aleaga o parola care poate avea intre 6
si 10 caractere, se va testa in primul rand cazul in care se introduce o parola mai mica de 6
caractere (nu ar trebui sa fie permis si in general va fi afisat un mesaj de eroare), cazul in care
care se introduce o parola mai mare de 10 caractere (la fel nu ar trebui sa fie permis) si inca un
caz in care se va introduce o parola care este intre 6 si 10 caractere, teoretic, acest lucru fiind
permis. Aceasta tehnica este folosita atunci cand exista mult prea multe cazuri de testat
individual.
3. Tehnica tablei de decizii (decision table testing)
Aceasta tehnica este folosita pentru softurile in care exista combinatii complexe de intrari
(input-uri) care cumulate pot duce la decizii diferite. Este de altfel cunoscuta ca si tabelul ‘cauza
efect’.
4. Testarea tranzitiilor (state transition table)

Orice sistem aflat sub test poate sa genereze rezultate diferite pentru aceeasi intrare, totul
depinzand de conditiile exterioare, asta insemnand ca s-a trecut la alta stare de tranzitie.
5. Testarea exploratorie (exploratory testing)
Partea de exploratory testing se face de catre un tester care se transpune in locul unui utilizator
normal si face anumite actiuni strategice pentru a maximiza ariile acoperite de teste.
Acest tip de testare se poate considera de tip black box deoarece nu este necesara cunoasterea
codului sursa ci a cerintelor clientului si al comportamentului normal al aplicatiei.

6. Ghicirea erorilor (error guessing testing)
Acest tip de testare este facut de obicei doar de testerii cu experienta. O astfel de persoana
intuieste usor care parti ale aplicatiei sunt afectate de anumite schimbari, care sunt componentele
in care apar cel mai des erorile dar si partile sensibile ale unei aplicatii.

9. White box testing
Acest tip de testare se ocupa cu testarea si analizarea structurii interne a programului, ceea ce
inseamna ca avem acces la codul sursa. Se aplica pentru unit testing, integration testing si system
testing.
Ca si tehnici principale ale testarii de tip white box putem aminti:
1. Statement coverage
Scopul acestui tip de testare este de a asigura fiecare instructiune din cod este executata macar o
data.
2. Decision coverage
Scopul acestui tip de testare este de a asigura ca fiecare decizie (if, elese, for) a fost executata
macar o data.
3. Condition coverage
In aceasta etapa fiecare conditie din cod este executata macar o data.

Ca si tehnici secundare ale testarii de tip white box putem amninti:
1. Api Testing
Este testarea aplicatiei folosind API (aplication programing interface) public si privat. API este
un set de subrutine, protocoale si instrumente pentru construirea aplicatilor software. Aceasta se
poate considera si o metoda de comunicare dintre mai multe componente software.
2. Code coverage
Se creaza teste pentru a se observa daca codul satisface toate crietriile.
3. Fault injection
Aceasta tehnica consta in introducerea intentionata a unor greseli in cod pentru a se observa
eficacitatea tehnicilor de testare.
4. Mutation testing

Acesata tehnica consta in modificarea programului in mici moduri. Fiecare versiune se numeste
‘mutant’, iar testele ar trebui sa respinga aceste versiuni datorita comportamentului codului
original. Scopul este de a ajuta testerul sa localizeze slabiciunile in sectiuni de cod neaccesate in
timpul executiei.
5. Static testing
Implica analiza softului si a codului fara a fi executat.

10. Testare functionala
Testarea functionala verifica fiecare parte dintr-un program software pentru a se asigura
ca cerintele sunt implementate corect si sistemul functioneaza adecvat. Cu alte cuvinte, se
verifica daca ce ar trebui sa faca sistemul aflat sub test chiar face.

Atunci cand sunt facute teste de tip functional trebuie avut in vedere :
1. Se identifica datele pentru intrari
2. Se determina care ar trebui sa fie rezultatul asteptat bazat pe acele intrari
3. Rularea de cazuri de test cu intrarile propriu zise.
4. Compararea rezultatelor asteptate cu rezultatele actuale.
Urmand acesti pasi si comparand la final rezultatele asteptate cu rezultatele actuale, daca acestea
corespund testului i se va putea atribui statusul de ‘Passed’. In cazul in care rezultatele actuale si
rezultatele asteptate nu se potrivesc, astea inseamna ca exista o eroare in software.

10.1 Tipuri de testare functionala
● Unit Testing
Testele de tip unit sunt facute da catre developeri. Acestia isi testeaza codul, prin rularea unor
teste scrise de ei, pentru a observa daca indeplineste cerintele si face ceea ce ar trebui sa faca.
Acest tip de testare apartine si de ‘Black box testing’.
● Regression Testing
Acest tip de testare este unul amanuntit si este facut pentru a observa ca anumite schimbari in
cod, cum ar fi adaugarea de noi componente sau fixarea unor probleme nu au afectat si alte parti
deja existente ale aplicatiei sau nu au cauzat instabilitate. Acest tip de testare ar trebui facut
frecvent pentru a se asigura stabilitatea sistemului.
● Smoke testing
Acest tip de testare este rulata pentru functionalitatile principale. Este facuta inainte de a incepe
orice alt timp de testare, pentru a observa daca are sau nu rost sa se continue cu celelate tipuri de
testare.
● Sanity testing
Acest tip de testare este asemanator cu smoke testing. Este un subset al regression testing. Este
folosit cand timpul nu este de ajuns pentru a rula toate testele de tip regression sau cand au fost

facute doar schimbari minore in cod. Se testeaza doar partile majore ale aplicatiei pentru a se
observa daca schimbarile nu au afectat alte componente deja existente.
● Integration Testing
In cadrul acestui tip de testare, multiple module ale unui sistem care au fost dezvoltate separat
sunt considerate un intreg si sunt testate ca atare.
● Interface Testing.
Interfata este o conexiune care uneste doua sau mai multe componente. Acest tip de testare este
facuta pentru a asigura faptul ca doua sau mai multe sisteme sau componente controleaza si
transfera corect datele de la una la alta. In timpul rularii acestui tip de teste trebuie sa ne
asiguram ca : toate componentele software/hardware suportate au fost testate, comunicarea dintre
componente se face corect, orice documente astasat poate fi deschis si este suportat de toate
platformele, etc.
● System Testing
Acest tip de testare verifica comportamentul sistemului complet integrat, insa de cele mai multe
ori nu avem o interfata reala a produsului. Daca la integration testing atentia se concentreaza pe
gasirea problemelor cauzate de integrarea a doua sau mai multe module, in aceasta faza scopul
este gasirea problemelor sau a defectelor in comportamentul general aplicatiei si de asemenea se
doreste sa se observedaca aplicatia indeplineste cerintele specificate. Datele folosite in testare
sunt prefabricate, ne fiind folosite datele reale din productie pentru acest tip de testare. System
testing este de tip black box dar se poate incadra atat la functional testing cat si la non functional
testing.
● UAT (user acceptance testing)
UAT este facut dupa system testing. In acest tip de testare se verifica comportamentul aplicatiei,
dupa ce toate modulele au fost unite, utilizandu-se date reale, din productie. Testerul trebuie sa se
comporte ca un utilizator real pentru a valida faptul ca aplicatia indeplineste cerintele clientului.
Apartinand de black box testing, acest timp implica toate multe tehnici de tesatre cum ar fi
boundary value analysis, equivalence partitoring and decision table testing. De asemenea se
testeaza sistemul si cu intrari intamplatoare, iar defectele gasite sunt considerate esecuri ale
produsului.

11. Testare non-functionala
Testarea de tip non-functional verifca aspectele care nu tin de functionalitatile aplicatiei
cum ar fi securitatea, perforamanta, scalabilitatea, etc. Este important ca cerintele pentru testare
sa fie prioritizate si atributele calitatii sa fie identificate corect.
Un prim scop al testarii de tip non functional este acela de a reduce riscurile gasirii
punctelor slabe ale aplicatiei in productie si a cheltuielilor asociate acestora.

Un al doilea scop este de a ajuta optimizarea produsului in aspectele esentiale oricarui
soft cum ar fi instalarea, executarea, gestionarea si monitorizarea.
De asemenea un al treila scop este colectarea datelor si efectuarea de masuratori pentru
cercetare si dezvoltare interna si de asemenea pentru a imbunatati comportamentul si tehnologiile
produsului aflat in uz.
Nu in ultimul rand, testarea de tip non functional are rolul de a creste performanta la
utilizare, mentenabilitatea, eficienta si portabilitatea produsului.

● Performance testing
Este executat pentru a determina cum un sistem functioneaza in ceea ce priveste stabilitatea,
capacitatea si viteza de reactie, stabilitatea in cadrul unui anumit volum de munca si date sau
cum utilizeaza resursele. Dupa rulea acestor tipuri de teste se poate determina spre exemplu
numărul de utilizatori virtuali, accesările pe secundă, erorile pe secundă, timpul de răspuns,
laten ț a ș i octe ț ii pe secun dă (capacitatea de transfer), precum ș i corela ț iile dintre acestea.
Fiind un tip de testare complex, acesta cuprinde inca doua tehnici de testare:
Load testing este recomandat sa se faca atunci cand se doreste determinarea numarului de
utilizatori pe care sistemul ii poate gestiona.
● Failover Testing
● Security Testing
● Compatibility Testing
● Usability Testing
● Stress Testing
● Maintainability Testing
● Scalability Testing
● Volume Testing
● Security Testing
● Disaster Recovery Testing
● Compliance Testing
● Usability Testing
● Portability Testing
● Efficiency Testing
● Reliability Testing
● Baseline Testing
● Endurance Testing
● Documentation Testing
● Recovery Testing
● Internationalization Testing
● Localization Testing
● Instalation testing

Majoritatea produselor software au nevoie de instalare pentru a functiona si proceduri diferite in
acest scop. Acest tip de testare verifica daca produsul se instaleaza, dezinstaleaza si actualizeaza
corect. Exista multe medii de operare, cee ce inseamna ca este un proces complex. Un program
se poate instala in diferite moduri, poate adauga diferite fisiere pe drive si poate face anumite
schimbari in sistemul de operare sau poate avea acces la anumite date (locatie, camera, microfon
etc.)