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… [603422]

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 sau devieri de la cerintele clientului.

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 cu grija rezultatele.

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)