1.2 Cand se poate incepe/opri procesul de testare? 1.3 Bug -uri software celebre 1.4 Metodologia Waterfall 1.5 Metodologia Agile 1.5.1 Scrum 2…. [610148]

Cuprins

PLANIFICAREA ACTIVITATII
ABSTRACT
LISTA ABREVIERI
LISTA FIGURI
LISTA TABELE

1. Stadiul actual
1.1 Testare software
1.2 Cand se poate incepe/opri procesul de testare?
1.3 Bug -uri software celebre
1.4 Metodologia Waterfall
1.5 Metodologia Agile
1.5.1 Scrum
2. Fundamente teoretice
2.1 Testare manuala. Generalitati.
2.2 Testare automata
2.3 Clasificarea generala a tipurilor de testare
2.4 Testarea de tip Black -Box
2.4.1 Tehnici de testare de tip Black -Box
2.5 Testar ea de tip White Box
2.6 Testarea de tip Gray Box
2.7 Testarea functionala
2.7.1 Tipuri de testare functionala
2.8 Testarea non -functionala
2.8.1 Tipuri de testare non -functionala.
3. Implementare
3.1 Cazuri de test
3.2 Tehnologii utilizate pentru testarea automata aplicatiilor.
3.3 Implementarea testelor automate
4. Rezultate experimentale
4.1 Costurile testarii software
4.2 Costurile defectelor software
4.3 Analiza SWOT a testarii automate.
4.4 Analiza SWOT a testarii automate
4.5 Metode de optimizare si reducere a costurilor
5. Concluzii
6.Bibliografie

LISTA DE ABREVIERI

WEB
OOP
TC
ID
XPATH
CSS

LISTA DE FIGURI

Figura 1.1 Etapele metodologiei Waterfall

Figura 1.2 Ciclul de dezvoltare Agile
Figura 2.1 Testarea de tip Black box
Figura 2.2 Testarea de tip White box
Figura 2.3 Testarea de tip Gray box
Figura 3.1 Cautarea unui element in structura paginii WEB
Figura 3.2 Element care necesita identificare cu XPATH
Figura 3.3 Element care necesita identi ficare pe baza de ID
Figura 3.4 Element care necesita identificare cu CSS selector
Figura 3.5 Element care necesita identificare pe baza de clasa
Figura 3.6 Element care se poate identifica dupa nume
Figura 3.7 Status ‘Passed’ in Intelij
Figura 3.8 Statu s ‘Failed’ in Intelij
Figura 4.1 Raport erori
Figura 4.2 Ciclul de viata al unui bug
Figura 4.3 Raportarea unui bug
Figura 4.4 Proveninenta defectelor
Figura 4.5 Utilizarea resurselor de test
Figura 4.6 Costul relativ al remedierii defectelor

LISTA DE TABELE

3.1 Caz de test pentru autentificarea cu facebook
3.2 Caz de test pentru cosul de cumparaturi
3.3 Caz de test pentru editarea datelor

4.1 Analiza SWOT a testarii automate
4.2 Analiza SWOT a testarii manuale
4.3 Exemplu de coresponde nta intre criteriile de intrare si de iesire

Planificarea activității

Sarcini de lucru

Data inceperii
Numar zile
Data sfarsit

Alegerea temei
10.11.2017

1
10.11.2017
Studiu bibliografic și
acumularea de
cunoștințe legate de
tema proiectului

10.11.2017

45
07.03.218

Studiul utiliz ării
aplicațiilor

07.03.2018

25
01.04.2018

Scrierea testelor
manuale/ automate
Redactarea lucrarii

01.04.2018

80

09.07.2018

Printare si legare

09.07.2018
2
11.07.2018

Termen de predare

12.07.2018
1
12.07.2018

1.State of the Art

I have elaborated this thesis in order to present the benefits of software t esting and what
are the differences between differen t types of software testing and test methodologies . When you
want to validate a developed application, you need a good test strategy in order to confirm the
validity and functionality of the application. The best way to do that, is trying to find as many
bugs and fails as you can, in order to prevent and fix the possible issues that can appear.
Why is testing important? Well, t esting is important because software bugs could be
expensive or even dangerous. Software bugs can potentially cause monetary and human loss,
history is full of such examples.
What is software testing? In general, testing is finding out how well something wo rks. In
software development, testing is used in various checkpoints of the o verall process to determine
whether objectives /requirements are being met. For exa mple, in software development, product
objectives are sometimes tested by product user representatives. When the design is complete,
coding follows and the finished code is then tested at the unit or module level by each
programmer. A t the component level by the group of programmers involve and at the system
level when all components are combined together. At early or late stages, a product or service
may also be tested for usability.
Some decades ago, many parts of software were tested only manually or not at all. The
integration of testing into development was through a wall over which developers threw the
software to dedicated testers. Test coverage ana lysis and A/B testing were techniques many of us
only heard of in college and never saw applied in practice. The most striking sign of progress is
visible in industrial practice.

2.Theoretical Fundamentals

The trend and competency of testing is changing . Testers are now required to be more
technical a nd process oriente d. Nowadays, testing is not just about finding bugs. It has a wider
scope and is required right from the beginning of the project when the requirements are not
even finalized.
Since tes ting is also standardized, j ust like software development has a lifecycle, t esting
too has a lifecycle. In the next paragraphs , I will be presenting what a life cycle is and how is
related to software testing .
Lifecycle in simple term refers to the sequence of changes from one form to another.
These changes can happen to anything . Every entity has a lifecycle from its start to end.
In a similar way, s oftware is also an entity. Just like developing software involves a
sequences of steps, testing also has steps which should be executed in a definite sequence.
This phenomenon of executing the testin g activities in a systematic and planned way is
called testing life cycle.

Software Testing Life Cycle (STLC) refers to a testing process which has specific steps to
be executed in a definite sequence to ensure that the quality goals have been met. In STLC
process, each activity is carried out in a planned and systematic way. Each phase has different
goals and deliverables .
STLC phases are :
1.Requirement Phase : This phase is for analyzing and study ing the requirements. . It helps you to
identify the scope of the testing. If any feature is not testable, this is the perfect moment to
communicate it so the strategy can be changed .
2.Planning Phase : In practical scenarios, test planning is the first step of the testing process. I n
this phase we identify the activities and resources which would help to meet the testing
objectives. During planning we also try to identify the metrics, the method of gathering and
tracking those metrics.
3.Analysis Phase : This STLC phase defines what to be tested. We basically identify the test
conditions through the requirements document, product risks and other test basis. The test
condition should be traceable back to the requirement.
4.Design Phase : This phase defines how to test.
5.Implementation Phase : The major task in this STLC phase is the creation of the detailed test
cases. Prioritize the test cas es, identify which test case will become part of the regression suite.
Before finalizing the test case, It is important to carry out the review to ensure the correctness of
the test cases.
6.Execution Phase : This is the phase where the actual execution takes place. Before you start the
execution, make sure tha t all the requirements/criteria is met.
7.Conclusion Phase : This phase is concentrated on the exit criteria and reporting. There are
different types of reports as : Daily Status Report, Weekly Status Report; The content of the
report can change depending on whon is running the test.
8.Closure Phase : C heck the completion of the test and create the test c losure report.
In other words software testing is a verification and validation process.
Verification is the process to make sure the product satisfies the conditions imposed at
the start of the development phase.
Validation is the process to make sure the product satisfies the specified requirements at
the end of the development phase.
BLACK BOX TESTING, also known as Behavioral Testing, is a software testing method
in which the internal structure/design/implementation of the item being tested is not known to the
tester. These tests can be functional or non -functio nal, though usually functional.

This method is named so because the software program is like a black box inside whi ch
one cannot see.
Black Box Testing method is applicable to the following levels of software testing :
Integration Testing, System Testing, Acceptance Testing .
The following techniques can be used for designing black box tests:
-Equivalence Partitioning: It is a software test design technique that involves dividing input
values into valid and invalid partitions and selecting representative values from each partition as
test data.
-Boundary Value Analysis: It is a software test design technique that involves the determination
of boundaries for input values and selecting values that are at the boundaries and just inside/
outside of the boundaries as test data.
-Cause -Effect Grap hing: It is a software test design technique that involves identifying the cases
(input conditions) and effects (output conditions), producing a Cause -Effect Graph, and
generating test cases accordingly.
Black box testing has the following advantages :
-Tests are done from a user’s point of view and will help in exposing discrepancies in the
specifications.
-Tester need not know programming languages or how the software has been implemented.
-Tests can be conducted by someone who doens ’t have contact with developers, allowing for an
objective perspective and the avoidance of developer -bias.
-Test cases can be designed as soon as the specifications are complete.
The black box te sting has also some disadvantages :
-Only a small number of possibl e inputs can be tested and many program paths will be left
untested.
-Without clear specifications, which is the situation in many projects, test cases will be difficult
to design.
-Tests can be redundant if the software designer/developer has already run a test case.
WHITE BOX TESTING, also known as Structural Testing is a software testing method
in which the internal structure/design/implementation of the item being tested is known to the
tester. The tester chooses inputs to exercise paths throu gh the code and determines the
appropriate outputs. Programming know -how and the implementation knowledge is essential.
This method is named so because the softw are program, in the eyes of the tester, is like a
transparent box inside which one clearly sees.
White Box Testing method is applicable to the following levels of software testing: Unit
Testing, Integration Testing , System Testin g.
The advantages of white box testing are :
-Testing can be started at an earlier stage.
-Testing is more t horough, with the possibility of covering most paths.

The main disadvantages are :
– Since tests can be very complex, highly skilled resources are required, with a thorough
knowledge of programming and implementation.
-Test script maintenance can be a hard if the implementation changes too frequently.
Since this method of testing is closely tied to the application being tested, tools to cater to every
kind of implementation/platform may not be readily available.

1.Stadiul actual

1.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 clien tului. 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 verificare a 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 t esta pentru toate combinatiile de intrari si preconditii.

1.2 Cand se incepe/opri 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 neces ar fixarii acestuia.
Momentul inceperii testarii depinde si de modelul de lucru folosit pentru dezvoltarea software
ului. (Agile, Waterfall etc.)
Este greu de realizat cand procesul de testare poate lua sfarsit. In general nu este nimeni
care poate declar a 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 per ioadei de testare.
2. Executarea tuturor cazurilor de test care sunt scrise.
3. Rata de defecte scade sub nivelul impus de catre client.

1.3 Bug -uri software celebre

1.World of Warcraft (WOW)
In anul 2005, in cadrul celebrului joc WOW, care are un numar apr oximativ de 10
milioane de jucatori, s -a introdus un nou personaj numit Hakkar, care avea ca si putere speciala

infectarea personajelor altor jucatori cu o boala, care ar putea fi apoi transferata si altor
personaje. Boala ar fi trebuit limitata doar la o anumita arie a jocului si sa vizeze doar
personajele de rang inalt. Dintr -o greseala a fost uitata restrictia de zona ceea ce a dus, ceea ce a
dus la moartea personajelor jucatorilor in masa, personajele mai slabe fiind foarte usor de ucis in
joc, boala raspnadindu -se rapid in intreaga lume a jocului. Aparent, acest incident ar fi fost
folosit de catre cercetatori pentru a studia cum ar reactiona populatia la o pandemie.
2. AT&T
In anul 1990, compaia de telefonie a fost dezactivata datorita unei erori c auzate de
comutatoarele care faceau o resetare continua. S -au estimat pierderi in cadrul companiei de 60
milioane dolari.
3 PayPal
In anul 2007, un american a devenit cel mai bogat om din lume dupa ce PayPal i -a virat
din greseala in cont $92,233,720,368, 547,800 . PayPal si -a retras banii din contul persoanei
respective, dar s -au oferit sa faca o donatie organizatiei de caritate a acestuia pentru a -si indrepta
greseala.
4. Mariner 1 rocket
In anul 1962 s -a declarat cel mai scump bug din istorie. Naveta sp atiala in valoare de 18,5
milioane de dolari a fost proiectata pentru a fi lansata pe Venus. La scurt timp dupa lansare
acesata a inceput sa nu mai raspunda comenzilor sistemelor de orientare si s -au detectat manevre
neprogramate asa ca s -a ordonat distrug erea ei dupa doar 295.5 secunde de zbor si functionare.
5. Apple Maps
Datorita rivalitatii sale cu Google, Apple a hotarta sa scoata aplicatia ‘Google maps’ si sa
o inlocuiasca cu o aplicatie de harti scrise in cadrul companiei. Insa, in hartile deszvolt ate au
existat multe lacune. Lipseau lacuri, gari, statii de tren sau multe dintre el erau marcate gresit.
Muntele din Washington se misca de -a lungul strazii iar un supermarket era marcat ca si spital,
desi spitalul se desfiintase cu 11 ani in urma. In ca drul functionalitatii de vedere 3D pareau sa se
topeasca in apa iar o gara din Noua Zeenlanda era plasata in mijlocul oceanului.
Datele care stau la baza unei aplicatii de acest gen provin din zeci de baze de date
diferite, pentru drumuri, fotografii din satelit, puncte de interes etc. Interconectarea acestora
pentru a crea aplicatii de cartografienu necesita doar aplicatii inteligente ci si mii de ore si zeci
de oameni care sa execute manopera. Google a avut timp cativa ani sa finalizeze aceasta
operatiun e, dar Apple nu. Desi problemele au fost rezolvate cu timpul, oamenii si -au pierdut
increderea in Apple Maps.
6. Deschiderea terminalului Heatrhrow
In marea Britanie, inainte de deschiderea terminaului Heatrhrow s -a implementat un
sistem de manipulare a bagajelor, construit pentru a usura manipularea cantitatilor mari de bagaje
verificate zilnic. Inginerii responsabili au testat linia inainte de deschidere cu peste 12.000 bagaje
de proba. A funtionat fara probleme la toate rundele de testare, dar la des chiderea aeroportului s –
a aflat ca linia nu a putut face fata scenariilor din viata reala, cum ar fi spre exemplu inlaturarea
unui bagaj manual din sistem pentru ca un pasager uitase ceva acolo. Sistemul a devenit confuz
si s-a oprit. In urmatoarele zile, pana la rezolvarea problemelor, aproximativ 42.000 bagaje nu au
reusit sa calatoreasca alaturi de proprietarii lor si 500 zboruri au fost anulate.

1.4 Metodologia Waterfall

Modelul ‘Waterfall’ a fost primul model de dezvoltare software introdus si se r efera la o
liniaritate secventiala de ciclu de dezvoltare. Este un model foarte simplu de inteles. Fiecare faza
in parte trebuie sa se finalizeze ca urmatoarea faza sa inceapa. La sfarsitul fiecarei etape, are loc
o analiza pentru a determina corectitudine a muncii facute si daca are sau nu rost continuarea
respectivului proiect.
Este recomandat sa se foloseasaca la proiecte de dimensiuni mici care au cerinte clare.
Fazele acestui proiect nu se suprapun, ceea ce inseamna ca testarea va incepe doar dupa
finalizarea completa a fazei de dezvoltare.
Un prim avantaj clar este acela ca este usor de inteles si de utilizat. Un al doilea avantaj
este ca prin rigiditatea procesului, fiecare faza este bine definita si este clar cand, cum si ce va fi
livrat dupa o anum ita etapa. Un al treilea avantaj este acela ca etapele nu se suprapun.
Ca si dezavantaje putem enumera faptul ca o data trecut dintr -o etapa in alta, este foarte
dificil sa se revina la stadiul precedent pentru a face anumite verificari sau pentru a core cta unele
erori. De asemenea, un al doilea dezavantaj este ca nu poate fi livrat nimic pana la sfarsitul
ciclului de dezvoltare si este inconjurat de risc si incertitudine. Un al treilea dezavantaj este ca nu
poate fi recomandat pentru proiectele foarte co mplexe, sau pentru cele ale caror cerinte sunt
predisupuse mereu la schimbare.

Fig 1.1 Etapele metodologiei Waterfall.

Prima etapa ‘Requirements’ consta in citirea intelegerea cerintelor clientilor. Trebuie sa
fie inteles scopul, rolul si f unctionalitatile ce vor urma sa fie implementate. Este o etapa foarte
importanta, deoarece o intelegere gresita va duce la mari erori in produsul final.
In ce -a de-a doua etapa ‘System design’ (etapa de design), pe baza cerintelor studiate in
etapa anter ioara, se pregateste design -ul si se defineste arhitectura viitorului produs.
Bibliografie
In ce -a de-a treia etapa, ‘Implementation’ (etapa de implementare ), se scrie cod pentru
dezvoltarea propriu zisa a sistemului. La inceput, de cele mai multe ori s e dezvolta initial un
unitati mai mic, care urmeaza sa fie unite si testate ca un intreg in urmatoare faza.

Ce-a de-a patra etapa este etapa de testare. Toate unitatile care au fost dezvoltate anterior
acum sunt unite si testate ca un intreg. Dupa incheie rea acestei etape trebuie sa se poata garanta
ca soft -ul nu va avea probleme si erori.
In ce -a de-a cincea etapa numita ‘Deployment’, dupa finalizarea tuturor testelor
functionale si non -functionale, se trimite produsul clientului, sau se lanseaza direct pe piata, in
functie de caz.
Ultima etapa, este mentinerea sistemului (maintenance). Acest pas implica modificare
sistemului sau a unei compnente individuale pentru o mai buna performanta, dupa instalarea
acestuia. De asemenea consta si in repararea erori lor nedescoperite si in suport periodic.

1.5 Metodologia Agile

Figura 1.2 Ciclul de dezvoltare Agile

Agile este o metodologie de dezvoltare a proiectelor care consta in abordarea dezvoltarii
software ului prin efort colaborativ al echipelor. Acest lucru consta intr -o planificare riguroasa,
dezvoltare evolutiva, livrare mult mai rapida decat in cazul modelului Waterfall, posibilitate
continua de imbunatatire, flexibilitate si raspuns la schimbare.
Ca si avantaje a Agile, putem aminti faptul ca foar te multe persoane sunt implicate si
informate in procesul de dezvoltare al produsului inclusiv departamentul de bussiness,
colaborarea si comunicarea dintre echipe fiind un lucru deosebit de important.
Ca si dezavantaj, putem mentiona faptul ca multe din organizatii, adapteaza in felul lor
acest tip de metodologie si prin abaterea de la regulile si procedurile clasice, rezultatul final
poate fi diferit. Un alt dezavantaj este acela ca, scopul unor actiuni deja incepute poate fi
schimbat usor, ceea ce va d uce la nemultumiri din partea echipei de dezvoltare.
Scrum este un subest al Agile, folosit pentru gestionarea problemelor complexe de
dezvoltare. Cee ce este specific acestei modalitati de lucru sunt sedintele aferente, formula si
membrii echipei si arte factele, care se urmeaza cu strictete si nu se schimba.

1.5.1 Scrum

In metodologia Agile -Scrum, se lucreaza in sprint -uri. Un sprint este considerata o
perioada de munca, care poate fi intre 1 si 4 saptamni, cea mai intalnita perioada fiind de 2
saptama ni. Ceea ce evidenteaza Agile de alte metodologii de lucru, spre exemplu Waterfall, este
faptul ca ca la sfarsitul fiecarei perioade de sprint, este livrat ceva functional.
In cadrul scum, exista 4 sedinte, care ii ofera structura sprintului, acestea fii nd sprint
planning, daily stand -up, sprint demo si sprint retrospective.
Sprint planningul este sedinta facuta la inceputul fiecarui sprint impreuna cu toata echipa,
pentru a planifica activitatile necesare pentru a indeplini scopul sprintului ce va urma .
Daily stand -up-ul este o sedinta care se tine zilnic, dureaza intre 15 si 30 minute, in care
fiecare membru al echipei in parte va spune ceea ce a facut ieri, ce va face astazi si daca
intampina probleme care ii blocheaza activitatea. Scopul acestei in talniri este sincronizarea
membrilor echipei si sporirea comunicarii.
Sprint demo este sedinta de la sfarsitul sprintului in care echipa prezinta ceea ce a realizat
in perioada alocata
Sprint review, este sedinta care in general este facuta dupa sprint demo. Este una foarte
importanta, deoarece se discuta despre modul in care a descurs sprintul. Se dezbate ceea ce a
decurs bine in sprint, cee ce ar putea fi imbunatatit, ceea ce nu a functionat si actiunile care
trebuie facute pe viitor pentru imbunatatir ea rezultatelor finale a urmatoarelor sprint -uri.
O alta parte importanta a Scrum ului este structura echipei. Aceasta este formata dintr -un
Scrum Master un Product Owner si echipa efectiva, formata de obicei din 5 -7
oameni(programatori, testeri devOps, etc.)
Product Owner -ul este persoana care se focuzeaza pe intelegerea cerintelor clientului dar
si pe intelegerea cerintelor pietei. Acesta tine legatura cu clientii, se concentreaza ca echipa sa
livreze cel mai bun produs si de asemenea se asigura ca toat a lumea intelege ceea ce are de facut
si cum se doreste sa arate urmatoarea parte din produs care urmeaza sa fie livrata. Scopul
acestora este sa se asigure ca este livrat cel mai bun produs.
Scrum Master -ul are rolul de a monitoriza atat echipa cat si Pr oduct Owner -ul. Acesta
planfica resursele necesare indeplinirii scopului sprint -ului, atat cele umane cat si cele de natura
logistica. De asemnea are rolul de a ajuta echipa in procesul de optimizare al produsului pentru
livrare si incearca sa nu permita s chimbarea scopului sprint -ului.
Echipa in sine este formata de 5 -7 membrii. Membrii echipei, in functie de tipul de
proiect pot fi deveoperi, testeri, web developeri, devops, web designer etc. Acestia se
completeaza si se ajuta reciproc, pentru a putea a sigura o finalizare de succes a sprintului. In
esenta, echipa conduce sprintul, deoarece ei estimeaza cata munca si ce sarcini pot face in timpul
alocat. Mentinerea duratei fixe a sprintului ofera echipei de dezvoltare o perspectiva reala privind
procesul de dezvoltare si livrare, ceea ce va face ca estimarile acestora sa devina din ce in ce mai
exacte.
O alta componenta importanta a scrum -ului sunt artefactele, in numar de 4 : product
Backlog, sprint Backlog, burn -down chart si increment.
Product backlo g este o lista prioritizata a tuturor cerintelor necesare pentru indeplinire,
pana la finalizare produdului. In ‘Product backlog’, apar toate caracteristicile, corectiile, cerintele
si functionalitatile care constituie modificari care trebuie facute produd ului in versiunile viitoare.
Elementele acestei liste, au fiecare in componenta, descriere, ordine, exprimare si valoare. Acest
artefact este in continua dezvoltare, deoarece in timpul dezvoltarii software a produsului pot
aparea cerinte noi sau se pot sc himba sau pot aparea cereri de imbunatatire, dar de asemnea
provoaca schimbari in product backlog si modificari ale tehnologiei sau ale conditiilor de piata.

La inceputul fiecarui sprint sunt alese anumite user story -uri, care au fost prioritizate in
sproduct backlog pentru a merge in sprint backlog, plus un plan pentru livrarea produsului si
realizarea scopului propus. Acest plan contine detalii scrise concis pentru a putea fi intelese de
catre toata lumea, si pentru a putea fi usor de urmarit in cadrul sedintelor zilnice de stand -up.
Acest plan fiind practic o prognoza a echipei cu privire la ce functionalitate va fi gata si la
activitatile necesare. In cazul in care o noua activitate va fi necesara in cadrul sprintului, aceasta
va fi adaugata si la spr int backlog. Pe masura ce sarcinile sunt efectuate si finalizate, munca
ramasa estimata este actualizata. Sprint backlog ofera o imagine in timp real a municii pe care
echipa o realizeaza in timpul sprintului.
Incrementul este suma tuturor articolelor din backlog finalizate in timpul unui sprint,
combinate cu suma articolelor din backlog din sprint -urile anterioare. La sfarsitul fiecaruei
perioade de sprint, incrementul trebuie sa fie un produs in stare de functionare. Fiecare echipa va
trebui sa ajunga si ngura la un consens cu privire la ce inseamna pentru ei un increment.
Echipa trebuie sa ofere o crestere a functionalitatii produsului la sfarsitul fiecarui sprint, de aceea
este important sa se stie si sa se estimeze corect un numar articole din backlog care poate fi luat
in sprint si finalizate corespunzator in perioada aferenta. Fiecare increment este adaugat la
incrementarile anterioare si testat riguros pentru a se asigura ca noua funtionalitate implementata
sau modificare facuta nu afecteaza restul a plicatiei.
Burn -down chart se foloseste pentru monitorizarea activitatii ramase in sprint si a
progresului. Product Owner -ul urrmareste astfel munca ramasa la sfarsitul sprintului, compara
acest volum de munca cu cel ramas la sfarsitul sprint -urilor anter ioare, pentru a putea evalua
progresul facut cu privire la estimari si la finalizarea muncii in intervalul de timp dorit.
Pentru un proces eficient, toate sedintele si artefactele sunt necesare sa fie respectate.
Daca doar anumite parti sunt implementate in cadrul unei companii, rezultatul nu este ‘Scrum’ si
nu va putea fi niciodata la fel de eficient, deoarece necesita implementare totala.

2. Fundamente teoretice

2.1 Testarea manuala. Generalitati

Testarea manuala este un tip de testar e 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 ma re 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 treb uie 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 s i 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 case). O data ce cerintele si specificatiile au fost intelese, se poate incepe scrierea propriu –
zisa a cazurilor de t est.
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 proces ului 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 us urinta. 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 vo r 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.

2.2 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 fo losite 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 vo rba 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 simul tan (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 necesi ta 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.

2.3 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: funct ional 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 fu nctie 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 facut a testarea : testare bazata pe test case -uri si testare
bazata pe experienta.

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

2.4 Testarea de tip “Black box”.
In cadrul testarii de tip black box, nu este cunoscut codul sur sa 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.

Figura 2.1 Black Box testing

2.4.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. Teh nica 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 inferi oara) 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 fii nd
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 (i nput-
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 an umite 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. Gh icirea 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.

2.5 Testarea de tip White box

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 testin g, integration testing si
system testing.

Figura 2.2 Testarea de tip White box

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 maca r 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 trebu i 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 exe cutat.

2.6 Testarea de tip Gray Box

Fig 2.3 Testarea de tip Gray box

Testarea de tip Gray box se poate considera o combinatie dintre celelalte tipuri de
testare, white box si black box. Implica cunostinte despre cod/date/algoritmi. Test case -urile se
construiesc avand acces la aceste date, dar se executa utilizand tehnica ‘Black box’.
Acest tip de testare este util spre exemplu, in cazul unui ‘integration testing’, cand este
vorba despre doua modeule scrise de doi developeri diferiti si doar interf ata utilizatorului este
expusa pentru test.

2.7 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 intrar i
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 s tatusul de ‘Passed’. In cazul in care rezultatele actuale si
rezultatele asteptate nu se potrivesc, astea inseamna ca exista o eroare in software.

2.7.1 Tipuri de testare functionala

● Unit Testing
Testele de tip unit sunt facute da catre developeri. Ace stia 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 amanun tit 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 cel elate 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 schim bari 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 dezvol tate
separat sunt considerate un intreg si sunt testate ca atare.
Integration testing are doua tehnici principale, botton up integration testing si top down
integration testing.
In cadrul a ‘botton up integration testing’ sunt testatet mai intain componen tele cu nivel
inferior, iar dupa testare sunt folosite pentru a facilita testarea componentelor cu nivel superior.
Acest tip de testare ajuta la determinarea nivelului de dezvoltare al softului si face mai usoara
dterminarea nivelului de progres al testari i, in procente.
In cadrul a ‘top down integration testing’, abordarea se face prin testarea in prima faza a
modulelor de varf deja integrate, iar ramura modului respectiv este testata pas cu pas pana la
finalizarea testelor pentru modulul repsectiv.
● Inter face 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 ru larii 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 sa u 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 te sting. 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 ceri ntele 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 de fectele gasite sunt considerate esecuri ale
produsului.

2.8 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 c a 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 asoci ate 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.

2.8.1 Tipuri de testare non -functionala

● 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 anumi t 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 secundă (capacitatea de transfer), precum și corelațiile dintre
acestea.
Fiind un tip de testare complex, acesta cuprinde inca doua tehni ci de testare.
Prima tehnica este ‘load testing’ aceasta fiind recomandata sa se faca atunci cand se
doreste determinarea numarului de utilizatori pe care sistemul ii poate gestiona si a capacitatii
maxime de operare a unei aplicatii. Se pot stabili difer ite scenarii de test pentru concentrarea pe
anumite functionalitati ale aplicatiei pe care exista posibilitatea sa fie multi utilizatori simultan
pentru a determina cata memorie CPU este cosnumata si care este timpul de raspuns al retelei.
De asemenea se poate determina modul in care se incarca aplicatia, asta diferind de la dispozitiv
la dispozitiv sau cum se sutine sistemul per total.
Acest tip de testarea poate fi facut sub conditii controlate pentru a compara capabilitatile
si performantele diferitel or tipuri de sisteme sau a determina cu exactitate capacitatea unui singur
sistem.
Scopul principal al acestui tip de sistem este de a determina capacitatea maxima de
munca pe care un sistem o poate face, insa fara o degradarea semnificativa a performantei .
Ca si exemple de load testing ar fi : descărcarea unei serii de fișiere de dimensiuni mai mari,
rularea simultan a mai multor aplicatii, atribuirea mai multor lucrări unei imprimante într -o serie,
supunerea unui server la o cantitate mare de trafic, scr ierea și citirea datelor de pe un hard disk
continuu.
Acesta este tipul de testare care ar trebui reluat frecvent, pentru a se asigura ca
performanta sitemului aflat sub test nu a scazut in urma unor modificari.

A doua tehnica de testare este ‘Stress t esting’. Acest tip de testare implica verificarea
functionarii unui sistem dincolo de capacitatile normale ale acestuia, pana se ajunge la un punct
in care aplicatia esueaza. In acest punct scopul este de a determina stabilitatea unui sistem dat. Se
pune u n accent mai mare pe partea de disponibilitate și tratare a erorilor sub o sarcină grea sau
sub un volum mare de date.
Pentru a efectua aceste tipuri de teste se utilizeaza seturi de date masive care se pot pierde
în timpul testelor. Obiectivele acestor t ipuri de teste sunt asigurarea faptului că software -ul nu se
prăbușește în condiții de resurse insuficiente de calcul (cum ar fi memoria sau spațiul de pe disc),
de asemenea determinarea punctului critic de operare si modul cum un sistem se recupereaza
dupa ce esueaza in cadrul unei sarcini.

● Failover Testing
Acest tip de testare validează capacitatea unui sistem de a aloca resurse suplimentare și
de a muta operațiile în sisteme de back up in cazul unei caderi a sistemului. De asemenea, se
folosete pentru a verifica capacitatea sistemului aflat sub test de a continua operațiunile în timp
ce capacitatea de procesare este transferată într -un sistem de back -up. Nu in ultimul rand se,
determină dacă un sistem poate aloca resurse suplimentare, cum ar fi memorie CPU sau servere
suplimentare, în timpul unor defecțiuni critice sau în momentul în care sistemul atinge un prag
prestabilit de performanță.
● Security Testing.
Acest tip de testare este unul foarte important deoarece evaleaza pragul de siguranta sau
eventual ele vulnerabilitati ale aplicatiei care pot duce la spargerea sistemului de catre o persoana
neautorizata.
Scopul acestui tip de testare este de a gasi si masura potentialele vulnerabilitati pentru a
pute fi fixate de catre developeri.
Fiind un tip de te stare foarte complex care implica multe portiuni de verificat, acesta
implica mai multe sub -tipuri de testare.
Un prim sub tip este ‘Vulnerability scanning’. In aceasta etapa codul sursa este scanat
automat printr -un program special care descopera unele v ulerabilitati.
Un a doilea sub tip de testare este ‘Security scanning’. Acest sub tip de testare implica
identificarea deficientelor atat de retea cat si de sistem. Scanarea poate fi facuta atat manual cat
si automat.
Un al treilea sub tip de testare es te ‘Penetration testing’. Acest sub -tip de testare, practic
se simuleaza un atac al unui hecker. Se analizeaza vulnerabilitatile sistemului afalt sub test in
timpul unei incercari de atac asupra sistemului(hacking).
Un al patrulea sub -tip de testare este ‘Risk Assessment ’. Acest sub tip de testare implica
analiza riscurilor de securitate observate în cadrul organizației. Riscurile sunt clasificate ca
‘scăzut’,’ Mediu’ și ’Înalt’. In urma acestui tip de testare se recomanda controale și măsuri
pentru reduce rea riscului.
Un al patrulea sub tip de testare este ‘Security auditing’. Acest sub tip de testare implica
o inspectie interna a codului si a sistemelor de operare pentru detectarea erorilor de securitate.
Acest tip de audit se poate face si inspectand c odul linie cu linie.
Un al cincilea sub tip de testare este ‘Ethical hacking’. Acest sub tip implica incearcarea
‘etica’ de a sparge si a frauda un sistem doar pentru a ii expune slabiciunile si lacunele de
securitate.

Un al saselea tip de testare este ‘Posture assement’. Acest tip de testare intruneste
‘Security scanning’, ‘Ethical hacking’ si ‘Risk assessments’ pentru a arata un raport complex
prind securitatea unui sistem.
● Compatibility Testing
Acest tip de testare verifica este facuta pentru a verifi ca compatibilitatea sistemului cu
varietatea de conditii exterioare necesare functionarii optime cum ar fi sistemul de operare,
platforma hardware, motoarele de cautare web sau tipul de retea folosit. Acest tip de testare este
folosit pentru a determina ca t de bine functioneaza sistemul aflat sub test intr -un mediu particular
de functionare ce include anumita platforma, o anumita conexiune la internet sau alte soft -uri.
● Usability Testing
Acest tip de testare este facuta pentru a determina cat de confortabil se simte un utilizator
cu folosirea aplicatiei in acord cu diferiti parametrii (continut, viteza de reactie, fluxul de actiuni
necesare penttru a face ceva), sau in special comparand doua aplicatii similare.
In acest tip de testare se urmaresc cinci compo nente relevante pentru experienta unui
utilizator.
Prima componenta ar fi simplitatea aplicatiei si usurinta cu care ea se poate invata in
scurt timp pentru a putea fi indeplinite sarcinile de baza in aplicatie, atunci cand utilizatorul are
contact cu ea p entru prima data. Este normal ca daca o aplicatie normala, cum ar fi spre exemplu
aplicatia unei firme de taximetrie, are o interfata prea complexa si actiunile de baza nu pot fi
intuite rapid, utilizator cel mai probabil va renunta la ea.
A doua component a a acestui tip de testare este eficienta. In acest pas se urmareste cat de
repede un utilizator isi indeplinetste sarcinile necesare in aplicatie.
A treia componenta urmarita in acest tip de testare este felul in care aplicatia este
memorata. Daca un uiti lizator nu foloseste o perioada de timp aplicatia, este important de sesizat
daca acesta o va putea folosi eficient urmatoarea data cand va reveni sau va trebui sa inceapa sa
invete de la inceput modul ei de utilizare.
A patra componenta importanta de stud iat in cadrul acestui tip de testare este modul in
care sistemul face fata erorilor de utilizare, cat de repede isi revine dupa acestea sau cat pot fi de
severe. Din partea unui utilizator care nu cunoaste aplicatia se asteapta diferite erori de utilizare,
diferite combinatii de intrari invalide sau actiuni neasteptate.
Nu in ultimul rand, in cadrul acestui tip de testare se urmareste satisfactia utilizatorului
cand foloseste aplicatia.
Prin rularea acestui tip de testare obtinem o serie indubitabila de avantaje.
Un prim avantaj este acela ca, testarea de tip ‘Usability’ poate fi facuta astfel incat sa
acopere multe alte tipuri de testare, cum ar fi testarea funcțională, testarea integrării
sistemului,unit testing, smoke testing etc.
Un al doilea avantaj este ca a cest tip de testare poate fi foarte economică dacă este
planificată corespunzător si este este foarte eficientă și benefică. Dacă se utilizează resurse
adecvate (testeri experimentați și creativi), ‘Usability testing’ poate ajuta la rezolvarea tuturor
problemelor cu care se poate confrunta utilizatorul chiar înainte ca sistemul să fie pus in
productie. Acest lucru nu face altceva decat sa duca la o performanță mai bună și la un sistem
conform standardelor in vigoare.
● Maintainability Testing
In cadrul acestu i tip de testare se verifica cat de usor poate fi mentinut un sistem, adica
cat de usor se poate corecta, modifica, adauga functionalitati suplimentare sau actualiza fara a
aparea erori.

● Scalability Testing
Testeaza abilitatea sistemului de a continua sa functioneze optim in cazul in care este
facuta o schimbare in marime sau in volum pentru a putea indeplini o cerere in continua crestere.
Se testeaza capacitatea de extindere a capacitatii de functionare in cazul unor cresteri de
tranzactii, volum de date etc.
Spre exemplu, un magazin online poate suporta 1000 de utilizatori simultan pe platforma.
Insa, in timpul perioadelor de reduceri, cu siguranta numarul utilizatorilor va depasi numar optim
suportat, ceea ce inseamna ce testarea in acest caz este foa rte importanta pentru a vedea
comportamentul si capacitatea de a suporta volum mai mare de date si utilizatori.
Depinzand de tipul aplicatiei care este testata, diferiti parametrii vor fi testati cum ar fi utilizarea
retelei sau a datelor mobile, utilizare a CPU sau experienta utilizatorului in aplicatie.
● Volume Testing
Este un tip de testare non -functionala facuta cu volume mari de date ca parte a
‘Performance testing’. Se testeaza aplicatia in cazuri in care exista volume mari de date de
intrare, volume m ari de inregistrari de date, in cazul unei marimi mari a unei tabele de baze de
date.
Scopurile principale ale testelor de volum sunt: verificare modului in care se face
incarcarea sistemului la un volum mai mare de date si determinarea punctului in care stabilitatea
incepe sa se degradeze, verificarea timpului de raspuns, verificarea ca datele sa nu fie supra
scrise fara notificari aferente, verificarea daca datele sunt stocate corect.
● Disaster Recovery Testing
Acest tip de testare ajuta la asigurarea f aptului ca, in cazul unui dezastru o organizatie isi
poate recupera datele, restabili aplicatiile critice si continua operatiunile. Daca nu se investeste
timp si resurse in crearea unui plan eleborat de recuperare a datelor in caz de dezastru si testarea
acestuia relativ regulat exista o sansa ca acesta sa esueze atunci cand este cu adevarat nevoie de
el.
Incercările de recuperare în caz de dezastre ar trebui să fie efectuate în mod regulat pe tot
parcursul anului. De asemenea ar trebui să fie încorporate în planul de intretinere iar personalul
ar trebui sa fie pregatit in acest sens. Odată ce un test de acest fel a fost finalizat, trebui analizate
jurnalele de audit și restul datelor pentru a determina daca totul a functionat asa cum era de
asteptat, pentr u a se determina ceea ce nu a functionat cum era de asteptat si care au fost cauzele
care au determinat acest lucru si nu in ultimul rand, ce modificări trebuie făcute în plan pentru a
fi imbunatatit.
● Compliance Testing
In esenta, acest tip de testatre es te un audit care se face pe sisteul aflat sub test pentru a
verifica daca standardele impuse sunt indeplinite. Pentru a se asigura de acest lucru, unele
comapanii înființează un consiliu de autorități de reglementare și experți în materie de
conformitate. Acest consiliu verifică si analizeaza daca echipele de dezvoltare respecta, aplica si
implementeaza corespunzator standardele impuse. De asemenea, comitetul de reglementare
lucrează simultan pentru a îmbunătăți standardele, ceea ce va conduce, la rândul să u, la o mai
bună calitate.
Acest tip de testare este cunoscut de asemenea si sub numele de ‘Conformance testing’
(teste de conformitate). Standardele utilizate în mod obișnuit de industria IT sunt în mare parte
definite de marile organizații precum IEEE ( Institutul Internațional de Inginerie Electrică și
Electronică) sau de W3C (World Wide Web Consortium) etc. Acest tip de testare poate fi
realizată si de o companie independentă, specializată în acest tip de testare.

Ca lucruri estentiale care trebuie ver ificate in cadrul acestui tip de testare sunt: domeniul
de aplicare al specificatiilor, apelul sistemului care urmeaza sa fie implementat, specificarea
obiectivelor si standardele prin care are loc implementarea.
Avatantajele rularii testelor de conformi tate sunt multiple, dar putem enumera
urmatoarele ca fiind cele principale : certitudinea ca specificatiile au fost implementatea corect,
asigură portabilitatea și interoperabilitatea, certitudinea ca exista utilizarea adecvată a
standardelor, certitudine a că interfețele și funcționalitatile funcționează conform așteptărilor,
ajuta la identificarea zonelor in care trebuie facute imbunatatiri.
Pentru construirea unei aplicatii utile si eficiente standardele, specificatiile si cerintele ar
trebui specificat e cla si concis pentru a evita ambiguitatile. Doar cu specificatii clare si concise
testarea de conformitatea poate fi una relevanta.
● Portability Testing
‘Portability testing’ se refera la procesul in care este testata usurinta cu care un produs
software se poate muta dintr -un mediu de functionare in altul si masurarea efortului depus.. Ca si
exemple relevante ar fi: muatarea unei aplicatii din Windows 7 mediu in care functioneaza
conform asteptarilor in Windows 8, mutarea din Android 5 in Android 8 etc.
Deoarece majoritatea aplicatiilor au fost dezvoltate astfel incat sa poate fi functionale pe
cat mai multe platforme, motoare de cautare sau sisteme de operare, procesul este unul complex.
Obicectivele acestui tip de testare sunt:
-determinarea daca sist emul poate fi portat pe mediile cerute: diferite dimensiuni de memorie
RAM sau diferite dimensiuni de spatiu ramas pe disc, rezolutie ecaran sau monitor, diferite
sisteme de operare, versiunea motorului de cautare.
-verificarea aspectului interfetei de uti lizator si comportamentul acesteia este similar in diverse
motoare de cautare sau la rezolutii diferite ale ecranului.
-verificarea daca produsul software are capacitatea de a coexista cu alte produse software
independente si de a imparti resursele existen te.
● Efficiency Testing
In cadrul acestui tip de testare se verifica resursele necesare unui produs pentru a
indeplini o anumita cerinta. În companiile de dezvoltare software, acest termen este utilizat
pentru a arăta efortul depus pentru a dezvolta aplicația și pentru a cuantifica satisfacția
utilizatorului.
Intr-o companie este importanta utilizarea eficienta a resuselor si transformare a cestora in
bunuri productive. Concentrarea este pe: resursele disponibile, instrumente, oameni, tipul de
proiect, buget, cerinta clientului, complexitatea etc. Astfel se masoara modul in care echipa face
munca necesara pentru a obtine rezultatele dorite.
Prin insusi definitia ei, eficienta este raportul dintre iesire si intrare exprimat in procente.
Fiind un parametru, aceasta nu poate avea valoarea mai mare de 100%. In cazul echipei de
tesatre eficienta se poate calcula ca si numarul de TC -uri executate intr-o unitate de timp, de
obicei aceasta unitate de timp fiind ora.
Eficienta este una dintre calitatile principale ale unuie echipe de testare. O planificare
riguroasa este secretul efectuarii tuturor activitatilor de testare intr -o maniera eficienta. Aici nu
este vorba doar despre executia TC -urilor ci si despre planificarea testelor, scrierea efectiva a
cazurilor de test, revizuirea, executia, urmarirea defectelor si cel mai important munca in echipa.
Alte formule de calculare a eficientei per total sunt :
[Test efficiency = (numarul total de defecte gasit in unit+integration+system) / (numarul total de
defecte gasit in unit+integration+system+User acceptance testing)

Testing Efficiency = (Numar total de defecte rezolvate /Numar total de defecte gasi te)* 100]
● Reliability Testing
Testarea de fiabilitate, dupa cum efectiv ii sugereaza numele, permite testarea
consecventei programului software. Testele de fiabilitate constau in exersarea aplicatiei astfel
incat esecurile sa fie descoperite si eliminate inainte ca sistemul sa fie pus in productie.
De asemenea, fiabilitatea se refera la coerenta rezultatelor obtinute la iesire in cazul
aplicarii repetate a aceleasi intrari. Acest tip de testare este recomandat sa se faca la mai multe
dintre stadiile de d ezvoltare software.
● Baseline Testing
Baseline testing se refera la validarea documentatie si specificatiilor pe baza carora sunt
scrise cazurile de test. In cadrul testarii software, se evalueaza performanta aplicatiei. Practic,
acest lucru se refera la u n punct de referinta care este baza oricarei noi creatii.
Acest tip de testare confera o baza pentru celelalte tipuri care vor urma, pentru a putea
compara performanta noii aplicatii cu un standard de referinta. In primul rand se va crea
documentul, pe b aza caruia se vor face testele urmatoare. Se masoara caracteristicile si cerintele
importante, astfel putandu -se analiza performanta relativa a unei aplicatii. Daca aplicatia prezinta
caracteristici de performanta sub linia pre stabilita, atunci aceasta es te considerata eronata. Cu
fiecare prototip nou al aplicatiei, aceste tip de teste ere rulat din nou, toate caracteristicile
importante fiind comparate pentru a ajuta la descoperirea si rezolvarea erorilor. Baseline testing
nu poate fi legat de o anumită f uncție deoarece se concentrează pe caracteristicile de calitate ale
aplicației.
Ca si un exemplu concludent pentru acest tip de testare si importanta ei, poate fii o
aplicatie care ofera o performanta buna pentru cel putin 2000 de utilizatori, la un meomen t dat.
Atunci, linia de baza va fi considerata 2000. Oricare nou prototip al aplicatiei va trebui sa
functioneze perfect la 2000 de utilizatori, in caz contrar va fi respins.
De asemenea, trebuie sa luam in considerare actualizarile de software. Cu fiec are
actualizare, o aplicatie va avea caracteristicile vechi, plus cele noi. Rularea testelor de tip
baseline asigură că principalele caracteristici și repere ale aplicației funcționează conform
așteptărilor.
● Endurance Testing
Endurance testing, este un ti p de testare non -functionala facuta pentru a determina
anduranta sistemului.
Acest tip de testare se refera la testele efectuate in mod tipic, cu un volum de date mai
mare si extitns pe o perioada mai lunga de timp, pentru a observa comportamentul sistem ului. In
urma rularii acestor tipuri de teste si a monitorizarii sistemului se pot gasi erori care in mod
normal nu ar aparea sau ar fi ratate, cum ar fi : lacune in memorie care pot avea ca rezultat
caderea aplicatiei, blocarea aplicatiei, erori la inchid erea bazelor de date, degradarea trepatata a
timpului de raspuns al aplicatiei, deoarece eficienta scade ca rezultat al testului prelungit. Spre
exemplu, un sistem se poate comporta conform asteptarilor cand este testat timp de o ora, dar
cand este testat acelasi sostem timp de 4 ore, pot aparea probleme enumerate anterior.
Scopul acestui tip de testare este de a descoperi modul în care sistemul se comportă in
cazul unei utilizari indelungate. Este important ca timpii de producție și de răspuns după o
perioadă lungă de activitate susținută sa fie la fel de buni ca la inceputu l testului.
Un dezavantaj al acestui tip de testare este acela ca este un consumator foarte mare de
timp. Dorindu -se verificarea performantei in timpul unei utilizari prelungite, durata de timp al
unei test trebuie stabilita pe baza unor factori cum ar f i utilizarea reala a sistemului, implicarea

clientului etc. Un astfel de test poate dura mai bine de 12 ore si de cele mai multe ori este
automatizat cu ajutorul unor programe speciale (LoadStorm, LoadRunner, Appvance, OpenSTA,
Rational Performance Tester, LoadUI)
● Documentation Testing
Implica documentarea artefactelor care ar trebui scrise inainte de inceperea sau in timpul
procesului de testare. Documentatia necesara procesului de testare ajuta la estimarea efortului si
timpului necesar. De asemenea ajut a la asigurarea ca toate functionalitatile din aplicatie sunt
acoperite si ca cerintele sunt urmarite. Din aceste documente fac parte: TC – urile, planurile de
test, documentele cu cerintele clientului si matricea de trasabilitate)
Este un lucru extrem d e important ca documentatia sa fie scrisa corect, concis, fara a lasa
loc de interpretare. Documentația poate fi testată moduri diferite, cum ar fi rularea documentelor
printr -un dispozitiv de verificare a ortografiei și gramaticii sau revizuita manual pentru a elimina
orice ambiguitate sau inconsecvență.
Testarea si revizuirea documentelor poa te începe chiar la începutul procesului de
dezvoltare si prin urmare se pot economisi sume mari de bani, deoarece cu cat mai repede este
gasita o eroare, cu atat costul de fixare va fi mai mic. Daca documentatia este incerta, inexistenta
sau gresita, toat e acestea se vor reflecta in calitatea finala a produsului.
● Recovery Testing
In cadrul testarii de recuperare, se produc esecuri fortate pentru a putea studia eficacitatea
procesului de testare. Spre exemplu, in cazul unei aplicatii mobile, daca se dorest e descarcarea
unui fisier utilizand datele mobile/WI -FI-ul, dar la un moment dat conexiunea este intrerupta,
descarcarea ar trebui sa fie pusa pe pauza. La reluarea conexiunii procesul de descarcare ar trebui
sa continue.
● Internationalization Testing
Internationalizarea este procesul de dezvoltare al unui produs sau aplicatie care sa
permita procesul de localizare. Testarea din timpul procesului de internationalizare se focuseaza
pe testarea de comaptibilitate, instalare, functionala etc. Codul aplicatie i este independent de
limba.
● Localization Testing
In zilele noastre este un lucru foarte comun sa gasim diferite site -uri web sa aplicatii care
pot fi traduse in numeroase limbi. Procesul de adaptare a unui produs la o alta limba si regiune se
numeste ‘loc alizare’. Este important ca un produs sa fie adaptabil la alte limbi, culturi sau
regiuni.
In cadrul testelor de localizare, multe elemente din interfata utilizatorului vor fi
schimbate, cum ar fi : formatul datei si orei, scheme de culori sau simboluri, m oneda utilizata,
limba, formatul tastaurii, unele cerinte legale, sortarea, aliniera si compararea datelor, texte sau
grafice care intr -o anumite cultura pot fi deranjante. Echipa de testare are ca focus principal
pentru testare in acest caz interfata de u tilizator si toatepartile din aplicatie in care procesul de
localizare a facut schimbari (casute de dialog, mesaje de eroare, tutoriale, ghiduri etc.)

● Instalation testing
Majoritatea produselor software au nevoie de instalare pentru a functiona si proced uri
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 ada uga diferite fisiere pe drive si poate face

anumite schimbari in sistemul de operare sau poate avea acces la anumite date (locatie, camera,
microfon etc.)

3. Implementare

3.1 Tehnologii utilizate pentru testarea automata a aplicatiilor.

Testele automate sunt scrise in Java. Java este un limbaj de programare orientat pe
obiecte lansat initial de Sun Microsystem in anul 1995. Este unul din cele mai populare limbaje
de programare deoarece este rapid, sigur si fiabil. In acest limbaj se dezvolta cele mai multe
tipuri de produse software.
Pentru procesul de testare este nevoie de instalarea si configurarea mai multor programe,
care vor ajuta acest proces, in cazul de fata programel sunt: Selenium WebDriver, Intelij si Java
JDK.
Selenium WebDriver este o colectie de API -uri open -source care sunt utilizate pentru
automatizarea testarii web. Suita Selenium mai cuprinde si Selenium IDE, Selenium Client API,
Selenium Remote Control și Selenium Grid. Cu ajutorul acestui program automatizarea se poate
face pe mai multe motoare de cautare, cum ar fi Chrome, Safari, Internet Explorer sau Firefox.
Utilizand Selenium WebDriver se pot automatizat mai multe tipuri de aplicatii, insa nu si cele
bazate pe ferestre. Pentru scrierea scripturilor de testare suporta mai multe limbaje de programare
cum ar fi C #, Java, Perl, PHP sau Ruby.
Un mare avantaj al SeleniumWebDriver este acela ca este independent de platforma,
adica aceleasi scripturi pot fi rulate si in Windows, Apple Os si Linux.
Pentru scrierea testelor automate elementele trebuie cautate in pagina, prin diferite
strategii de localizare cum ar fi CSS, Xpath, Id, nume sau link.
Intelij o aplicatie de tip desktop si este un mediu de dezvoltare Java. Aceasta platforma
expune multe API -uri care simplifică cr earea de instrumente diferite (IDE) în partea superioară a
platformei. Aceste API oferă funcționalități comune, cum ar fi suportul pentru acțiuni, elemente
de meniu, finalizare cod, refactorizare, integrare sistem de control al versiunii, editor, inspecții
etc.
JUnit este un cadru (framework) conceput pentru scrierea si rularea testelor automate in
Java. Acest soft are o interfata grafica ceea ce aface usoara scrierea codului sursa. Permite

dezvoltatorului sa scrie suite de teste pentru a masura progresul s i pentru a vedea efectele
secundare. Testele pot fi executate continuu si se primesc rezultatele imediat.
JDK (Java Development Kit ) este o implementare a unei platforme Java sub forma unui
produs binar dedicat dezvoltatorilor software pe platformele Solaris, Linux, mac OS sau
Windows. JDK este un produs gratis.

3.2 Cazuri de test

Platforma pe care am ales sa implementez testele automate este https://www.hipmenu.ro/ .
Aceasta este o platforma a carei act ivitate consta in servicii de intermediere in cadrul carora,
platforma face legatura intre client si restaurantele partenere. Raza de activitate in care Hipmenu
are acoperire este in Bucuresti, Cluj -Napoca, Timisoara si Oradea. Alimentele se comanda
online , de oricare din restaurantele partenere, cu disponibilitate in functie de zona orasului in
care se doreste livrarea. Ca orice magazin de e -commerce, aplicatia dispune de cos de
cumparaturi pentru fiecare restaurant partener in parte, posibilitatea de a pl ati cu cardul in
momentul confirmarii comenzii, cu bani cash sau cu bonuri de masa. Dupa plasarea unei
comenzi un timp de livrare va fi estimat iar livrarea va fi facuta de catre restaurantele partenere,
de către Hipmenu sau prin terțe părți care presteaz ă servicii de livrare.
In cadrul oricarui proces de testare, cazurile de test sunt una dintre cele mai importante
parti. Acestea sunt folosite atat de echipa de testare, de dezvoltare cat si de management. In cazul
in care nu exista documentatie pentru ap licatie, cazurile de test vor fi folosite ca si documente de
referinta.Sunt importante deoarece in primul rand, clarifica modul in care ar trebui sa functioneze
un sistem si ce trebuie facut pentru a fi testat. Ajuta de asemenea la monitorizarea procesului de
testare, facandu -l mai organizat, deoarece cu ajutorul lor se poate monitoriza progresul facut, pas
cu pas.
Cu alte cuvinte, acestea sunt scenarii pe care un utilizator normal le -ar putea face si au
rolul de a ghida testerul prin functionalitatile apl icatiei 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.
4. 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 aces t 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
dimens iuni 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. Decri erea 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 test ului 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 mu lte 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.
Implementarea oricarui test automat se va face pe baza unui caz de test scris manual
manual. Pentru www.hi pemnu.ro am pregatit urmatoarele cauri de test pentru a fi automatizate:

ID Licenta -01 Preconditii Cont de
FaceBook Data
Scriere 21.05.2018
Nr. 1 Nume
Executant Blidar Adina Data
Executare
04.07.2018

Titlu Autentificare cu
FaceBook Nume
Creator Blidar Adina
Mediu
Test Google Chrome
Nr.
Pasi
Pasi

Rezultate asteptate
Status
Comentarii
1. Acceseaza:
https://www.hipmenu.ro/#ho
me Pagina de start ar trebui sa fie
afisata. Passed
2 Apasa “Intra in cont/creaza
cont” Casuta de dialog cu titlul
“Autentificare” ar trebui sa fie
afisata. Passed
3 Apasa butonul “Intra cu
facebook”. Fereastra de autentificare
FaceBook va fi afisata. Passed
4 Introd u datele valide ale
contului si apasa butonul
“Log in” Autentificarea va fi facuta cu
succes Passed

Tabel 3.1 Caz de test pentru autentificarea cu Facebook

Acest caz de test, descrie pas cu pas cum se realizeaza autentificarea cu FaceBook p e
site-ul www.hipemnu.ro si care sunt rezultatele asteptate, afrente fiecarui pas. Cand se executa
acest test, pe langa cursul initial al actiunii de la cap la coada, se testeaza functionalitatea si mia
multor buto ane.

ID Licenta -02 Preconditii Cont de
FaceBook Data
Scriere 21.05.2018
Nr. Test 2 Nume
Executant Blidar Adina Data
Executare
04.07.2018

Titlu Autentificare cu
FaceBook Nume
Creator Blidar Adina
Mediu
Test Google Chrome
Nr.
Pasi Pasi
Rezultate asteptate Status Comentarii
1. Acceseaza:
https://www.hipmenu.ro/#ho
me Pagina de start ar trebui sa fie
afisata. Passed
2 Apasa ‘Intra in cont/cre eaza
un cont’ Casuta de dialog cu titlul
“Autentificare” ar trebui sa fie
afisata. Passed
3 1.Introdu date valide in
campurile de email si parola.
(Ex:
testaddisonlee1@gmail.com
/Qwerty123!l)
2. Apasa butonul ‘Intra cu
hipemnu’ Autentificarea a fost facu ta cu
succes. Passed
4 Apasa butonul ‘Comanda
acum’ Ecranul ‘Ajuta sa gasim restaurante
in zona ta’ va fi afisat Passed

5 1.Introdu in campurile de
adresa: Oras ->Cluj Naapoca,
Strada -> Iugoslaviei, Nr –
>68.
2.Apasa butonul “Gaseste
restaurante” O pagina cu optiuni ale
restaurantelor dipsonibile va fi
afisata. Passed
6 In bara de cautare introdu
‘City Pizza’ Optiunea introdusa va fi returnata. Passed
7 Da click pe restaurant. Un panou cu optiuni(comanda
online/comanda in grup) si
informatii v a fi afisat. Passed
8 Apasa butonul ‘Comanda
Online’. Pagina aferenta restaurantului va fi
afisata. Passed
9 In antetul cu optiuni apasa
“Pizza” Meniul ‘Pizza’ va fi afisat. Passed
10 Da click pe unul din
produsele din sectiune. Un panou cu numele produsului,
ingrediente si butonul ‘Adauga’ va
fi afisat. Passed
11 Apasa butonul ‘Adauga’. Un panou cu titlul ‘Topping’ si cu
optiuni cu casete de bifat va fi
afisqat Passed
12 1.Bifeaza cateva optiuni.
2. Apasa butonul “Urmator”. Un panou cu titlul ‘Sosuri extra’ si
cu optiuni cu casete de bifat va fi
afisat Paseed
13 1.Bifeaza cateva optiuni.
2. Apasa butonul “Urmator”. Un panou cu un camp de
‘Instructiuni speciale’ va fi afisat. Passed
14 1.Scrie ceva in campul de
intructiuni speciale.
2.Apas a butonul ‘Adauga in
cos’. Utlizatorul va fi redirectionat pe
pagina pe care era anterior (De la
pasul 9) Passed
15 Apasa pe butonul ‘Cos’. Pagina ‘Cosul meu’ va trebui sa fie
afisata. Passed

16 Analizeaza pagina ‘Cosul
meu’ Comanda trebuie sa fie salv ata,
impreuna cu optiunile suplimentare
adaugate si instructiunile speciale. Passed
Tabel 3.2 Caz de test pentru cosul de cumparaturi

Desi este doar un caz de test, acesta este unu complex. Executand un singur test, se
verifica functionalitatea de aut entificare, functionalitatea de gasire a restaurantele din apropiere,
functionalitatea barii de cautare, acuratetea rezultatului returnat, functionalitatea butoanelor si
procesul efectiv de adaugare a unui produs in cos si faptul ca optiunile suplimentare au fost
salvate si pretul a fost calculat in functie de ele.

ID Licenta -01 Preconditii Cont de
FaceBook Data
Scriere 21.05.2018
Nr. 3 Nume
Executant Blidar Adina Data
Executare
04.07.2018

Titlu Autentificare cu
FaceBook Nume
Creator Blidar Adina
Mediu
Test Google Chrome
Nr.
Pasi
Pasi

Rezultate asteptate
Status
Comentarii
1. Acceseaza:
https://www.hipmenu.ro/#ho
me Pagina de start ar trebui sa fie
afisata. Passed
2 Apasa “Intra in cont/creaza
cont” Casuta de dialog cu titlul
“Autentificare” ar trebui sa fie
afisata. Passed
3 1.Introdu date valide in
campurile de email si parola.
(Ex:
testaddisonlee1@gmail.com
/Qwerty123!l)
2. Apasa butonul ‘Intra cu Autentificarea a fost facuta cu
succes. Passed

Hipe mnu’
4 Apasa pe numele contului
(stanga sus). O caseta cu optiuni se va expanda
(Istoric comenzi/Setari/Iesire din
cont) Passed
5 Da click pe optiunea ‘Setari’ Ecranul ‘Setari’ va fi afisat, Passed
6 Editeaza cateva informatii
din sectiunea ‘Informatii
cont’ (Ex: numele si
prenumele) si apasa ‘OK’ Informatiile trebuie sa fie salvate si
sa poata fi vizualizate. Passed
7 Adauga o adresa de livrare
noua si salveaza actiunea. Informatiile ar trebui s a fie salvate
si sa poata fi vizualizate. Passed
Tabel 3.3 Caz de test pentru editarea datelor
Cand testul din tabelul X, va fi rulat automat sau manual, vor fi verificate, pe langa
functionalitatea de autentificare si setarile contului, capac itatea de a fi salvate modificarile si
functionalitatea de adaugare adresa de livrare noua.

3.3 Implementarea testelor automate

Un prim pas, dupa instalarea programelor enumerate in subcapitolul anterior si crearea
unui nou proiect, este importarea pa chetelor, inainte de scrierea efectiva a codului.
import org.openqa.selenium.By;
Referinta la clasa By de unde este apelat un tip de locator.
import org.openqa.selenium.WebDriver;
Referinta la interfata WebDriver Pachet necesara pentru a instantierea unu i nou browser de catre
clasa WebDriver.
import org.openqa.selenium.WebElement;
Referinta la clasa WebElement care este necesara pentru a putea instantia un nou element web.
import org.openqa.selenium.chrome.ChromeDriver;
Referinta la clasa Chrome driver, n ecesara pentru instantierea unei pagini specifice a motorului
de cautare Google Chrome.
import java.util.Iterator;
import java.util.Set;
import org.openqa.selenium.JavascriptExecutor;
Indica faptul ca un driver poate executa Java Scrip, oferind acces la m ecanism pentru a putea
face acest lucru.

In a doua faza, pentru implementarea unui test automat pe o pagina WEB, trebuie
identificate elementele in structura paginii. Pentru aceasta actiuni, se da click dreapta pe
elementul pe care dorim sa il identifica m si se va alege optiunea “Inspecteaza”.

Figura 3.1 Cautarea unui element in structura paginii web.

In functie de elemente, am folosit diferite metode de identificare, dupa cum urmeaza:
driver.findElement(By. xpath("/html/body/nav/div/a[2]" ) ;
Acest e ste un element care a fost identificat cu Xpath. XPath este un limbaj care folosește
expresii de cale pentru a selecta noduri sau seturi de noduri. Aceste expresii ale căii efective pe
care se poate gasi elementul.
Exemplu de element in pagina, care necesi ta identificare cu XPATH

Figura 3.2 Element care necesita identificare cu XPATH

driver.findElement(By. id("AcceptAllID" );
Acesta este un element identificat cu ajutorul id -ului. Cu aceasta strategie, primul
element cu valoarea atributului respectiv va fi returnat. In cazul in care id -ul nu exista, va fi
returnata valoarea “NoSuchElementException”.
Exmplu de element in pagina care necesita identificare dupa ID:

Figura 3.3 Element care necesita identificare pe baza de ID

driver.findElement(By. cssSelector (".searchbox -submit-button"));
Acesta este un element identificat cu ajutorul sintaxei CSS selector. Exemplu de element
idenitificat cu ajutorul CSS Selector:

Figura 3.4 Element care necesita identificare cu CSS selector

driver.findEleme nt(By.className( "search-input"));
Acesta este un element identificat cu ajutorul clasei. Se selecteaza elementul cu un
anumit atribut de clasa. Exemplu de element care necesita identificare dupa clasa:

Figura 3.5 Element care necesita identificare pe baza de clasa

driver.findElement(By.name( "admin");
Acesta este un element identificat cu ajutorul numelui. Fiecare formular ar trebui sa aiba
campuri cu nume unice, desi acest lucru nu este o restrictie. Poate sa fie util spre exemplu in
identificarea elementelor de pe o pagina de autentificare. Insa, in cazul in care pe pagina exista
spre exemplu, mai multe butoane cu acelasi nume, va trebui incearcata alta metoda.
Exemplu de element care poate fi identificat pe baza numelui:

Figura 3.6 Element care se poate identifica dupa nume

driver.findElement(By.linkText( "How to use locators?" );
Acest tip de cautare a elementului in pagina va functiona doar pentru etichetele de
ancorare. Este recomandat de utilzat pentru folosirea fluxurilor de navigatie.
Dupa importarea pachetelor, am declara in prima faza o clasa principala EditProfile
:“public class EditProfile”.
In interiorul acestei clase am mai declar o clasa main “public void main() throws
InterruptedException { }”. “Public” inseamna ca metoda est e visbila si poate fi apelata. “Void”
inseamna ca metoda nu are valoare de returnare. “ throws InterruptedException”, inseamna ca
utilizeaza exceptii pentru a notifica lucrurile care nu trebuie ignorate.
In continuare trebuie sa se hotarasca care va fi mo torul/motoarele de cautare pe care vor
fi executate testele. In acest caz, testele au fost automatizate pe Google Chrome. Proprietatile
sistemului si pagina care va fi lansata se stabilesc prin metode, astfel:
System.setProperty ("webdriver.chrome.driver" ,"C:\\chromedriver_w
in32\\chromedriver.exe" );

WebDriver driver = new ChromeDriver();
driver.get( "https://www.hipmenu.ro/ ");
Pentru maximizarea unei pagini a motorului de cautare se foloseste metoda:
driver.manage( ).window().maximize();
In continuare, trebuie folosite metode pentru a interactiuni cu elementele cum ar fi,
click, scrierea textului in interiorul unui camp, derularea paginii etc.
Spre exemplu, un element va fi declarat si se va face click pe el, in ur matorul mod:
WebElement AllowCoockies =
driver.findElement(By. id("AcceptAllID" ));
AllowCoockies.click();
Pentru declarea, identificarea si scrierea in interiorul unui camp am folosit:
WebElement emailfield = driver.findElement(By. id("loginCtrl –
username" ));
emailfield.sendKeys( "testaddisonlee1@gmail.com ");
Un element se poate gasi in pagina cu metoda ‘find’, insa se va putea interactiona cu el,
doar daca va fi in raza vizuala. Pentru a putea fi derulata p agina, astfel incat elementul sa fie
vizibil, am folosit:
WebElement elementy = driver.findElement(By. id("h-cart-
titleId" ));
((JavascriptExecutor)
driver).executeScript( "arguments[0].scrollIntoView();" ,
elementy);
O alta problema care poate fi intampinata este manevrarea a doua pagini WEB. Spre
exemplu o autentificare cu un cont de social media, duce la declansarea a unei pagini web
secundare, in care se introduc parola si emailul. Pentru aceasta situatie, am folosit:
while(itr.hasNext()){
String childW indow=itr.next();
if(!mainWindow.equals(childWindow)){
driver.switchTo().window(childWindow);
System.out.println(driver.switchTo().window(childWindow).getTitl
e());
WebElement Email1 =
driver.findElement(By. id("email"));
Email1.send Keys("adinablidar1@gmail.com" );

WebElement Password1 =
driver.findElement(By. id("pass"));
Password1.sendKeys( "Qwerty123!" );

WebElement SocialLogin2 =
driver.findElement(By. id("loginbutton" ));
SocialLogin2.click();
driver.close();
driver.switchTo().window(mainWindow);
}
}

Pentru identificarea unui camp, stergerea textului initial din el si inlocuirea acestuia cu un
alt text am folosit:
WebElement editname = driver.findElement(By. id("h-acc-inftx-
first-name-text-input"));
editname.clear();
editname.sendKeys( "Este un test!" );

Acest cod, muta actiunea de la pagina parinte, la a doua pagina Web declansa de apasarea
unui buton, cauta campurile corespondente parolei si emailului, apasa butonul de autentificare,
inchid e pagina secundara si schimba actiunea inapoi la pagina parinte.
Dupa finalizarea scrierii codului sursa pentru un test, l -am rulat in Intelij. Una dintre
functionalitatile importante ale acestui program este furnizarea statusului imediat al testului dupa
rularea acestuia.
Daca testul va fi trecut, rezultatul va aparea dupa cum urmeaza:

Figura 3.7 Status ‘Passed’ in Intelij

Daca testul va fi picat, rezultatul va aparea dupa cum urmeaza:

Figura 3.8 Status ‘Failed’ in Intelij

In cazul unui test p icat, InteliJ returneaza si cauzele pentru care testul nu a trecut.

4. Rezultate experimentale

4.1 Bug -ul. Ciclul de viata al unui bug.

In urma rularii unei suite de teste, atat manual cat si automat exista o mare probabilitate
sa fie gasite bug -uri in aplicatie. InteliJ genereaza automat si un raport cu cu numarul de teste
picate si cele trecute.

Figura 4.1 Raport erori

Dupa picarea unui test trebuie investigat motivul si daca este cazul, trebuie raportat un
bug. In companii , se folosesc sisteme de monitorizare si urmarire ale bug -urior (Ex: Jira)

Un bug este o eroare/problema/defectiune care cauzeaza iesiri invalide, o abatere de la
rezultatele asteptate sau prabusiri ale programului. Bug -urile apar din cauza greselilor din codul
sursa ale programului sau datorita lacunelor rezultate din cerinte emise la implementare.
Echipa de testare are ca scop principal gasirea tuturor bug -uri si erorilor din aplicatie. O
data gasit, un bug trece printr -o serie de etape, care se pot numi generic ‘ciclu de viata’.

Figura 4.2 Ciclul de viata al unui bug

1. Nou (New) – este prima etapa, cand un bug tocmai a fost gasit si a fost postat pentru prima
data intr -un program de urmarire a bug -urilor. (ex.: Jira)
2. Alocat (Asigned) – in cea de -a doua etapa bug -ul este alocat unei persoane din echipa de
dezvoltare care va trebui sa se ocupe de rezolvarea acestuia.
3. Deschis (open) – in aceasta etapa, membrul echipei de dezvoltare caruia i -a fost alocat bug -ul
respectiv a inceput sa analizeze s i sa lucreze la problema.
4. Fixat (Fixed) – dupe ce developerul a facut schimbarile necesare in cod pentru rezolvarea
problemei, el va trece acest status bug -ului, iar acesta va fi alocat automat echipei de testare.
5. In asteptare pentru retestare (Pendi ng retest) – in acest pas, se asteapta ca cineva din echipa de
testare sa preia bug -ul.
6. Retestare (Retest) – dupa rezolvarea problemei de catre developer, echipa de testare va trebui sa
verifice daca intr -adevar bug -ul se mai reproduce sau nu.
7. Veri ficat (Verified) – In cazul in care problema nu se mai reproduce, bug -ului i se va trece
statusul de ‘Verified’.
8. Inchis (Closed) – statusul primit dupa ce un bug este rezolvat, testat si aprobat.
9. Duplicat (Duplicated) – in cazul in care un bug se rep eta de doua ori, sau exista doua similare
care au acelasi concept, va primi statusul de ‘Duplicate’
10. Respins (Rejected) – Daca se considera ca bug -ul nu este autentic va primi statusul de
‘Rejected’
11. Amanat (Deferred) – in cazul in care bug -ul nu est e unul prioritar care trebuie rezolvat in
viitorul apropiat i se va pune statusul de ‘Deferred’.

13.Nu este un bug (Not a bug) – in cazul in care ceea ce a fost raportat nu este un defect, se
atribuie acest status.

Figura 4.3 Raportarea unui bug

4.2 Costurile testarii software (Partea economica)

Dezvoltarea unui program software este adesea constransa de timp si buget. Esista adesea
tentatia ca activitatile de asigurare a calitatii sa fie percepute ca si consumatoare de timp si de
resurse financia re. Insa, experienta sugereaza ca investirea eforturilor in asigurarea calitatii
imbunatateste sansele de livrare.
Provocarea universala pentru proiectele de dezvoltare software este detectarea si
eliminarea rapid si ieftin si de asemenea inlaturarea risc urilor pe care acestea le au asupra
functionarii produsului, Costurile unui defect poat fi masurate prin impactul defectului respectiv
si momentul dar si momentul in care este gasit. Cu cat un defect sa gaseste mai devrem cu atat
costul repararii acestuia este mai mic. Spre exemplu, daca se gaseste o eroare in stadiul analizarii
specificatiilor si a cerintelor, repararea acesteia va fi iefina. La fel, daca eroarea se gaseste in
timpul etapei de revizuire a designului, va pute fi corectata usor. Insa, in caz ul in care eroarea nu
este cuprinsa in specificatii si nu este gasita pana in cadrul UAT sau doar in productie, costurile
fixarii problemei vor fi mult mai mari. Acest lucru se datoreaza faptului ca vor fi necesare
reparatii in specificatii si design inain te ca schimbarile necesare sa fie facute in constructie,

deoarece un defect din cadrul cerintelor se poate propaga in mai multe locuri din design si cod.
De aseemenea toata testarea facuta pana in punctul in care defectul a fost gasit si reparat va
trebui sa fie refacuta, pentru a atinge nivelul dorit de incredere. Este destul de intalnit cazul in
care defectele sunt gasite intr -un stadiu avansat al dezvoltarii produsului si in functie de gravitate
sau modul in care afecteaza utilizator pot sa nu fie corect ate deoarece acest lucru de multe ori
costul este prea mare.

Figura 4.4 Cresterea costurilor unui bug in functie de faza de dezvoltare

Masurarea costurilor procesului de testare este un pas important deoarece toate
cheltuielile aferente sunt justific ate prin compararea beneficiilor acumulate cu costul in sine.
Inainte de a incepe procesul efectiv de testare, persoanele responsabile de efectuarea, planificarea
si managerierea procesului in sine trebuie sa stabileasca rezursele necesare pentru testare,
nivelurile necesare si costurile acestora.
O analiza atenta arata ca de obicei costurile reale de testare sunt de obicei intre 15% si
25% din costul total al proiectului, in cazul proiectelor mai complexe care necesita tehnici de
testare mai speciale aju ngand pana la 50% din costul unui proiect. Stabilirea costurilor de testare
a software -ului este un prim pas crucial pentru planificarea oricarei activiati, precum si costurile
reparatiilor si corectiilor care vor fi necesare in program.
Daca o organizat ie nu stabileste un proces de testare eficace sau nu pune accent pe
acesata parte, costurile testarii slab facute, ajung de obicei sa fie dublu fata de costurile directe
ale testarii.
Costul testarii software include atat costurile directe cat si cele in directe cauzate de
defectiuni si masurarea acestora.

Costurile directe ale testarii
(indispensabile) Costurile indirecte ale testarii
(datorate testarii slabe)
Revizuirea si analiza documentatiei Rescrierea programului
Testarea sistemului (System t esting) Actiuni corective

Testare de acceptare (Acceptance testing) Re-introducerea datelor
Planificarea procesului de tesatare Erori si proces slab de testare
Resurse de test Debugging (depanare)
Costul terminalelor, resurselor umane etc. Retestarea.
Tabel 4.1 Costurile directe si indirecte ale testarii

4.3 Costurile defectelor software (Partea economica)

Exista un impact economic al testarii software. Unul dintre impactele economice este
cauzat de costul defectelor. Al doilea impact economic est e cauzat de modul in care efectuam
testare propriuzisa. Poate fi posibil sa avem motivatie si instrumente de testare potrivite, dar
testarea sa fie facuta intr -un mod ineficient.
Pentru a putea intelege mai bine implicatiile si costurile unui defect treb uie sa intelegm
de unde provin acestea.

Figura 4.4 Provenienta defectelor

Exista un procentaj atat de mare de defecte provenit din neintelegerea cerintelor clientului
deoarece putini oameni au fost instruti sa inteleaga dinamica cerintelor, proiect ele si felul in care
doresc clientii sa arate produsul lor se schimba repede sau de foarte multe ori pot aparea greseli
de interpretare.
Dupa cum s -a observat in figura anterioara, cele mai multe defecte provin din
neconcordanta cerintelor cu implementar ea si din design. Insa, majoritatea efortului in ceea ce
priveste testarea se face de obicei la final, intr -o faza numita abordare de tip ‘Big bang’.
Problema abordarii de acest tip este ca defectele nu sunt gasite decat spre sfarsitul proiectului,
acesta find cel mai riscant si costisitor timp de reparare a defectelor, unele dintre ele putand fi
imposibil de rezolvat.

`
Figura 4.5 Utilizarea resurselor de test.

Unul dintre cele mai cunoscute lucruri despre defectele software este faptul ca, cu cat
sunt descoperite mai tarziu, cu atat va fi mai greu si mai costisitoare remedierea lor. Regula
generala este ‘1:10:100’. Acest lucru insemnand ca daca un defect costa o unitate(ora, euro, leu
etc.) sa il remediezi in stadiul de cerinte sau design, va cost a 10 unitati sa fie reparat in faza de
testare(testare de sistem/testare de acceptare) si 100 unitati pentru a remedia problema odata
ajunsa in productie. Acest cost nu ia in considerare si efectul pe care defectul si repararea lui l -a
avut asupra softului .

Figura 4.6 Costul relativ al remedierii defectelor

4.4 Analiza SWOT a testarii automate. (Partea economica)

Puncte tari:
-timpul necesar pentru testele de regresie este
considerabil redus.
-ofera masuratori mai precise comparat iv cu
observatiile umane deoarece un computer nu
va fi obosit sau distras.
-reproductibilitatea este mai mare, deoarece
computer va observa aceleasi evenimente intr –
o maniera identica.
-posibilitatea de a testa 24h pe zi, 7 zile pe
saptamana.
-lipsa riscu lui de a varia rezultatele finale
datorita interventiilor umane
-pe o perioada lunga de timp se economisesc
bani
-o data scrise testele automate pot fi refolosite Puncte slabe:
-instrumentele necesare pentru automatizare
pot fi scumpe.
-in prima faza este un proces care necesita
mult timp pentru pregatirea mediului de
testare si scrierea efectiva a testelor automate.
-instrumentele de testare automata au anumite
limitari. Nu poat fi testate automat elementele
de consideratie vizuala (cul ori, fonturi, etc.)
-nu se poate schimba cursul unui test in
mijlocul acestuia daca s -a observat ceva
defect ne luat in considerare anterior.
-este nevoie de competente bine dezvoltate in
domeniul programarii pentru a putea scrie
teste automate.
-de fiecar e data cand se face o schimbare in
aplicatie trebuie schimbate si scripturile de
test.
Oportunitati:
-colectarea datelor care ulterior pot facilita
dezvoltarea softului. Amenintari:
-incercarea de a inlocui definitiv implicarea
umana in procesul efectiv de testare.
-daca in scriptul de test exista erori
neobservate pot exista conseecinte grave.
Tabel 4.1 Analiza SWOT a testarii automate

4.5 Analiza SWOT a testarii manuale.

Puncte tari:
-costurile pe termen scurt sunt mici.
-in comparatie cu test are automata, in timpul
testarii manuale se permite ca programul sa
fie folosit si testat precum va fi folosit si in
productie.
-testarea manuala este flexibila
– Puncte slabe:
-unele sarcini sunt dificile de indeplinit
manual.
-testarea manuala poate dev eni repetitiva si
plictisitoare
-testele manuale o data facute, nu pot fi
refolosite.

Oportunitati:
-un tester se va comporta ca un user
proeficient si va putea da sugestii de
imbunatatire ale aplicatiei adaugand valoare
aplicatiei. Amenintari:
-load testing si testele de performanta nu sunt
eficiente daca sunt rulate manual.
-in cazul situatiilor de urgenta in care exista
constrangeri de timp nu vor putea fi rulate

corespunzator testele manuale
-nu se pot identifica manual riscurile existente
in aplic atie in ceea ce priveste se securitatea.
– erorile de observatie umana.
Tabel 4.2 Analiza SWOT a testarii manuale

Analiza SWOT este o metoda de indentificare si expunere a punctelori tari, punctelor
slabe, oportunitatilor si amenintarilor atat a t estarii manuale cat si a testarii automate.
Analiza presupune identificarea elementelor favorabile si nefavorabile a fiecarui tip de testare
pentru a putea fi hotarat, depinzand de caz daca se va apela la testare manuala sau la testare
automata. In functi e de natura proiectului, bugetul alocat, timpul disponibil si resursele umane
existente se va lua aceasta hotarare pentru ca testarea sa fie eficienta si costurile sa nu depaseasca
limita normalului,

4.7 Metode de optimizare si reducere a costurilor (Partea economica)

Pe masura ce din ce in ce mai multe organizatii fac trecerea spre modelul de manageriere
al proiectelor de tip Agile, descopera ca testarea nu este doar la sfarsit, ci pe tot parcursul ciclului
de viata al unui proiect. O intrebare fireasca este aceea ca daca testarea este pe tot parcursul
ciclui de viata si nu doar la sfarsit, nu va fi mai scumpa? Este o greseala sa se porneasca de la o
astfel de premisa, deoarece si rezolvarea defectelelor gasite la sfarsitul proiectului sau cele gasite
dupa ajungerea produsului in productie pot fi foarte costisitoare.
Mai jos o sa enumar o lista de solutii pentru a reduce costul testelor software si pentru a
face procesul mai concentrat, productiv si eficient.
1. Testarea in paralel cu dezvoltarea.
Rezul tatele ar trebui testate pe masura ce produsul este dezvoltat, pentru a reduce
defectele majore de la sfarsit, care pot fi mult mai costisitoare. Defectele nu sunt cauzate
intotdeauna de greseli in cod ci si de intelegerea eronata a cerintelor.
2. Inceper ea testelor de performanta si securitate devreme.
In ceea ce priveste performanta si securitatea, daca codul nu este bine structurat la
inceput, se pot observa realtiv usor problemele. La fel, o problema de acest gen gasita intr -un
stadiu inaintat la proie ctului poate fi costisitoare atat din punct de vedere al timpului cat si din
punct de vedere al resurselor financiare.
3. Determinarea zonelor stabile ale aplicatiei.
Un alt punct important este determinarea zonelor stabile si bine testate ale aplicatiei .
Astfel se poate minimza testarea anumitor zone care nu mai necesita atat de multa atentie. De
asemenea in acele zone se pot implementa testele automate, pentru ca testele de regresie rulate in
urma implementarii fiecarei caracteristici noi sa consume un minim de timp.
4. Analizarea codului testelor automat si a cazurilor de test.
Analizarea scripturilor de teste si a cazurilor de test este eficienta deoarece se
eficientizeaza procesul prin eliminarea testelor care nu mai sunt folositoare sau nu gasesc
defecte.
5. Exploratory testing.
Reducerea metodelor rigide de testare si inlocuirea lor cu mai multe teste de tip
exploratory duc la gasirea foarte rapida a problemelor mai mari si la economisirea timpului.

6. Testarea frecventa a zonelor instabilie.
Anumite zone ale aplicatiei tind sa fie predispuse la aparitia defectelor. Testarea acestora
in cicluri mici si frecvente ajuta la reducerea costurilor prin gasirea si rezolvarea rapida a
problemelor.
7. Reducerea rapoartelor a caror rezultate nu vor fi f olosite.
Pentru economisirea timpului echipei de testare se pot reduce planurile de test si
rapoartele pe baza rezultatelor carora nu urmeaza sa se intreprinda actiuni. Daca nu exista nici o
actiune rezultata rapoartele sunt atat inutile cat si consumatoar e de timp.
8. Utilizarea instrumentelor de manageriere a defectelor.
Utilizarea un triaj de defecte informal si rapid poate reduce timpul ciclului de gestionare a
defectelor (Ex.: Jira)
9. Regula 80/20
In cazul in care este posbil, se poate utiliza regul a 80/20. Principiul spune ca 80% din
probleme sunt cauzate de 20% din cod. Conceptul aici este principiul Paretto, descris initial de
catre Vilfredo Pareto si mai tarziu formalizat de catre Joseph Juran. Desigurm aceasta este doar o
regula, dar poate fi un a importanta.
Indiferent dac aprocentele sunt 90/10 70/30, in realitate cele mai multe problem sunt
cauzate de cativa factori care stau la baza. Cand un tester stie acest lucru, poate oferi o valoare
extraordinara echipei. Spre exemplu, daca un tester se uita la o lista cu 100 de defecte, initial
probabil nu va vedea o legatura. Daca acele defecte vor fi clasificate pe baza unor categorii, se
poate observa ca un numar foarte mare de bug -uri provine din foarte putine locuri.
Pentru ca aceasta regula sa fie eficienta, erorile ar trebui sortate dupa cauza, nu dupa
rezultat. De asemenea nu ar trebui sa grupam toate bug -urile care au facut aplicatia sa se
prabuseasca ci ar trebui sa grupam si sa indentificam modulele din care aceste probleme au
provenit. Cu toa te acestea erorile s -ar putea sa nu apara doar din cadrul programului, acestea pot
aparea si din cauza procedurilor gresite. Spre exemplu, 80% din probleme pot aparea din cauza
faptului ca dezvoltatorul uitilizaeza proceduri depasite.
Acest principiu poate fi extrem de pu ternic în reducerea numărului de bug -uri si automat
al costului si al timpului investit in acestea, deoarece rezolvarea a doar câteva lucruri poate face
un program mult mai stabil.
11. Incercarea de automatizare intr -un stadiu incipient al proiectului.
In loc sa automatizeze de la inceput, multe dintre echipe incep cu testarea manuala. Desi
pe termen scurt acest lucru are sens deoarece investitiile sunt mult mai mici, testarea manuala o
data cu expansiunea proiectului se poate transforma intr -o povara, in cazul in care nu este
mentinuta la minimul necesar. Cand un proiect este complex, automat si erorile umane sunt mai
predispuse sa apara. Stiind acest lucru, o regula de baza este de a cauta oricand ceva ce poate fi
autmatizat in timpul procesului initail d e testare manuala. Acest lucru va reduce automat costul si
timpul rularii viitoarelor teste de regresie.
12. Criteriile clare de intrare si iesire.
Stabilirea criteriilor de intrare si de iesire este importanta pentru eficientizarea costurilor
de testare deoarece neglijarea acestor criterii provoaca incertitudine, ceea ce poate duce ore
intregi ale echipei, pierdute, la omiterea unot bug -uri si de asemenea procedurile clar definite
sunt mai usor de automatizat.

Criterii de intrare Criterii de iesire

Prototipul a trecut toate testele de tip smoke. Toate testele disponibile au fost executate.
Datele necesare pentru teste sunt disponibile
(conturi, carduri etc.) Toate problemele care blocheaza functionarea
aplicatiei au fost rezolvate.
Toate testele d e tip unit, au trecut. 90% din problemele cu prioritate mare au fost
rezolvate.
Tabelul 4.3 Exemplu de corespondenta intre criterii de intrare si iesirre

https://pdfs.semanticscholar.org/f7f3/9a546ad957e9fec753f42479c298175d7db8.pdf

1- http://istqbexamcertification.com/what -is-efficiency -testing -in-software/
2- https://en.wikipedia.org/wiki/Waterfall_model (pasii metodologiei waterfall)
3.http://istqbexamcertification.com/what -is-waterfall -model -advantages -disadvantages -and-
when -to-use-it/
4. http://toolsqa.com/software -testing/waterfall -model/ – poza water fall
5.http://www.uniberasoft.com/our -process/agile/ – poza agile
6. https://www.tutorialspoint.com/scrum/scrum_arti facts.htm artifacte agile
7.https://gooroo.io/GoorooTHINK/Article/16833/Famous -Software –
Bugs/23477#.WyJPyUiFNnJ (bug wow/AT&T)
8. https://www.independent.co.uk/news/world/americas/chris -reynolds -briefly -becomes -worlds –
riche st-person -after-paypal -credits -him-with-92-quadrillion -8716484.html paypal bug
9. https://en.wikipedia.org/wiki/Mariner_1 (Mariner Rocket bug)
11. https://www.computerweekly.com/opinion/The -economics -of-software -testing partea
economica
12. https://www.riceconsulting.com/public_pdf/STBC -WM.pdf cifre pie chart/utilizare resurse
de test..
13. https://xbosoft.com/software -quality -blog/reduce -the-cost-of-software -testing/
Reducere costuri
13.https://www.utest.com/articles/principles -of-testing -the-8020 -rule 80/20 rule