Introducere … … … … … 5 [630393]

Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………….. … 5
Temă și conținut ………………………….. ………………………….. ………………………….. ………………….. 5
Motivarea te mei ………………………….. ………………………….. ………………………….. ………………….. 6
1 CAPITOLUL 1 – Conceptul de “Business Intelligence” (BI) ………………………….. …………. 7
1. Business Intelligence – descriere ………………………….. ………………………….. …………………. 7
1.1 Istoricul Business Intelligence ………………………….. ………………………….. …………………. 8
1.1.1 Inceputurile ………………………….. ………………………….. ………………………….. ………… 8
1.1.2 Dezvoltarea pana in 1950 ………………………….. ………………………….. …………………. 9
1.1.3 Evolutia pana la sfarsitul anilor 80’ ………………………….. ………………………….. ……. 9
1.1.4 Anii 1980 – 1990, moment important pentru revolutionarea Busines Intelligence
10
1.1.5 Anii 2000, Business Intelligence 1.0 ………………………….. ………………………….. … 10
1.1.6 Business Intelligence 2.0 ………………………….. ………………………….. ………………… 11
1.1.7 Busines Intelligence in zilele noastre ………………………….. ………………………….. .. 11
1.2 Business Intelligence – componente si implementare ………………………….. ……………. 12
1.2.1 Componenta analytics: ………………………….. ………………………….. …………………… 13
1.2.2 Componenta de Data Mining (extragerea datelor si informatiilor) ………………… 13
1.2.3 Componenta OAP (sau Olap – Online Analytical Processing) ……………………… 14
1.2.4 Componenta BPR ( Business process re -engineering) ………………………….. ……… 15
1.2.5 Componenta Benchmarking ………………………….. ………………………….. ……………. 15
1.2.6 Componenta Data Warehouse ………………………….. ………………………….. …………. 16
1.2.7 Componenta de reporting ………………………….. ………………………….. ……………….. 17
1.3 Cateva exemple de solutii de Busines Intelligence ………………………….. ………………… 17
1.3.1 IBM Watson Analytics ………………………….. ………………………….. …………………… 18

2
1.3.2 Microsoft Power BI ………………………….. ………………………….. ……………………….. 18
1.3.3 Tableau Dekstop ………………………….. ………………………….. ………………………….. .. 18
1.3.4 Google analytics ………………………….. ………………………….. ………………………….. .. 19
2 CAPI TOLUL 2 – „Testarea produselor software” ………………………….. ……………………….. 20
2.1 Testarea software – descriere ………………………….. ………………………….. …………………. 20
2.1.1 Termenul de „Bug” ………………………….. ………………………….. ………………………… 20
2.2 Testare software si Asigurarea Calitatii – istoric ………………………….. …………………… 21
2.2.1 Inceputurile ………………………….. ………………………….. ………………………….. ………. 21
2.2.2 Perioada 1945 – 1956 in testarea produselor software ………………………….. ……… 21
2.2.3 Perioada 1 957 – 1978 ………………………….. ………………………….. …………………….. 21
2.2.4 Anii 1979 – 1982 ………………………….. ………………………….. ………………………….. . 22
2.2.5 Perioada 1983 – 1987: Orientarea spre evaluare ………………………….. …………….. 22
2.2.6 1988 – Prezent ………………………….. ………………………….. ………………………….. ….. 23
2.3 Meto dologii folosite in testarea produselor software ………………………….. ……………… 24
2.3.1 Definirea si importanta metodologiilor de testare ………………………….. …………… 24
2.3.2 Metodologia Agile – sumar ………………………….. ………………………….. ……………… 24
2.3.3 Scrum – sumar ………………………….. ………………………….. ………………………….. ….. 26
2.3.4 Metodologia Waterfall – Sumar ………………………….. ………………………….. ………. 27
2.4 Tipuri de testare: ………………………….. ………………………….. ………………………….. ……… 29
2.4.1 Black bo x testing ………………………….. ………………………….. ………………………….. . 30
2.4.2 White box testing ………………………….. ………………………….. ………………………….. . 30
2.4.3 Unit testing ………………………….. ………………………….. ………………………….. ………. 30
2.4.4 Incremental integration testing ………………………….. ………………………….. ………… 31
2.4.5 Integration testing ………………………….. ………………………….. ………………………….. 31
2.4.6 Functional testing ………………………….. ………………………….. ………………………….. 31

3
2.4.7 System testing ………………………….. ………………………….. ………………………….. …… 32
2.4.8 End to end testing ………………………….. ………………………….. ………………………….. 32
2.4.9 Sanity testing ………………………….. ………………………….. ………………………….. ……. 32
2.4.10 Regression testing ………………………….. ………………………….. ………………………….. 33
2.4.11 Acceptance testing ………………………….. ………………………….. …………………………. 33
2.4.12 Load testing ………………………….. ………………………….. ………………………….. ……… 33
2.4.13 Stress testing ………………………….. ………………………….. ………………………….. …….. 34
2.4.14 Performance testing ………………………….. ………………………….. ……………………….. 34
2.4.15 Usability testing ………………………….. ………………………….. ………………………….. … 34
2.4.16 Install/Uninstall testing ………………………….. ………………………….. …………………… 34
2.4.17 Recovery testing ………………………….. ………………………….. ………………………….. .. 34
2.4.18 Security testing ………………………….. ………………………….. ………………………….. …. 35
2.4.19 Compatibility testing ………………………….. ………………………….. ……………………… 35
2.4.20 Comparison testing ………………………….. ………………………….. ………………………… 35
2.4.21 Alpha testing ………………………….. ………………………….. ………………………….. …….. 35
2.4.22 Beta testing ………………………….. ………………………….. ………………………….. ………. 35
2.5 Testare manuala ………………………….. ………………………….. ………………………….. ………. 36
2.5.1 Descrierea procesului ………………………….. ………………………….. …………………….. 36
2.5.2 Platforme utilizate in testarea manuala – Jira………………………….. ………………….. 37
2.6 Testare automata ………………………….. ………………………….. ………………………….. ……… 39
2.6.1 Descriere procesului ………………………….. ………………………….. ………………………. 39
2.6.2 Importanta testarii automate ………………………….. ………………………….. ……………. 39
3 CAPITOLUL 3 – Aplicatia dezvoltata: uSON Dashboard ………………………….. ……………. 41
3.1 Platforme folosita pentru dezvoltare: ………………………….. ………………………….. ………. 41
3.1.1 Platforma folosita: IntelliJ IDEA Ultimate ………………………….. …………………….. 41

4
3.2 Tehnologii folosite pentru dezvoltar e: ………………………….. ………………………….. …….. 42
3.2.1 jQuery ………………………….. ………………………….. ………………………….. ……………… 42
3.2.2 Underscore.js ………………………….. ………………………….. ………………………….. ……. 44
3.2.3 Sheetjs js -xlsx ………………………….. ………………………….. ………………………….. …… 45
3.2.4 Chart.js ………………………….. ………………………….. ………………………….. …………….. 47

5
Introducere

Tem ă și con ținut
Tema lucrării este reprezentată de încadrarea noțiunii de “Business Intelligence” în
testarea produselor software și de modul în care acest concept poate aduce o inovație și un
context ajutător procesului de testare în domeniul IT. O scurtă descriere a acestora se va regăsi
în cadrul Introducerii.
Capitolul 1, intitulat “Conceptul de Business Intelligence”, descrie în detaliu această
noțiune și o înca drează în contextul domeniului din care face parte printr -o scurtă descriere
inițială. Urmează un scurt istoric al Business Intelligence ce a luat naștere în anul 1865,
parcurgând evoluția acestui concept de -a lungul istoricului tehnologic din domeniul IT până în
zilele noastre. Se va succede apoi o analiză în detaliu a conceptului de Business Intelligence din
punct de vedere al folosirii și implementării efective, pe componente, explicând totodată fiecare
componentă în parte și rolul acestora într -un siste m de Business Intelligence. Capitolul se
încheie cu câteva exemple de aplicații și soluții software, cele mai utilzate și apreciate la ora
actuală, acestea reprezentând în același timp și o sursă de inspirație și orientare pentru aplicația
dezvoltată de mi ne.
Capitolul 2, “Testarea produselor software”, definește conceptul de testare în domeniul
IT, precum și alți termeni și alte proceduri din domeniu. După o scurtă explicație asupra
activității de testare și după introducerea termenului de “bug”, adesea folosit în domeniu, este
relatat un istoric al evoluției procesului de testare, începând cu anul 1944, pe timpul Celui de –
al II -lea Război Mondial, până în prezent. Se vor prezenta ulterior principalele
metodologii folosite în domeniul testării softw are și importanța acestora : Metodologia
Agile și Metodologia Waterfall. După definirea termenilor, a activității de testare și a
metodologiilor folosite în domeniu, sunt prezentate toate tipurile de tesare folosite în prezent,
acoperind astfel întrea ga arie a domeniului dezvoltării aplicațiilor software. Cele mai
cunoscute metode de testare sunt: Black box testing, White box testing, Functional testing, Load
testing, Performance testing, etc. Vor fi totodată prezentate și metode precum Unit test ing,
System testing, Acceptance testing, Recovery testing, etc.

6
Motivarea temei
Alegerea acestei teme este influențată atât de experiența de peste un an de lucru
în domeniul testării software, în special a testării manuale, cât și de dorința de îmbună tățire și
optimizare a întregului proces de testare software folosind noi tehnologii și concepte.
Noi componente și departamente au luat naștere datorită vitezei cu care avansează
domeniul IT și datorită noilor necesități și cerereri de înalta calitate a p roduselor software. O
componentă de baza în cadrul firmelor producătoare de soft este departamentul de testare, ce
are tangențe cu întregul proces de realizare a produsului, chiar și după ce acesta este lansat pe
piață.
Pe de altă parte, conceptul de “Busi ness Intelligence” poate fi integrat ușor în procesul
de testare, deoarece se referă la seturi de strategii, procese, colecții de date, distrubutie de date,
distribuție de informații și raportare, componente ce se regăsesc adesea în procesul de testare a
produselor software.
După cum voi prezența în capitolul 2, acesta este un domeniu puternic dezvoltat în ultima
decadă, devenind un proces absolut necesar în dezvoltarea aplicațiilor software. De aceea
consider adecvată aprofundarea acestui subiect, fiind un domeniu de viitor, în continuă
dezvoltare și creștere.
Procesul de testare este în principal dinamic și orientat către anumite obiective. Acesta
a ajuns la un nivel suficient de complex încât firmele dezvoltatoare au început să -și creeze
departamente dedi cate testării produselor software. Procesul este detaliat, îndelungat și
complex, cu rapoarte periodice și urmărind scopuri specifice, obiectivul final fiind acela de a
lansa pe piață un produs software cât mai bine realizat, capabil să satisfacă nevoile c lientului și
care să aibă cât mai puține erori.

7
1 CAPITOLUL 1 – Conceptul de “Business Intelligence” (BI)

1. Business Intelligence – descriere

Conform Wikipedia.com, Business Intelligence cuprinde un set de strategii, procese,
date și arhitecturi tehnologice folosite de către companii pentru a susține colecții de date, pentru
a prezenta și raporta datele și informațiile1. De asemenea, tehnologiile dezvoltate în Business
Intelligence oferă informații despre operațiile de business și previziuni cu pr ivire la trend -ul
acestora în viitor, bazate pe statistici și analize curente.
Beneficiile Business Intelligence sunt accelerarea și îmbunătățirea deciziilor de
marketing, îmbunătățirea proceselor interne, creșterea eficienței operaționale și acumularea de
avantaje competitive față de companiile rivale de pe piața respectivă. De asemenea, sistemele
de Business Intelligence pot determina cu acuratețe trendurile de piață și pot identifica probleme
de business. Acestea trebuie ulterior analizate și corectate p entru menținerea continuității
trendului pozitiv.
În domeniul de date, Business Intelligence include atât informații stocate de -a lungul
timpului (Historical Information) cât și date noi, culese în timp real de la sistemele sursă, pe
măsură ce acestea sunt generate. Astfel se creează un context favorabil pentru analiza Business
Intelligence pentru a sprijini atât elementele strategice cât și cele tactice pentru deciziile de
marketing. Inițial tool -urile erau folosite de către analiștii de date și alți profe sioniști IT care
realizau rapoarte de analiză pe bază de interogări, rapoarte ale căror rezultate erau trimise către
utilizatorii de business. Însă persoanele cu funcții executive de business folosesc din ce în ce
mai mult soluții software de Business Inte lligence, laolaltă cu lucrătorii și programatorii,
mulțumită „Self Service BI” și „Data Discovery Tools”.
a) a) Self Service BI (SSBI – Self-Service Business Intelligence) reprezintă o metodă
de abordare în domeniul data analytics care permite utilizatorilor de business să
acceseze și să lucreze cu date complexe și struturate2 chiar dacă nu au cunoștințe
dezvoltate în analiza de statistici, Business Intelligence sau data mining. Această

1 „Bussiness Information” – privită că una dintre cele trei componente ale Industriei Informatice, celelalte două
fiind Componentă Științifică și Componentă Tehnică și Medicală
2 Corporate data Commented [TA1]: https://en.wikipedia.org/wiki/Business
_intelligence#History

https://en.wikipedia.org/wiki/Business_information

8
nouă implementare realizează o decongestionare pe partea de date, astfel î ncât
fiecare utilizator își poate trage datele folosind interogări specifice fără să apeleze la
departamente de tehnologie și IT, permițându -le acestora o mai bună orientare către
obiectivele lor specifice.
b) Data Discovery tools , conform definiției clasice de pe Wikipedia.com, reprezintă
un proces de Business Intelligence ce constă în crearea și utilizarea rapoartelor
interactive și a explorării datelor din surse multiple. Aplicațiile de Data Recovery
folosesc visual tools precum hărți geografice, pivot -tables, sau heat -maps pentru a
susține și ușura procesul de găsire al șabloanelor specifice de date într -un mod rapid,
intuitiv și grafic. De asemenea ele folosesc și unelte statistice și tehnici de data
mining pentru a -și atinge scopul. Câteva exemple de soft -uri de data discovery,
conform Softwareadvice.com: Dundas BI, Sisense, Domo, Sage Live, IBM Cognos
Analytics, Style Intelligence, Yellowfin, Looker, IntelliFront BI, etc.

1.1 Istoricul Business Intelligence

1.1.1 Începuturile

Conform unui articol realizat în anul 2014 pe site -ul Betterbuys.com, Business
Intelligence, ca și concept și utilizare, a existat înaintea tehnologiei și are o istorie mult mai
îndelungată decât am putea să ne imaginăm intuitiv, precedând astfel calculato arele și alte
elemente tehnologice inovatoare.
Prima utilizare și apariție a termenului de Busines Intelligence a fost în lucrarea lui
Richard Millar Devens, în 1865, intitulată „Cyclopaedia of Commercial and Business
Anecdotes”. Acesta a descris modul în care un bancher, Șir Henry Furnese, a avut succes: el a
dezvoltat o înțelegere superioară despre problemele politice, instabilitățile de pe piață și
industrie, înaintea competitorilor săi. Citând din lucrarea lui Devens: „Throughout Holland,
Flanders3, Fra nce, and Germany, he maintained a complete and perfect train of business
intelligence” (în traducere: Prin Olanda, nordul Belgiei, Franța și Germania, acesta a menținut
o perfectă linie de Business Intelligence) în sensul că a analizat situația acestor reg iuni,

3 regiune din nordul Belgiei în care se vorbește limba Daneză

9
colectând și realizând aproximativ 3000 de anecdote ilustrative și incidente pentru a crea o
imagine clară asupra acestora și a le supraveghea.

1.1.2 Dezvoltarea până în 1950

Tehlonogia până în acel moment nu se dezvoltase îndeajuns încât să fie un do meniu de
aplicabilitate pentru Business Intelligence din acele vremuri. Acest lucru s -a întâmplat abea în
secolul XX.
Potențialul BI în domeniu a fost recunoscut abea în 1958 de către un informatician de la
IBM, Hans Peter Luhn. În lucrarea sa intitulată „ A Busines Intelligence System”, acesta a
descris „un sistem automatic, dezvoltat pentru diseminarea informațiilor în numeroase secțiuni
a oricărei organizații industriale, științifice sau guvernamentale”, în traducere aproximativă.
După Cel De-al II-lea Război Mondial, datorită boom -ului tehnologic și industrial, a fost nevoie
de o soluție de organizare și simplificare a manipulării volumului foarte mare de date în continuă
creștere.
Ca o concluzie a lucrării sale, Luhn afirmă că Business Intelligence, în e sență, este
considerat un mod simplu de a înțelege și manipula volume mari de date astfel încât să se poată
lua deciziile optime. Informaticianul nu doar a introdus și dezvoltat posibilitățile conceptului, ci
a și dezvoltat și stabilit metode și noi concep te care au dus la realizarea unor sisteme de analiză
de baza ale IBM -ului de astăzi.

1.1.3 Evolu ția până la sfârșitul anilor 80’

Odată cu apariția calculatoarelor, companiilor li s -a dat în sfârșit o alternativă în privința
stocării datelor și informațiilor pe hârtie. De asemenea, IBM a revoluționat stocarea datelor prin
inventia hard disk -ului în 1956. Odată cu apariția acestuia, împreună cu dischetele, discurile
laser și alte tehnologii de stocare, a crescut foarte mult și volumul de date, iar odată cu ace stea
nevoia tot mai mare de loc de stocare. Aceasta a dus la realizarea primului sistem de
management al bazelor de date, denumit la acea vreme DSS4. Până în 1970, deja existau activiști
în domeniul Business Intelligence care ofereau tool -uri pentru accesa rea și organizarea datelor,

4 Decision Support Systems Commented [TA2]: https://www.betterbuys.com/bi/histor
y-of-business -intelligence/
Commented [TA3]: http://www.pyramidanalytics.com/pag
es/blog/2016/02/brief -history -business -intelligence.aspx

10
însă acestea erau destul de stângace, rudimentare și altfel greu de folosit. In 1988 a avut loc o
conferinta internationala pe tema procesarii datelor. Consortiul denumit „Multiway Data
Analysis” a avut loc in Roma si a fost o pi atra de temelie pentru inceperea simplificarii analizei
Business Intelligence .

1.1.4 Anii 1980 – 1990 , moment i mportant pentru revolu ționarea Busines I ntelligence
Analistul informatic a adus și încadrat termenul în utilizarea contemporană. În anii 80’
deja e ra clar că analiza informațiilor de business prin sisteme informatice avea un viitor foarte
strălucit. În acea vreme Dresner lucra pentru Future Gartner Group, și declara că Busines
Intelligence consta în orice metodă sau concept care ajută la îmbunătățire a procesului de decizie,
utilizând sisteme bazate pe gestiunea faptelor.
În anii 2000 noi termeni au fost introduși în data analytics, precum „Business Analytics”
și „Strategic Intelligence”. Nu există un standard universal pentru acești termeni, însă aceș tia
operează sub umbrela conceptului de „Big D ata5”, arhicunoscut în domeniu. Iata o scurta
definitie a celor 2 termeni nou introdusi:
a) Business Analytics, conform Wikipedia.com se referă la aptitudini, tehnologii și
practici pentru o continuă și iterativă explorare și investigare a evolitiei performanței
de business din trecut, folosind date și metode statistice pentru a realiza un planning
de business cât mai corect;
b) Strategic intelligence înseamnă atât colectarea, procesarea, analiza și diseminarea
inform ațiilor pentru realizarea planurilor politice și militare la un nivel național și
internațional, cât și unui set de însușiri și aptitudini pe care le deține un lider pentru
a putea fi un strateg bun.

1.1.5 Anii 2000, Busines s Intelligence 1.0
Pe măsură ce Business Intelligence devine un termen foarte folosit în anii 90’ și 2000,
foarte mulți noi jucători apar pe piață. În această perioadă existau două funcții de bază ale BI:
producerea de date și rapoate, și organizarea acestora într -un mod câ t mai prezentabil, clar și

5 date prelucrate și păstrate în cantități imense, datorită unor medii de stocare ieftine, unor metode de procesare mai
rapide și a unor algoritmi mai performanți: definiția Big Data conform Wikipedia.com Commented [TA4]: http://www.investopedia.com/ask/ans
wers/033015/what -are-historical -origins -business –
intelligence.asp
Commented [TA5]: https://www.betterbuys.com/bi/histor
y-of-business -intelligen ce/

11
ușor de înțeles pentru informatician. Existau însă două probleme care îngreunau această
implementare: complexitatea și timpul.
Mult prea multe proiecte IT se dezvoltau și aparțineau departamentelor de IT, însemnând
că încă mulți utilizatori nu puteau executa task -uri de Busines Intelligence pe cont propriu. Tool –
urile pentru gestiune din acea vreme erau realizate exclusiv de către experți, iar pentru folosirea
acestora era nevoie de un proces de training îndelungat și elaborat. Aș adar numai informaticienii
de nivel înalt erau capabili să lucreze în analiza de date, până când tool -uri ajutătoare au fost
dezvoltate.

1.1.6 Business Intelligence 2.0
Începutul secolului 21 a adus odată cu sine o revoluție în domeniul BI, așteptată de toată
lumea, pe măsură ce tehnologiile continuau să evolueze rapid, acestea aducând cu ele noi
probleme de complexitate ridicată și cu cerere de rezolvare imediată. De asemenea, conceptul
de Cloud începuse să se dezvolte, extinzând și ușurând accesul la platforme de BI.
Printre altele BI 2.0 găzduiește diferite tehnologii de procesare în timp real care
încorporează informații provenite din evenimente informatice pe măsură ce acestea se întâmplă,
fiind stocate în Data Warehouses, permițând companiilor să ia decizii bazate pe cele mai recente
informații apărute.
Alte tehnologii care au apărut pe piață includeau servicii de acces pentru utilizatorii
comuni. Aceasta însemna că angajații puteau astfel completa proiecte fără a avea tangențe cu
departamentul IT al firmei, chiar și pe partea de Business Intelligence, inaccesibilă lor până
atunci.
Începând cu anul 2005, când deja interconectarea entităților din lumea de business avea
nevoie, pentru a continua să existe, de informații în timp real, Business Intelligence deja nu mai
era o utilitate adăugată, ci o nevoie, o componentă absolut necesară pentru a supraviețui pe piață,
pentru a supraveghea competiția și pentru a gestiona propriile resurse.

1.1.7 Busines s Intelligence în zilele noastre
Platformele de BI au prins o agilita te uimitoare, fiind într -o continuă transformare și
dezvoltare și devenind specifice și de sine stătătoare, pe măsură ce penetrează diferite zone de

12
activitate. Astăzi conceptul și tehnologiile sunt folosite cu foarte mare grad de utilitate în
sistemul med ical, în sistemul de justiție, chiar și în lumea sportului.
Odată cu revoluția Big Data și explozia internetului, BI și -a făcut loc tot mai ușor în IT,
datorită volumelor uriașe de date ce trebuie gestionate și manipulate, după care folosite și expuse
într-o manieră cât mai ușoară, rapidă și utilă, într -o eră în care se trimit aproximativ 204 milioane
de mailuri pe minut.
Necesitatea pentru Business Intelligence a devenit atât de mare încât au fost dezvoltate
tool-uri oferite ca serviciu, de exemplu Cloud B I6 care reduce costurile pentru stocare și permite
accesul organizat la date foarte rapid, de oriunde din lume, având și diferite facilități.
Odată cu apariția și evoluția dispozitivelor mobile, soluții de BI au fost implementate
pentru a folosi și această componentă a tehnologiei actuale, realizându -se numeroase soluții ce
fac parte din categoria Mobile BI.

1.2 Business Intelligence – componente și implementare
Deși principalele componente ale BI nu pot fi identificate sub un standard unic, există
câteva comp onente principale utilizate pentru a defini conceptul, utilizarea sa și caracteristicile
esențiale așezate în schema următoare:

6 soluție online bazată pe cloud

13
1.2.1 Componenta analytics :
Soluțiile de analiză pentru BI ajută la studiul datelor și conversia acestora în informații
concrete de care pot beneficia organizațiile pentru a -și îndeplini obiectivele în domeniul de
activitate.
Companiile dețin un volum foarte mare de date: date despre clienți, date tehnice ale
produselor, documentație, procese interne de business, date de testare, e tc. De multe ori, acestea
nu pot fi rapid transformate în informații utile, accesate cu rapiditate, sau nu pot fi interpretate
sugestiv astfel încât să servească scopurilor folosirii lor. Business Intelligence vine cu câteva
tehnologii care se ocupă exact de acest lucru. Aceste a sunt împărțite în 3 categorii :
– Guided Analysis and Reporting7, categorie ce include soluțiile tradiționale de BI ce
au fost folosite de -a lungul anilor pentru a realiza analize recurente și specifice de
date. Componentele principale ale soluțiilor din această categorie sunt: Reports,
Dashboards and Scoreboards, Corporate Performange Management, Spreadheet
Integration, BI Search ;
– Self-service BI and analyis – această categorie cuprinde tool -uri de BI care au ca
scop analiza ad -hoc de date ce sunt folosite în special de oamenii de business,
analiștii financiari, angajații din departamentul de resurse umane sau managerii.
Componente principale: Ad -hoc Reporting and Analysis, Online Analytical
Processing, Dată Discovery, Dată Visualizatio n.
– Advanced Analytics oferă tool -uri pe care oamenii de știință le folosesc pentru a crea
modele de date predictive. Aici intră soluții software pentru analiză predictivă,
modelare statistică, Data Mining și analiză de Big Data .

1.2.2 Componenta de Data Mining (extragerea datelor și informa țiilor)
Este una dintre cele mai importante componente deoarece reprezintă procesul extragerii,
manipulării și analizei datelor din perspectiva unor criterii precise, pentru a realiza un sumar al
informațiilor într -o formă primară și utilizabilă.
Din punct de vedere tehnic, Dată Mining este procesul de găsire a corelațiilor și a
șabloanelor printre multe câmpuri și baze de date relaționate. Dată mining se poate împărți în 2
categorii :

7 Analiză și Raportare Ghidată Commented [TA6]: http://searchbusinessanalytics.techtarg
et.com/feature/Understanding -BI-analytics -tools -and-their-
benefits
Commented [TA7]: http://www.blog –
geographica.com/2016/11/15/how -data-mining -is-used-to-
generate -business -intelligence/

14

– Data mining descriptiv, care ofer ă informa ții despre datele existente;
– Dată mining predictiv, ce realizează predicții ale evoluției datelor în viitor pe baza
trend -ului datelor actuale. Pentru această categorie sunt folosite statistici, tehnologii
de inteligență artificială sau chiar algor itmi de rețea ;
Ca o concluzie, componenta de Dată Mining încearcă să ajute la înțelegerea conținutului
de Big Data, bazându -se în principal pe extragerea, transformarea și gestiunea tranzacțiilor de
date în sisteme de Data Warehouse, stocarea și management ul de date în baze de date
multidimensionale, prezentarea datelor într -un format cât mai comun și ușor de vizualizat,
analiză de date, accesul la date .

1.2.3 Componenta OAP (sau Olap – Online Analytical Processing )
OLAP este o tehnologie utilizată pentru or ganizarea marilor baze de date de business
care vin în ajutorul Business Intelligence. Bazele de date OLAP sunt împărțite într -unul sau mai
multe cuburi de date, fiecare fiind organizat și administrat de către un administrator pentru a -l
modela într -un mod specific în scopul utilizării cât mai ușoare a PivotTable -urilo r și PivotChart –
urilor .
Sursa de date pentru OLAP este reprezentată de bazele de date OLTP8, adesea stocate în
Data Warehouses. Datele sunt agregate în structuri care permit analiză sofisticat ă și sunt
organizate pe niveluri și ierarhii depozitate în cuburi, în detrimentul tabelelor clasice. Sunt
folosite tehnologii sofisticate ce înglobează structuri multidimensionale, pentru a oferi un acces
rapid la date pentru analiză. Această abordare perm ite lucrul cu volume impresionante de date,
mai mari decât ar fi fost posibil dacă erau folosite ba ze de date cu structura clasică .
Cubul de date, structura de date folosită în OLAP, realizează măsurători pe niveluri și
ierarhii ale fiecărei dimeniuni în p arte ce se dorește a fi analizată. Cuburile combină mai multe
dimensiuni, cum ar fi timpul, locația geografică, linii de producție, etc, cu date sumarizate
precum vânzări, inventar, diferite trend -uri ale evoluției produselor, etc. Aceste cuburi nu
trebuie privite că și cuburi geometrice, pentru că nu au neapărat „l aturi” egale, ci sunt o metaforă
tehnologică pentru un c oncept complex, descris mai sus .

8 Online Transactional Processing Commented [TA8]: https://support.office.com/en –
us/article/ Overview -of-Online -Analytical -Processing -OLAP –
15d2cdde -f70b-4277 -b009 -ed732b75fdd6

15
Întregul sistem OLAP se bazează pe următoarele componente: cubul de date,
măsurătorile, membrii ( un item din ierarhie),
membru calculat , dimensiune, ierarhie și nivel .
1.2.4 Componenta BPR (Business process
re-engineering)
BPR reprezintă o strategie de Business
Management, ale cărei baze au fost puse încă
din anii 90’, concentrându -se pe analiză și
desing -ul wo rkflow -urilor și proceselor de
business dintr -o organizație. Aceasta avea că
scop să ajute companiile în regândirea modului
în care își desfășoară activitatea pentru a
îmbunătăți dramatic serviciile pentru clienți, a
reduce costurile drastic și a deveni co mpetitori de nivel înalt, pe piață .
Această strategie urmărește de asemenea realizarea restructurărilor radicale în companii
și organizații prin focusarea asupra design -ului pornind de la baza în sus a proceselor de
business. Aceste procese sunt adesea fragmentate în sub -procese și task -uri, fiind îndeplinite de
către multiple arii funcționale specializate în cadrul unei organizații. De aceea de multe ori
nimeni nu este direct responsabil pentru performanță per total a unui întreg proces.

1.2.5 Componenta Benchmarking
Benchmarking -ul reprezintă metoda prin care indicatorii de performanță ale proceselor
interne sunt comparați cu standardele din industrie. De asemenea, benchmarking -ul asistă în
alcătuirea unor obiective concrete și utile, înțelegând și folos ind trend -urile din domeniul de
activitate, determinând îmbunătățirile necesare, ducând astfel la o creștere per total a
performanței.
La un nivel de baza, benchmarking -ul pune în perspectivă operațiile de business. Într -un
context de management, companiil e folosesc benchmarking -ul pentru a identifica arii care nu
au resurse suficiente sau care dispun de resurse prea multe, peste nivelul necesar. Metoda mai
este folosită și pentru a compara diferite structuri și componente, pentru o vizualizare bună și
Commented [TA9]: https://en.wikipedia.org/wiki/Business
_process_reengineering
Commented [TA10]: https://www.logianalytics.com/resou
rces/bi -encyclopedia/benchmarking/

16
intuitivă a diferențelor, în scopul corectării problemelor și optimizării proceselor, la nivel de
costuri, tehnologie, timp, și calitate.
Procesul de realizare a bencharking -ului, într -o formă standardizată, a fost dezvoltată de
către Robert Camp, care a scris una dintre primele cărți despre această metodă, ce constă într -o
serie de 12 pași :
1) Selectarea subiectului;
2) Definirea procesului;
3) Identif icarea poten țialilor parteneri;
4) Ident ificarea surselor de date;
5) Colectarea de d ate și selectarea partene rilor;
6) Determinarea gap-urilor9;
7) Stabilir ea diferentelor dintre procese;
8) Determinarea unui target pentru performan ță;
9) Comunicare;
10) Adaptarea în mod progresiv a obiectivelo r;
11) Implementa rea;
12) Realizarea review -ului.

1.2.6 Componenta Data Warehouse
Cunoscută și că DW sau DWH, este un sistem complex de stocare, raportare și analiză
a datelor și este considerată o componentă de bază în Business Intelligence având numeroase
surse pentru un volum mare de date.
Datele ajung într -un Data Wareho use, de obicei, printr -un sistem complex de uploading,
ce conține un Operational Data Store10, realizându -se și un Data Cleansing11.
Un Data Warehouse este de obicei găzduit de un server mainframe, sau în Cloud, și
primește date din numeroase tranzacții OLTP12. Scopul acestora este de a fi ulterior procesate
și analizate de aplicații specifice, sau extrase cu ajutorul interogărilor .
Un Warehouse de date este construit folosind unul dintre urmatoarele forme de design:

9 Diferenta dintre nivelul potential si nivelul actual
10 Metodă de integ rare a datelor
11 Procedeu prin care se elimina erorile și se elimină datele corupte
12 Online Transaction Protocol

17
1. Bottom -up design ( de jos în sus). Folo sind această abordare, se realizează întâi un layer
inferior pentru realizarea legăturii cu end -userii, în scopul schimbului de date necesar
pentru raportare și analiză. Acest layer de bază este ulterior integrat succesiv pentru a
acționa și la un nivel su perior, pe întreaga arhitectură;
2. Top-down design ( de sus în jos ) este creat pe baza unui model enterprise normalizat,
numit „Atomic Data” ce descrie datele cu un nivel de detaliu foarte ridicat, conținând
date specif ice necesare unor anume procese .
3. Hybrid design este o formă de realizare a unui Data Warehouse ce înglobează o bază de
date în forma normală 3, ce permite eliminarea redundanței. Pentru a stoca numeroase
modele de date sunt utilizare diverse operațiuni în procesul de stocare, rezultând în urmă
acestui proces date normalizate și neredundante peste care se pot construi diferite layere
specializate .
4.
1.2.7 Componenta de reporting
Această componentă se referă la procesul de importare și exportare a informațiilor și a
datelor către end -useri folosind în special soluții de Business Intelligence, fiind o structură tipică
în sistemele de BI.
De obicei componenta de raportare este o structură programată pe baza unor parametri
bine definiți, fiind încadrată într -un proces automatizat care importă date, urmând a fi analizate
și exportate într -o manieră structurată și vizuală. Rapoartele generate pot fi statistice, grafice
sau elemente standard textuale. Datele în formă finală exportate de către componenta de
raportare pot fi integrate la rândul lor în alte compo nente sau pot fi integrate în alte procese de
analiză în sc opul obinerii unor noi rapoarte .

1.3 Câteva exemple de solutii de Busines Intelligence

Conform unui studiu realizat de către Pcmag.com, și publicat pe dată de 27 mai 2017,
cele mai apreciate și utilizate soluții de Business Intelligence în 2017 sunt: IBM Watson
Analytics, Microsoft Power BI, Tableau Dekstop, Google Analytics și Chartio.
În continuare voi expune o scurt ă analiz ă a fiecarei aplica ții, pentru o mai buna intelegere
a utiliz ării acest ora: Commented [TA11]: https://www.techopedia.com/definiti
on/30217/business -intelligence -reporting -bi-reporting
Commented [TA12]: http://www.pcmag.com/article2/0,28
17,2491954,00.asp

18

1.3.1 IBM Watson Analytics
Este un serviciu analiză și vizulizare a
datelor, utilizat pentru o rapidă recunoaștere a
șabloanelor și a descoperirii trend -urilor de
orientare a datelor, cu o interfață prietenoasă.
Facilitățile de bază ale serviciului sunt: limbajul natural, predicție analitică automată, one -click
analysis, componenta de Data Recovery Smart, metode simplificate de analiză, metode
accesibile de analiză avans ată, dashboard -uri self -service .

1.3.2 Microsoft Power BI
Înglobează o serie de unelte de analiză și expunere
a datelor cu update în timp real și cu disponibilitate sporită
pe toate tipurile de device -uri. Printr -un acces foarte rapid,
utilizatorii își pot vizualiza datele sub diferite forme, atât
simple cât și complexe, folosind dashboard -urile încorporate și tool -uri intuitive. Power BI
folosește un sistem de raportare complex și poate reuni datele dintr -o organizație sau companie,
fie în Cloud sau On -Premises, oferind un grad de disponibilitate impresionant. Tool -ul se poate
conecta la se rvere de baze de date realizate folosind SQL Server sau modele din gama Analysis
Services. De asemenea dashboard -urile din Power BI pot fi înglobate în alte aplicații sau
sisteme, aceasta fiind una dintre facilitățile de bază ale soft -ului.

1.3.3 Tableau Deksto p
Aceasta este o unealtă software din categoria „Dată
Analytics and Reporting” cu o interfață prietenoasă, ce
poate fi folosită aproape de oricine datorită design -ului facil
și a multor operațiuni ce pot fi realizate în cadrul apliatiei
cu ajutorul me todei „drag and drop”. O altă facilitate este
reprezentată de posibilitatea de a realiza prezentări chiar în interiorul Tableau Desktop, într -o
manieră în care datele se autoexpun și sunt ușor de perceput și înțeles. De asemenea, tool -ul are
încorporat un mod de lucru offline, care nu necesită acces la rețea sau la bazele de date, realizând
Commented [TA13]: https://powerbi.microsoft.com/en –
us/what -is-power -bi/
Commented [TA14]: http://en.dwhwiki.info/charting/dash
board/tableau

19
extragerea datelor datelor în câteva secunde pentru o analiză ad -hoc. Acesta folosește și combină
tehnologii avansate de baze de date și grafică pe calculator, astfel în cât este posibilă analiza
volumelor imense de date pe un simplu laptop .

1.3.4 Google analytics
Este un freemium oferit de către google, care
urmărește și raportează traficul web și care a ajuns să fie cel
mai folosit serviciu de analiză de pe internet. Acesta este
disponibil în două versiuni: Google Analytics 360 (înainte
denumit Google Analytics Premium), orientat către clienții
enterprise și Google Analytics for Mobile Apps, o soluție
ce permite acumularea datelor despre trafic ale aplicațiilor dezvolt ate pe iOS și Android.
Serviciul oferit de Google are o performanță atât de ridicată, încât pe domeniul de analiză și
statistică este folosit de aproximativ 55% dintre cele mai popule 10.000 de site -uri.

Commented [TA15]: https://en.wikipedia.org/wiki/Google
_Analytics

20
2 CAPITOLUL 2 – Testarea produselor software

2.1 Testarea software – descriere
Testarea software reprezintă o investigare amănunțită a unui produs software, pentru a
oferi informații despre un produs software sau un serviciu. Testarea poate oferi, de asemenea,
obiective noi sau puncte de vedere independente asupra produsului testat, determinând astfel
posibilitatea și riscurile de implementare ale acesteia.
Tehnicile de testare, în general, sunt orientate către găsirea problemelor, erorilor și
defectelor produsului software denumit e bug -uri.

2.1.1 Termenul de „ Bug”
Acest termen, folosit pentru a descrie probleme în sistemele informatice, a fost atribuit
Amiralului Grace Hopper, în anul 1940. În timp ce acesta lucra la un computer Mark II, la
universitatea Harvard, membrii echipei de dezvoltar e au găsit o molie prinsă în niște circuite ale
computerului, împiedicând buna funcționare a acestuia. Acesta a denumit procesul de
îndepărtare a moliei din circuitele calculatorului „ Debugging”13.
Prima apariție a termenului de „Bug” cu sensul de eroare te hnică, însă, îi revine lui
Thomas Edison, în anul 1878, iar termenul de „ Debugging” mai fusese folosit înainte în
domeniul aeronauticii.
Procesul de testare se realizează chiar în timpul implementării și dezvoltării produsului
respectiv, pentru corectarea progresivă a erorilor în faze cât mai incipiente ale implementării.
Pe lângă descoperirea și corectarea defectelor, procesul de testare are și rolul de validare,
însemnând testarea noilor funcții și elemente în vederea implementării acestora, dacă sunt fia bile
și oferă rezultatele corespunzătoare.

13 de la „bug” – gâză, molie, insectă (eng.) Commented [WU16]: https://en.wikipedia.org/wiki/Softw
are_testing

Commented [WU17]: https://en.wikipedia.org/wiki/Debu
gging

21
2.2 Testare software și Asigurarea Calității – istoric

2.2.1 Începuturile
Dezvoltatorii de produse software le -au realizat și testat încă de când aceștia au început
să le realizeze, imediat după Cel de -al II -lea Război Mondial, însă termenul de Quality
Assurance14 a luat naștere mult mai devreme.
La început, dezvoltatorul sau pro gramatorul și utilizatorul erau una și aceeași persoană,
de regulă un om de știință. Tot acesta se ocupă și de procesul de testare, ca parte din cursul
natural al realizării produsului software. Ace asta a permis ca Asigurarea Calității să fie extrem
de ef icientă și foarte concentrată pe nevoia utilizatorului, având și un proces de feedback
continuu și rapid .
Pe măsură ce numărul utilizatorilor s -a mărit au apărut profesii noi, specializate, cum ar
fi dezvoltatorii de software. Mai târziu, unul câte unul, a u apărut managerii de proiecte, analiștii
de business, arhitecții șefi, inginerii șef, designeri și, în sfârșit, testerii.

2.2.2 Perioada 1945 – 1956 în testarea produselor software
Această perioadă a fost dominată de „debugging” , când testarea era asociată ex clusiv
cu debugging -ul și nu se putea realiza o diferențiere clară între acest proces și cel de testare
efectivă. De asemenea, în această eră nu se punea accentul atât de mult pe partea de software,
cât pe partea de hardware a unui produs unitar, considerâ ndu-se mai importantă partea fizică.
Pentru a oferi o definiție a procesului, Debugging reprezintă activitatea de găsire și
rezolvare a defectelor care previn buna funcționare a unui sistem informatic. Desigur, în
perioada aceasta, procesul era mult mai st rict și rudimentar, spre deosebire de un proces de
testare în zilele noastre, mult mai complex și elaborat.

2.2.3 Perioada 1957 – 1978
Odată cu creșterea și îmbunătățirea produselor informatice, atât la nivel de complexitate
și performanță, cât și de utiliare ș i cost, a început să evolueze și activitatea de testare a acestora.
A fost nevoie ca testarea să se realizeze pe scară largă și la un nivel mai ridicat, deoarece

14 Asigurarea calitatii Commented [WU18]: https://saucelabs.com/blog/quality –
assurance -and-software -testing -a-brief -history

22
tehnicile folosite până atunci nu mai erau la fel de relevante. O nouă viziune a fost introdus ă,
puțin mai evoluată față de cea din perioada anterioară, și anume că procesul de testare are ca
scop identificarea și îndepărtarea problemelor și erorilor și asigurarea funcționării corecte a
produsului software – o definire mai clară a activității de te stare, deși aceasta încă se suprapunea,
chiar confunda cu procesul de depanare dar sub un scop comun, cu orientare spre același
obiectiv.

2.2.4 Anii 1979 – 1982
Această perioadă este cunoscută sub numele de „Perioada orientată spre defectare”.
Odată cu apariția lucrării „The Art oof Software Testing” de către Glenford J. Mayers,
conceptele de depanare și testare devin în sfârșit ceva mai bine delimitate și separate, fiind
văzute ca două activități distincte. Acesta explică în lucrarea sa cele două concepte în fe lul
următor:
– Depanarea, procesul ce se realizează în timpul dezvoltării produsului și ține de
realizarea acestuia ;
– Testarea, procesul de rulare și execuție a programului, cu scopul exclusiv de a găsi
erori și defecte de funcționare.
Acesta orientează procesul de testare spre încercarea de alterare, defectare intenționată
a unui produs software prin găsirea unor situații în care acesta nu funcționează corect, prin
utilizarea unor seturi de parametri ieșiți din tipare.
Glenford Myers, născut pe 12 Decem brie 1946 a fost un
antreprenor și un om de știință în domeniul computațional. Acesta a
fondat două companii de high -tech (RadiSys și IP Fabrics), a fost
autorul a opt cărți în domeniul științei calculatoarelor și a contribuit
la realizarea arhitecturilor microprocesoarelor .

2.2.5 Perioada 1983 – 1987: Orientarea spre evaluare
Ideologia acestei perioade a fost ca în timpul dezvoltării și
vieții unui produs software să se ofere o evaluare periodică a acestuia din punct de vedere a
calității.

23
Tot în această perioa dă, mai ales în anul 1983, Biroul de Standarde din Statele Unite ale
Americii a publicat un set de reguli și practici ce se adresesaza exclusiv procesului de testare,
verificare și validare a produselor și sistemelor software. Metodologia nou apărută se ad resa în
mod specific instituțiilor federale americane și cuprindea metode de analiză și testare ce urmau
să fie folosite și aplicate în timpul ciclului de viață al unui produs software.
Aceasta a fost o perioada revoluționară datorită
noilor concepții asu pra procesului de testare, precum
testarea personalizată, orientată spre specificul
produsului, prin teste și verificări adresate exclusiv
produsului în cauză, în scopul creșterii calității generale a acestuia .
De asemenea, persoanele ce activau în domeniu l testării erau mult mai profesioniste și
dedicate datorită noilor tehnici și metodologii, acestea ducând efectiv la apariția unor posturi de
lucru precum tester, manager de testare sau analist de teste.
Procesul de standardizare este și el prezent în ac eastă epocă și chiar și în zilele noastre:
instituțiile americane ANSI15 Ameri can
Național Standars Institute și IEEE16
Institute of Elect rical and Electronics
Engineers realizează niște standarde cu
scopul de a formaliza diferite procese
printre care și cel de testare. Printre
măsurile concrete se numără, de exemplu,
stabilirea unui format pentru realizarea
documentațiilor de testare.

2.2.6 1988 – Prezent
Începând cu anul 1988 testarea în domeniul software va fi orientată spre prevenire, ca o
contra măsură a nașt erii defectelor și erorilor în sistemele informatice. Datorită îmbunătățirii
metodologiilor realizate de către IEEE se ajunge la concluzia că testarea trebuie să aibă loc în
toate fazele de lucru în același timp în care se realizează și procesul de program are, având

15 American Național Standars Institute
16 Institute of Electrical and Electronics Engineers

24
următoarele activități principale: planificare, analiză, proiectare, implementare, execuție și
întreținere. Metodologia urma să ajute la scăderea costurilor de realizare și mentenanță a unui
sistem software prin reducerea efectivă a numărului de erori și defecte care rămân nedescoperite
în momentul în care produsul ajunge în faza finală și urmează să fie lansat.

2.3 Metodologii folosite în testarea produselor software

2.3.1 Definirea și importanța metodologiilor de testare
Metodologiile de testare reprezintă diferite moduri de abordare ale procesului de testare
și metode de a asigura testarea în totalitate a aplicației software. Aceste metodologii cuprind tot
ce ține de testarea unui produs, începând cu testarea de bază a diferitelor module și compo nente,
până la sisteme de testare specializate, orientate către performanță și securitate.
Pe măsură ce produsele software au evoluat, devenind din ce în ce mai complexe și fiind
dezvoltate în diferite forme și pe diferite platforme, adresându -se unui num ăr mare de utilizatori,
este mai important ca niciodată să existe o metodologie de testare robustă și dinamică în scopul
testării cât mai eficiente și complete a produsului software, pentru a satisface nevoile clienților
și utilizatorilor.
Există mai multe metodologii și modele folosite în dezvoltarea și testarea software, cele
mai cunoscute dintre acestea fiind: Agile, Scrum și Waterfall.

2.3.2 Metodologia Agile – sumar
Metodologia Agile descrie un set de valori și principii
care se referă la dezvoltarea software și testare, și sunt aplicate
în mod colectiv în interiorul echipelor funcționale .
Cele mai importante principii ale Agile sunt
planificarea adaptată, livrarea p eriodică și cât mai rapidă,
dezvoltarea evolutivă și îmbunătățirea continuă, fiind astfel
considerată o metodologie iterativă și incrementală.
Nu putem vorbi despre metodologia Agile fără să
pomenim Agile Manifesto, alcătuită de șaptesprezece fondatori și inițiatori ai metodologiei, ce
reunește principiile de bază.
Commented [WU19]: https://www.inflectra.com/ideas/top
ic/testing -methodologies.aspx
Commented [WU20]: https://en.wikipedia.org/wiki/Agile
_software_development

25
Acestea sunt principalele idei si obiective urmărite de catre Agile Manifesto:
1. Indivizii și interacțiunile, mai mult decât procesele și uneltele;
2. Elemente software funcționale, mai mult decât doc umentație cuprinzătoare;
3. Colaborarea cu clientul, mai mult decât negocierea contratului;
4. Răspunsul la schimbare, mai mult decât urmărirea unui plan;

Pe lângă aceste idei principale, metodologia Agile se mai remarcă printr -un set de
douăsprezece principii și reguli care se regăsesc și în ideile menționate mai sus:
1. Satisfacerea clientului prin livrare timpurie și continuă de software corespunzător;
2. Primirea cu brațele deschise a schimbărilor, chiar și în stagii mai avansate de
dezvoltare;
3. Software funcțional este livrat frecvent (preferabil săptămânal decât lunar);
4. Relație apropiată între oamenii de business și dezvoltatori;
5. Proiectele sunt construite în jurul oamenilor motivați, care sunt demni de încredere;
6. Conversație față în față, folosită ca cea mai bună formă de comunicare;
7. Principala unitate de măsură a progresului este software -ul funcțional;
8. Dezvoltare sustenabilă;
9. Atenția continuă orientată către o parte tehnică bine făcută și design deosebit;
10. Simplicitate – arta de a maximiza cantitatea de muncă nef ăcută – element esențial;
11. Cele mai bune arhitecturi, cerințe și forme de design vin de la echipe organizate;
12. În mod regulat, echipa dezbate modalități de a deveni mai eficientă și se adaptează
conform rezultatelor.

Metodologia Agile este folosită intens și în domeniul testării, sub terminologia de
Agile Testing. Aceasta poate fi definită ca un set de practici și principii ce urmează structura
Agile Software Development, despre care am vorbit anterior.
Modul de funcționare al regimului de testare din cadru l Agile Testing este unul bazat
pe integrare continuă între testare și dezvoltare. Testarea nu se desfășoară secvențial ci
continuu și iterativ, după ce se încheie o etapă de programare și dezvoltare a produsului
software. O echipă de testare Agile lucreaz ă având ca obiectiv atingerea calității dorite.
Aceasta își desfășoară activitatea din punct de vedere temporal în segmente numite iteratii

26
(să spunem între 1 și 4 săptămâni). La finalul unei astfel de iteratii, închizându -se inclusiv
ciclul de testare, se realizează lansarea unei noi versiuni, proaspăt testată și îmbunătățită,
proces ce se mai numește și „release”17.

2.3.3 Scrum – sumar
Scrum este o metodologie ce provine din Agile Software Development, despre care am
vorbit anterior, oferind pași ceva mai c oncreți și specifici asupra procesului de dezvoltare a cărui
etapă finală este testarea.
Metodologia Scrum este concepută și aplicată mai ales asupra echipelor formate din
aproximativ zece oameni și se bazează în general pe întâlniri scurte zilnice în care se discută
progresul, starea curentă, obiectivele viitoare pe termen scurt, etc. și release -uri la două
săptămâni, aceste cicluri de lansare numindu -se sprint -uri.
Scrum se orientează puternic către fazele de lansare ale produsului software, din acest
motiv încercându -se menținerea produsului într -un stadiu livrabil permanent, acolo unde este
posibil, aceasta incluzând dezvoltare continuă și testare permanentă. La sfârșitul fiecărui ciclu
de sprint, echipa discută potențialul de livrare al soft -ului în sta diul respectiv și incrementează
planul de dezvoltare către următoarea iterație, continuând astfel procesul de tip Agile.
Scrum introduce roluri și responsabilități particulare în echipă, cele principale fiind
următoarele: Product Owner, Scrum Master și Tea m.
1. Product Owner: este poate cel mai important din echipa Scrum și trebuie să fie
îndeplinit de către o persoană cu viziune, dinamism, autoritate, putere de decizie și
cu grad mare de disponibilitate. De asemenea, este o persoană ce joacă rolul de
interfaț ă între echipă și alte părți implicate (cum ar fi stakeholders).
Responasibilitățile unui Scrum Product Owner sunt schimbătoare și dinamice,
ocupându -se practic de întreaga desfășurare corespunzătoare a procesului de
dezvoltare.
2. Scrum Master are un rol mai pasiv și nu se implică neapărat direct în procesul de
producție, dezvoltare sau testare. Acesta supraveghează lucrul echipei în raport cu
principiile metodologiei Scrum și veghează asupra respectării acesteia. Ca și poziție,
acesta este mai apropiat de ec hipă decât de partea superioară a ierarhiei, asigurând

17 Lansare pe piata Commented [WU21]: https://en.wikipedia.org/wiki/Scru
m_(software_development)

27
înlăturarea impedimentelor ce împiedică buna funcționare a lucrurilor și atingerea
obiectivelor sprint -ului. Acest lucru ajută echipa să rămână creativă și productivă,
realizându -și în același timp tas k-urile, asigurându -se astfel un nivel de eficientă
vizibil de către Product Owner.

3. Team (echipa propriu -zisă) se ocupă efectiv de producție, sau de testare, după caz,
și se auto manageriază. Acesta nu este un model clasic de echipa care primește
taskuri de la superiori pe care le duce la bun sfârșit, oferind un rezultat final. Echipa
Scrum are capacitatea de a decide singură asupra modului de funcționare și a
gestiunii activității, își creează singură task -urile specifice, le împarte între membri
și asigu ră relațiile între aceștia. Practic echipa Scrum preia din responsabilitățile unui
Team Leader, ce în mod normal impune aceste aspecte echipei pe care o conduce.
Această nouă metodă, însă, asigură o fluență deosebită și o modalitate inedită de
realizare a activității de dezvoltare -testare, printr -o dinamică adaptată condițiilor din
momentul respectiv, interschimband rolurile și responsabilitățile practice ale
membrilor săi. Astfel, Scrum Master -ul nu trebuie să împartă sarcini și să le
supravegheze, ci mai degrabă să se asigure că echipa funcționează eficient și se
îndreaptă către îndeplinirea obiectivului stabilit. După cum am spus, acesta are rolul
de a elimina impedimentele activității echipei, asigură o bună funcționare a acesteia
într-un mod mai pasiv ș i oferă condițiile de realizare a activității de dezvoltare.

2.3.4 Metodologia Waterfall – Sumar
Waterfall este o metodă secvențială, non -iterativă, folosită în dezvoltarea produselor
software, în care activitatea decurge liniar către finalizare, ca o cascad ă, trecând succesiv prin
câteva faze. Commented [WU22]: https://en.wikipedia.org/wiki/Water
fall_model

28
Metodologia decurge dintr -un model utilizat inițial în industria de construcții, preluând
din caracteristicile domeniului: unități structurate fizic în care modificările ulterioare sunt foarte
greu de realizat, dacă nu imposibile și extrem de
costisitoare. Datorită faptului că Waterfall a apărut
atunci când nu exista încă un model de urmat în
dezvoltarea software, acesta a fost preluat rapid în
acest domeniu și adaptat.
Prima descriere formală a acestui model
datează din anul 1970, dintr -un articol al lui
Winston W. Royce, deși acesta nu a utilizat cuvântul Waterfall în articolul său.
În modelul sau original, Royce a propus o serie de etape prin care trebuie să treacă un
proiect pentru a se dezvolta sub conceptul Water fall. Acestea sunt:
1. Cerințele soft -ului și cerințele de sistem: această etapă propune o analiză a resurselor
întrebuințate în procesul de dezvoltare și caracteristicile de care se dorește să dispună
produsul final, acestea formând o bază pe care se va cons trui soft -ul. Rezultatul este
reprezentat de obicei sub formă unui document în care se specifică ce se dorește de
la aplicația software, dar nu și modul în care aceasta va îndeplini cerințele respective,
aceasta rămânând la latitudinea echipei de dezvoltar e.
2. Faza de analiză, cea de -a doua etapă a procesului Waterfall, constă în analiză
sistemului conceput în fază inițială, pe baza documentului de cerințe, pentru a genera
modelele de dezvoltare și logică de business ce urmează să fie pusă în practică în
dezv oltarea aplicației .
3. Etapa de design reprezintă momentul în care se lucrează la arhitectură produsului,
cu tot ce implică asta: limbaj de programare, laye re funcționale, servicii, etc ( nu
neapărat design din punct de vedere vizual). În urma acestui proces v or rezulta niște
specificații de început, structurale și specifice, ce exprimă efectiv modul în care vor
fi puse în practică elementele constatate în faza anterioară, cea de analiză.
4. Faza de dezvoltare – codare: reprezintă momentul în care efectiv se începe
dezvoltarea concretă a produsului, implementându -se elementele stabilite în etapa
anterioară, cea de design, și în conformitate cu primele 2 etape: cerințele de sistem
și analiză .

29
5. Etapa de testare este o etapă cheie în procesul fluent de dezvoltare a produsului
software deoarece acesta este evaluat din punct de vedere calitativ și în raport cu
cerințele și specificațiile inițiale. În această fază se descoperă erori de către testerii
de QA și se încearcă rezolvarea lor. De cele mai multe ori această f ază determină
repetarea unora din fazele anterioare, pentru a permite aplicației să evolueze mai
departe fără probleme și în conformitate cu așteptările asupra acesteia.
6. Operațiile: o fază ce include la rândul ei mai multe elemente:
a. Livrarea și instalarea produsului pe platforma clientului sau in altă formă
cerută de acesta în mediul de utilizare;
b. Migrarea datelor, dacă este necesară;
c. Oferirea de suport pe durata de viață a produsului;
d. Asigurarea mentenanței în cazul apariției problemelor cauzate de
funcți onarea defectuasă a aplicației.

2.4 Tipuri de testare :
Principalele tipuri de testare folosite în industrie în zilele noastre sunt următoarele:
1. Black box testing
2. White box testing
3. Unit testing
4. Incremental integration
testing
5. Integration testing
6. Functional testing
7. System testing
8. End-to-end testing
9. Sanity testing
10. Regression testing
11. Acceptance testing 12. Load testing
13. Stress testing
14. Performance testing
15. Usability testing
16. Install/uninstall testing
17. Recovery testing
18. Security testing
19. Compatibility testing
20. Comparison testing
21. Alpha testing
22. Beta testing
Commented [WU23]: http://www.softwaretestin ghelp.co
m/types -of-software -testing/

30
2.4.1 Black box testing
Această metodă de testare analizează o funcționalitate a aplicației fără a intra în structura
internă sau modul de funcționare a acesteia, ci doar la nivel de „suprafață”. Aceasta se mai
numește și „Testarea comportamentului aplicației”. Numele metodei de testare duce cu gândul
la o cutie neagră la care nu se poate vedea conținutul, ci doar exteriorul, aceasta fiind singura
parte a cutiei ce poate fi analizată. Acest mod de testare este conceput pentru a descoperi
următoarele tipuri de erori:
– Funcții greșite sau care lipsesc;
– Erori legate de interfața;
– Erori ce țin de structura bazei de date;
– Erori de comportament sau de performanță.
2.4.2 White box testing
Această metodă este opusul precedentei în sensul în care, de această dată, tester -ul
cunoaște structura, design -ul și modelul de impl ementare a aplicației. Folosind această metodă
se testează diferite seturi de date de intrare pentru a parcurge diferite rute în codul aplicației și a
verifica dacă rezultatele sunt cele așteptate. Numele său sugerează fapul că în ochii tester -ului
aplicaț ia este albă, transparentă și se poate vedea absolut fieare unitate de informație și cod din
interiorul ei.

2.4.3 Unit testing
Unit testing se concentrează pe caracteristicile care sunt esențiale pentru măsurarea
performanței exclusiv a componentei testate. Astfel, programatorii sunt încurajați, folosind
această metodă, să modifice codul din spatele aplicației astfel încât să îmbunătățească la maxim
componenta respectivă, fără a avea în vedere urmările ce ar putea afecta celelalte componente
ale softului sau chiar a aplicației în mod integral. Metoda are avantajul că se poate face foarte
devreme în ciclul de dezvoltare a aplicației și este menită să descopere așa numitele „compound
errors” (erori care la început par inofensive și tind să devină neglijate, însă ulterior, în
combinație cu alte componente dezvoltate în cadrul aplicației, pot deveni severe sau chiar
fatale).
Commented [WU24]: http://softwaretestingfundamentals.
com/black -box-testing/
Commented [WU25]: http://searchsoftwarequality.techtar
get.com/definition/unit -testing

31
2.4.4 Incremental integration testing
Această abordare are avantajul de a detecta erori într -o faza inițială de asamblare, atunci
când este ușor de detectat o astfel de eroare. După fiecare faza de integrare, se realizează o serie
de teste, în momentul iterației respective, după care se trece la următoarea iterație și procesul se
reia. Incremental integration testing se poate realiza în general în trei moduri, depinzând în
principal de arhitectura aplicației:
– Top down: testarea are loc „de sus în jos” urmând linia arhitecturală a aplicației,
pornind de la meniul principal al interfeței;
– Bottom up: testarea are loc „de jos în sus” urmând în sens opus linia arhitecturală a
aplicației, componentele sau sistemele fiind înlocuite de drivere.
– Funcțional incremental: testarea are loc pe baza functionalitilor, în funcție de modul
în care au fost prezentate în documentație, ținând cont de specificațiile acest ora.
2.4.5 Integration testing
Acesta este mai mult un moment decât o modalitate de testeare, și anume momentul în
care componentele dezvoltate separat sunt integrate și testate împreună ca un grup. Integration
testing -ul are loc după ce se realizează unit test ing-ul, și înainte de validation testing. După ce
componentele sunt integrate, se realizează un set de date de testare de imput, după care se
urmărește parcursul acestora prin produsul software și desigur rezultatele. Setul de date de
intrare este conceput sub formă unui „Integration test plan”18.

2.4.6 Functional testing
Este un tip de testare care verifică faptul că fiecare componentă sau funcționalitate a
produsului software funcționează în conformitate cu specificațiile. Această metodă folosește
black box testing și nu se adresează codului sursă al aplicației. Fiecare componentă a aplicației
este testată folosind seturi de date adecvate, după care se compară rezultatele obținute cu cele
așteptate. Această metodă de testare se adresează în special interfeței cu utilizatorul, API –
urilor19, bazelor de date, securității și metodelor ce operează client/server.
Functional testing are în vedere următoarele elemente:
– Funcțiile principale;

18 Plan de testare de integrare
19 Application Programming Interface Commented [WU26]: https://www.guru99.com/functional
-testing.html

32
– Utilizarea de bază;
– Accesibilitatea din punctul de vedere al utilizatorului;
– Modul de raportare a erorilor.

2.4.7 System testing
Acest tip de testare se realizează pe un produs software complet și integrat, pentru a
evalua modul în care acesta respectă cerințele de sistem specifice. Aceasta folosește metoda de
black -box testing în care, cum am menționat și mai sus, nu este necesară cunoașterea
implementării și modului de funcționare al codului. Ca și regulă, System testing are ca input
componentele software care au trecut de etapa de integration testing și care au fost integrate într –
un context hardware compatibil. System testing se rulează pe un sistem întreg, în contextul
cerințelor funcționale și a specificațiilor, și se testează nu doar design -ul ci și comportamentul
produsului software. De obicei se merge chiar și mai departe și se t estează comportamentul
dincolo de limitele normale ale aplicației pentru a se observa comportamentul acesteia și în
astfel de situații excepționale.

2.4.8 End to end testing
End to end testing este o metodologie de testare folosită pentru a verifica faptul c ă un
flow (un traseu funcțional) al aplicației are loc exact așa cum a fost conceput. Rolul acestor teste
este acela de a se asigura dependența sistemului de resursele proprii, mai exact faptul că o
informație sau un set de date corect trece prin component ele potrivite ale produsului software și
acestea sunt prelucrate corect. Testele se realizează într -un mod în care se simulează utilizarea
aplicației în lumea reală de către utilizatori reali și prin modul de comportament al acestora.

2.4.9 Sanity testing
Este o etapă ce are loc în timpul procesului de dezvoltare al unei aplicații software.
Astfel, în momentul în care echipei de testare îi este furnizat un nou build al produsului în cauza
ce conține probleme și bug -uri minore rezolvate, aceasta testează aplicați a asigurându -se că
problemele s -au rezolvat. Scopul principal al unui Sanity test este acela de a se asigura că
rezolvările problemelor sunt corecte și nu afectează alte componente. Totodată se adresează
strict elementelor pe care s -au raportat bug -uri. As tfel, nu este nevoie de o regresie totală a Commented [WU27]: https://www.techopedia.com/definit
ion/7035 /end-to-end-test

33
aplicației și se folosește metoda Sanity testing. Fiind o metodă de testare simplistă și rapidă,
aceasta ajută la evitarea pierderilor de timp și cost în ceea ce privește procesul de testare. De
exemplu, dacă bui ld-ul respectiv este nefuncțional, acest lucru va ieși la iveală foarte rapid prin
Sanity testing și astfel nu se mai testează în continuare datorită erorilor descoperite inițial. În
acest caz, se raportează starea nefuncțională a build -ului și noul build funcțional va sosi mai
rapid.

2.4.10 Regression testing
Acesta este un tip de testare ce verifică dacă aplicația încă funcționează la parametrii
normali și oferă rezultatele cerute sau cele așteptate, după ce au fost implementate noi elemente
sau după ce au fost fixate erori majore. Este o metodă similară Sanity testing, însă mai detaliată
și complexă. Regression testing se realizează de obicei folosind scenarii de testare, clare și
specifice, pentru a urmări și a nota exact comportamentul aplicației. Această met odă este folosită
de asemenea în momentul în care aplicația ajunge la build -uri stabile și se dorește un release al
unei versiuni folosind build -urile respective. În acest moment, pentru a asigura funcționarea
optimă a produsului software, se realizează de obicei un full regression testing .

2.4.11 Acceptance testing
Este un nivel de testare în care se verifică gradul de acceptabilitate al software -ului.
Această metodă de testare are ca scop verificarea faptului că produsul software corespunde
cerințelor client ului, îndeplinește condițiile impuse de acesta și de asemenea dacă produsul este
gata pentru a fi livrat .

2.4.12 Load testing
Este o metodă specială care testează limitele produsului software, în sensul în care se
măsoară răspunsul produsului software în condiți i de folosire suprasolicitante sau neobișnuite.
Această metodă este folosită pentru a descoperi capacitatea de operare maximă a aplicației,
elementele ce îngreunează funcționarea ei în aceste condiții și, de asemenea, descoperirea
componentelor ce suferă c ea mai rapidă degradare.
Commented [WU28]: http://softwaretestingfundamentals.
com/acceptance -testing/

34
2.4.13 Stress testing
Este procesul prin care se determina abilitatea unui produs software de a se menține la
parametrii normali de funcționare în condiții nefavorabile, numite și condiții „de stres”. Metoda
poate folosi testare utilizând cantități foarte mari de date sau seturi de input atipice sau speciale,
măsurând astfel rata erorilor și a momentelor în care aplicația nu mai funcționează.

2.4.14 Performance testing
Performance testing este un tip de testare non -funcțional. Se rea lizează pentru a
determina cât de rapid se mișcă anumite componente ale aplicației în anumite condiții specifice
și pe anumite seturi de date care probabil urmează a fi cel mai intens folosite de către utilizatori.
În urmă performance testingului se asigur ă faptul că produsul software funcționează conform
specificațiilor din punct de vedere al performanței .

2.4.15 Usability testing
Aceasta este o metodă de testare care evaluează aplicația din punctul de vedere al unor
utilizatori reprezentativi. În mod normal, î n timpul unui astfel de ciclu de testare, utilizatorii
încearcă să realizeze task -uri tipice, în timp ce alții observă și notează. Obiectivul este acela de
a identifica probleme de folosire din punctul de vedere al utilizatorilor.

2.4.16 Install/Uninstall testin g
Se face pentru a verifica dacă produsul software a fost instalat corect, cu toate
componentele necesare, și dacă aplicația funcționează conform așteptărilor. Instalarea este un
proces foarte important, deoarece acesta este primul contact al utilizatorilo r cu produsul de care
urmează să beneficieze.
Uninstall testing se realizează pentru a verifica dacă toate componentele sunt înlăturate
de pe platforma în procesul de dezinstalare.

2.4.17 Recovery testing
Această metodă de testare măsoară timpul în care aplicați a își revine după ce a suferit o
cădere sau după ce a încetat să mai funcționeze datorită condițiilor de stres. Această metodă de
testare este o subdiviziune a performance testing -ului. Commented [WU29]: http://searchsoftwarequality.techtar
get.com/definition/stress -testing
Commented [WU30]: http://istqbexamcertification.com/w
hat-is-performance -testing -in-software/

35

2.4.18 Security testing
Este un tip de testare non -funcțională și se realize ază pentru a descoperi gradul de
securitate al aplicației. Se testează dacă produsul este vulnerabil la atacuri și dacă cineva se
poate loga în aplicație fără autorizație. De asemenea, în acest proces se testează gradul de
protecție al datelor cu care lucr ează aplicația .

2.4.19 Compatibility testing
Acesta este de asemenea un tip de testare non -funcțional realizat pe aplicație pentru a
evalua gradul de compatibilitate al aplicației cu diferite medii și platforme.
2.4.20 Comparison testing
Metoda ajută inginerii de testare să înțeleagă puterea, punctele forte și vulnerabilitățile
produsului, în comparație cu altele din aceeași categorie. Această abordare presupune
comparația rezultatelor, a proceselor funcționale și a fișierelor efective ce stau la baza aplicației.

2.4.21 Alpha testing
Alpha testing este una dintre cele mai răspândite strategii de testare folosite în
dezvoltarea software. Se realizează în locul în care s -a realizat și dezvoltarea, inginerii de testare
observând userii folosind aplicația, notând totodată pro bleme și defecțiuni. Această metodologie
de testare se aplică atunci când produsul software este aproape gata pentru lansare, fiind
penultima faza de testare înainte de lansarea produsului pe piață. De obicei Alpha testing constă
chiar în folosirea aplica ției de către potențiali clienți sau utilizatori, în același sediu în care s -a
realizat și dezvoltarea.

2.4.22 Beta testing
Este un proces de testare ce se realizezaza în locația clientului. Se trimite produsul
software către utilizatori în vederea instalării și folosirii acestuia în lumea reală și sub condiții
de funcționare reale. Aceasta este o ultimă fază de testare a produsului, chiar înainte de lansarea
oficială a acestuia .

Commented [WU31]: https://www.tutorialspoint.com/ soft
ware_testing_dictionary/compatibility_testing.htm

36
2.5 Testare manual ă
2.5.1 Descrierea procesului
Testarea manuală este acea metodă prin care un inginer de testare preia rolul unui
utilizator obișnuit și utilizează aplicația în scopul descoperirii defectelor. Adesea se folosește un
document cu scenarii de testare, pe ntru a urmări și ușura procesul .
În testarea manual ă se folosesc urmatoarele teh nici, prezentate deja în capitolul anterior:
– Acceptance testing
– White box testing
– Black box testing
– Unit testing
– System testing
– Integration testing

Fiind o modalitate de testare de bază, testarea manuală se realizează încă de la începutul
ciclului de viaț ă al aplicației, înainte de începerea testării automate.
Se creează un „Test plan”, o structura de prioritizare a elementelor ce urmează a fi testate
și care include și comportamentul acestora, după care se realizează testarea efectivă, folosind
Test plan -ul și cazurile de testare denumite „T est Cases”20.
Principalul obiectiv al testării manuale este acela de a se asigura faptul că aplicația
funcționează în conformitate cu cerințele clientului și că nu are erori sau defecte.
Conceptele testării manuale inclu d și „Exploratory testing”, metodă care presupune că
inginerii de testare să exploreze aplicația într -un mod aleatoriu, neprogramat, pentru a descoperi
erori neașteptate sau neobișnuite.
Pe parcursul procesului de testare, diferențele dintre ceea ce se întâmplă cu adevărat în
aplicație și ce ar trebui de fapt să se întâmple sunt tratate că defecte și sunt raportate. În urma
raportării, defectele ajung la dezvoltatori și sunt fixate de către aceștia. Programatorii trimit
rapoartele înapoi la inginerii de test, urmând ca aceștia să verifice corectitudinea înlăturării
defectelor de către programatori. Dacă erorile sunt eliminate, rapoartele sunt închise și
componenta respectivă este notată ca fiind reparată.

20 Scenarii detaliate de testare ce urmează a fi realizate și executate de către inginerii de testare, fără a folosi unelte
de testare automată, în acest context

37
La nivel schematic, un proces complet de testare u rmează această diagramă :

2.5.2 Platforme utilizate în testarea manual ă – Jira
Una dintre cele mai raspandite platforme utilizate în testarea manual ă, dar și în testarea
automat ă este Jira oferit ă de către Atlassian.
Jira este un produs software conceput pentru gestionarea bug -urilor, a improvement –
urilor și management -ului proiectelor de dezvoltare, utilizate în procesul de testare. Deși este
cunoscut sub numele de JIRA, acesta este de fapt un acronim, numele complet fiind Gojira
(traducerea din limba japoneză de la Godzilla, aceasta fiind o referință la competitorul principal
– Bugzilla).
Proiectul s -a dezvoltat începând cu anul 2002 și, potrivit unui studiu realizat chiar în
2017, Jira este cea mai folosită platform ă pentru managementul cazurilor și bug -urilor din lume .
Commented [A32]: http://toolsqa.com/software –
testing/manual -testing/

38
După spusele celor de la Atlassian, Jira este folosit pentru gestiunea proiectelor de către
peste 75.000 de clienți din 122 de țări de pe glob. Printre organizațiile cu renume mondial ce
folosesc pro dusul de la Atlassian se numără Fedora Commons, Hibernate, Skype Technologies,
Twitter, Nasa, Departamentul american pentru Apărare și Apache Software Foundation. De
asemenea, Jira include unelte care permit migrarea de la competitorul Bugzilla .
Jira poate fi livrat în 3 pachete:
1. Jira Software: soft-ul de baz ă ce include elemente de managemen t ale proiectelor
sub forma Agile ( înainte fiind un produs separat de numit Jira Agile);
2. Jira Core: unealta de management a proiectelor;
3. Jira Service Desk: folosi î n procesele IT de business.

Ca o concluzie, Jira realizeaz ă urmatoarele activit ăți de gestiune:
– Planning ( planificare) : creeaz ă scenarii și cazuri de testare sau implementare,
distribuie task -uri și sarcini;
– Tracking (urmarire, gestiune ) : prioritizeaz ă și manageriaz ă echipa și firul de
execu ție al activit șților cu o vizibilitate completă .
– Release ( livrare) : Asigura lansarea corectă a produsului către client, împreună cu
datele de testare de tip sanity actualizate constant .
– Report ( raportare) : ajută la îmbunătățirea performanței echipei pe baza datelor ce
pot fi vizualizate în timp real .

39

2.6 Testare automat ă
2.6.1 Descriere a procesului
Testarea automată presupune utilizarea unui produs software dedicat (separat de
produsul care trebuie testat) ce controlează execuția testelor pe aplicație și compararea
rezultatelor obținute cu rezultatele așteptate.
Procesul de testare automată poate, de asemenea, să automatizeze execuția unor sarcini
repetitive dar necesare în procesul de testare, în mod formal, sau să realiz eze elemente de testare
ce ar fi greu de realizat în formă manuală de către inginerii de t estare manuală .

2.6.2 Importan ța test ării automate
Testarea aut omat ă este extrem de important ă datorit ă următoarelor motive:
– Testarea manuală a tuturor aspectelor ce țin d e produsul software în curs de
dezv oltare consumă foarte mult timp ;
– Testarea automată nu necesită intervenția umană (testele automate se pot rula
independent, de exemplu în timpul nopții).
– Automatizarea cre ște viteza de executie a testelor;
– Automatizarea a jută la acoperirea mai eficient ă a aplica ției (Test coverage);
– Testarea manual ă poate deveni plictisitoare, gener ând astfel erori umane;

De fiecare dată când este modificat codul sursă al aplicației ar trebui în mod normal să
se scrie și să se execute sce narii de testare pentru modificările respective sau pentru
componentele care beneficiază de acele modificări.
Pentru fiecare versiune a produsului software ce se lansează pe piață se realizează în
mod normal teste pe toate sistemele de operare suportate și pe configurațiile hardware peste care
urmează să ruleze aplicația. Testarea manuală repetată a acestor elemente necesită resurse
materiale mari și consumă timp. De aceea testele automate pot fi create și configurate o singură
dată și rulate în mod repetat , fără a necesită resurse suplimentare, rulând de asemenea și mai
rapid.
Până și cel mai experimentat inginer de testare poate face greșeli în timpul procesului de
testare manuală monotonă. De partea cealaltă, testele automate realizează aceleași etape și

40

scenarii de testare cu precizie identică de fiecare dată, reținând și raportând în același timp și
rezultate detaliate. Testerii pot folosi timpul economisit datorită utilizării testării automate
pentru a repara sau îmbunătăți scenariile de testare automat ă, sau pot realiza altele noi, în funcție
de cerințe și disponibilitate .

41
3 CAPITOLUL 3 – Aplica ția dezvoltat ă: uSON Dashboard

3.1 Platforme folosit e pentru dezvoltare:

3.1.1 Intelli J IDEA Ultimate
IntelliJ IDEA este un mediu de programare în Java dezvoltat de către JetBrains care este
disponibil sub o licență community de la Apache 2 sau o licență comercială, ambele putând fi
folosite pentru uz comercial.
Prima versiune de IntelliJ a avut lansarea în Ianuarie 2001, una dintre pr imele IDE -uri
Java21 cu navigare avansată a codului și cu modele de sugestie.
În Decembrie 2014, Google a anunțat versiunea 1.0 a Android Studio, un IDE de tip
open source pentru aplicații Android, bazat pe comunitatea open source a IntelliJ IDEA. Alte
medii de dezvoltare bazate pe framework -ul IntelliJ includ AppCode, Clion, PhpStorm,
PuCharm, RubyMine, WebStorm și MPS .
Ultima versiune de release stabila a IntelliJIdea este pe piata din data de 18 Iulie 2017 l.

21 Integrated Development Environment
Commented [A33]: https://en.wikipedia.org/wiki/IntelliJ_
IDEA

42
Cerin țele de sistem pentru IntelliJ IDEA sunt urmatoarele:
1. Sistem de operare: Microsoft Windows 10/8/7 x64, OS X 10.8 sau mai recent, Linux
GNOME sau KDE Desktop ;
2. Memorie RAM: Minimum 1GB; 4GB sau mai mult pentru dezvoltarea pe Android
sau produc ție comercial ă;
3. Spațiu: 300 de mb și încă 1GB pent ru elemente cache generate;
4. Versiune JDK : 1.8 2016.1 sau mai recent ;
5. Rezolu ție a ecranului: 1024×768 cel putin.

IntelliJ IDEA oferă diferite facilități precum asistență la scrierea codului prin
completare automată pe baza analizei contextului. De asemenea se poate naviga prin cod de la
o clasa la alta în mod direct și se pot corecta automat erorile prin sugestii oferite de către
platformă.
Platforma oferă soluții de integrare a pachetelor exterioare precum Grunt, Bower, Gradle
și SBT. Ea suportă sisteme de control ale versiunilor precum GIT, Mercurial, Perforce sau SVN
și baze de date precum Microsoft SQL Server, Oracle, Postgre SQL sau MySql.
Se pot de asemenea instala diferite plugin -uri prin care pot fi adăugate noi funcționalități.
Este posibilă descărcarea și instalarea acestora fie din baza de plugin -uri de la IntelliJ, fie prin
componenta de căutare a plugin -urilor de la IntelliJ. La momentul actual, ediția Community a
IntelliJ IDEA pune la dispoziție 1495 de plugin -uri iar versiunea Ultimate are 1626 de astfel de
îmbunătățiri .

3.2 Tehnologii folosite pentru dezvoltare :
3.2.1 jQuery
jQuery este o librărie de JavaScript rapid ă și care conține o gamă vastă de elemente și
proprietăți care ajută la dezvoltarea aplicațiilor web HTML22. De asemenea, jQuery merge pe
principiul de a scrie mai puțin cod pentru a realiza mai multe funcționalități, fapt ce ușurează
dezvoltarea soluțiilor software. Analiza aplicațiilor web arată că jQuery este de departe cea mai
răspândită și folosită librărie JavaScript datorită car acteristicilor descrise mai sus .

22 Hyper Text Markup Language Commented [A34]: https://en.wikipedia.org/wiki/JQuery

43

Principalele functionalit ăți simplificate de c ătre tehnologia jQuery sunt urmatoarele :
1. DOM reprezintă modul în care JavaScript vede datele din paginile web, iar jQuery
ușurează selecția și utilizarea elementelor de tip DOM folosind un motor ce acționează
în mod cross -browser ce lucrează pe browsere, denumit Sizzle .
2. Event Handling – jQuery o feră un mod elegant de a captura numeroase acțiuni și
elemente precum click -ul realizat de un user pe un link fără a folosi event handlers
(manager de evenimente).
3. Ajax Support – jQuery suportă tehnologia Ajax: set de tehnici web folosite pentru a crea
aplicații web asincrone. Cu Ajax aplicațiile pot trimite și primi date de la server în mod
asincron fără a interfera cu modul în care se comportă pagină curentă.
4. Animation – jQuery vine cu o mulțime de efecte de animație încorporate ce se pot folosi
pentru aplicația web dezvoltată.
5. Lightweight (categorie ușoară) – fiind o librărie din categoria ușoară, aceasta ocupă doar
19 kb.
6. Cross Browser Support – jQuery este suportat pe foarte multe soft -uri de tip browser
precum Internet Explorer 6.0 +, Mozil la Firefox +, Safari 3.0 +, Google Chrome +,
Opera 9.0 +.
7. Tehnologii de ultimă oră – jQuery încorporează selectori CSS 3 și sintaxa basic de tip
Xpath.
Exist ă două versiuni de jQuery actuale disponibile pentru desc ărcare:
Commented [A35]: https://www.tutorialspoint.com/jquery
/jquery -overview.htm

44
– Product version – aceasta este folosita pentru produsele web care sunt pe pia ță si sunt
utilizate în prezent ;
– Development version: versiune folosit ă pentru dezvoltare și testare;

jQuery se poate folosi în dou ă moduri:
– Se descarc ă libraria jQyery de pe site -ul oficial jQuery.com dup ă care se include în
proiectul folosit astfel:
<head>
<script src="jquery -3.2.1.min.js">< /script>
</head>

– Se poate include libr ăria direct din CDN (Content Delivery Network) astfel:
De la Google:
<head>
<scriptsrc="https://ajax.googleapis.com/ajax/libs/jquery/3.2
.1/jquery.min.js">< /script>
</head>

De la Microsoft:
<head>
<script src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery –
3.2.1.min.js">< /script>
</head>

3.2.2 Underscore .js
Aceast a este o librărie JavaScript care oferă o mulțime de funcționalități ajutătoare în
programarea web fără a extinde obiectele încorporate în aplicație. Elementele acesteia sunt
comparabile cu cele oferite de către Prototype.js și limbajul Ruby, dar optează pe ntru
programarea&nbsp;funcțională în detrimentul extinderii obiectelor prototip. . Commented [A36]: http://underscorejs.org/

45
Underscore.js a apărut pentru prima dată în anul 2009 avându -l că fondator pe Jeremy
Ashkenas însă de curând tehnologia a fost cumpărată de către Lodash, care a atras și
dezvoltatorii către aceasta, părăsind Underscore.js .
Underscore.js ofer ă peste 100 de func ții care se impart în 4 categorii:
– Func ții pentru manipularea datelor de tip array;
– Func ții pentru manipularea obiectelor ;
– Func ții pentru manipularea at ât a obiectelor de tip array c ât și a celor de tip obiect
(colec ție);
– Func ții pentru manipularea altor func ții.

De asemenea exist ă și dou ă categorii de utilit ăti:
– Utility
– Chaining

Ca și în cazul jQuery, și Underscore.js pune la dispozi ție dou ă versiuni dup ă cum
urmeaz ă:
– Development version 1.8.3, versiune pentru dezvoltare și testare;
– Product version 1.8.3 minimizată și compresat ă;

3.2.3 Sheetjs js -xlsx
Acesta se utilizează la scrierea și parsarea numeroaselor formate de tip spreadsheet.
Sheetjs pune accentul pe scrierea î ntr-un mod robust pe formate multiple compatibile, unificate
într-o reprezentare JavaScript c ompatibilă cu ultimele browsere .
Commented [A37]: https://docs.sheetjs.com/#sheetjs -js-
xlsx

46
Înainte de existența Sheetjs, API-urile folosite pentru procesarea fișierelor erau specifice
pentru fiecare format. Librăriile suportau fie un singur format, fie includeau un set separat de
clase pentru fiecare tip de fișier suportat. Deși XLSB23 a fost introdus abea în 2007, nimic în
afară de Sheetjs și Microsoft Excel nu suportă acest format .

Pentru a promova un view pentru un format generalizat, js -xlsx începe de la o
reprezentare pură JavaScript denumită „Coomon Spreadsheet Format”. Dezvoltarea unui obiect
uniform oferă noi funcționalități precum conversia formtatelor (de exemplu citirea unui fișier
template de tip xlsx și salvarea acestuia sub extensia xls).
Iată o schem ă în care sunt dispuse formatele cu care poate lucra Sheetjs:

23 Fișiere cu extensia .xls de tip binar

47
O reprezentare simplă a obiectelor combinată cu practici specifice de scriere a codului
permite utilizarea a plicațiilor în browsere vechi și în medii alternative precum ExtendScript și
Web Workers. Întotdeauna a fost tentantă folosirea celor mai performante și de ultima oră
funcționalități însă acestea tind să necesite ultimele versiuni ale browserelor, limitân d astfel
numărul de utilizatori .
Microsoft Excel împinge formatul xlsx să devină cel prestabilit și de bază începând cu
Excel 2007. Mai există și alte formate cu proprietăți interesante și atractive. De exemplu
formatul XLSB este aproape identic cu XLSX în să fișierele tind să ocupe cam jumătate din
spațiul ocupat de acestea din urmă și se deschid mult mai r epede .
Sheetjs este disponibil în dou ă versiuni:
– Versiunea community ;
– Versiunea Pro – cu performan țe sporite și functionalit ăți adiționale la cerere și suport
dedicat.

3.2.4 Chart. js
Este o librărie JavaScript utilizată pentru crearea graficelor animate și interactive pentru
pagini web. Aceasta suportă HTML5 și poate realiza grafice de tip Line, Bar, Radar, Polar Area,
Pie și Doughnut charts, oferind și po sibilitatea de a extinde aceste tipuri de grafice și de a realiza
chiar altere personalizate .

Commented [A38]: https://cdnjs.com/libraries/Chart.js

48
Ultima versiune de Chart.js se poate instala folosind NPM24 sau Bower25 astfel:
1. Folosind NPM: npm install chartjs –save
2. Folosind Bower: bower install chart.js –save
Chart.js pune la dispoziție multiple componente ce pot fi configurate după bunul
plac și care pot fi folosite oriunde în aplicația web dezvoltată: culori, fonturi, interacțiunea cu
utilizatorul prin acțiuni de hover ale cursorului și alte opțiuni ce se aplică tuturor tipurilor de
grafice.
La dispoziția dezvoltatorilor este pusă și o versiune extinsă, cu mai multe
funcționalități și opțiuni, realizându -se astfel aplicații web cu un grad mai mare de complexitate.
Chart.js oferă suport pentru toate br owserele care suportă Canvas26
Chart.js este o librărie de tip Open Source disponibilă sub licență MIT .

24 Node Package Manager
25 Package manager
26 Element din HTML5 care permite utilizarea formelor 2D dinamice și a imaginilor de tip Bitmap

49
Bibliografie

[1] https://en.wikipedia.org/wiki/Business_intelligence#History
[2] https://en.wikipedia.org/wiki/Business_information
[3] https://www.betterbuys.com/bi/history -of-business -intelligence/
[4] http://www.pyramidanalytics.com/pages/blog/2016/02/brief -history -busin ess-
intelligence.aspx
[5] http://www.investopedia.com/ask/answers/033015/what -are-historical -origins -business –
intelligence.asp
[6] https://www.betterbuys.com/bi/history -of-business -intelligence/
[7] http://searchbusinessanalytics.techtarget.com/feature/Understanding -BI-analytics -tools –
and-their-benefits
[8] http://www.blog -geographica.com/2016/11/15/how -data-mining -is-used-to-generate –
business -intelligence/
[9] https://support.office.com/en -us/article/Overview -of-Online -Analytical -Processing -OLAP –
15d2cdde -f70b-4277 -b009 -ed732b75fdd6
[10] https://en.wikipedia.org/wiki/Business_process_ree ngineering
[11] https://www.logianalytics.com/resources/bi -encyclopedia/benchmarking/
[12] https://www.techopedia.com/definition/30217/business -intelligence -reporting -bi-
reporting
[13] http://www.pcmag.com/article2/0,2817,2491954,00.asp
[14] https://powerbi.microsoft.com/en -us/what -is-power -bi/
[15] http://en.dwhwiki.info/charting/dashboard/tableau
[16] https://en.wikipedia.org/wiki/Google_Analytics
[17] https://en.wikipedia.org/wiki/Software_testing
[18] https://en.wikipedia.org/wiki/Debugging
[19] https://saucelabs.com/blog/quality -assurance -and-software -testing -a-brief -history
[20] https://www.inflectra.com/ideas/topic/testing -methodologies.aspx
[21] https://en.wikipedia.org/wiki/Agile_software_ development
[22] https://en.wikipedia.org/wiki/Scrum_(software_development)
[23] https://en.wikipedia.org/wiki/Waterfal l_model

50
[24] http://www.softwaretestinghelp.com/types -of-software -testing/
[25] http://softwaretestingfu ndamentals.com/black -box-testing/
[26] http://searchsoftwarequality.techtarget.com/definition/unit -testing
[27] https://www.guru99.com/functional -testing.html
[28] https://www.techopedia.com/definition/7035/end -to-end-test
[29] http://softwaretestingfundamentals.com/acceptance -testing/
[30] http://searchsoftwarequality.techta rget.com/definition/stress -testing
[31] http://istqbexamcertification.com/what -is-performance -testing -in-software/
[32] https://www.tutorialspoint.com/software_testing_dictionary/compatibility_testing.htm
[33] http://toolsqa.com/software -testing/manual -testing/
[34] https://en.wikipedia.org/wiki/IntelliJ_IDEA
[35] https://en.wikipedia.org/wiki/JQuery
[36] https://www.tutorialspoint.com/jquery/jquery -overview.htm
[37] http://underscorejs.org/
[38] https://docs.sheetjs.com/#sheetjs -js-xlsx
[39] https://cdnjs.com/libraries/Chart.js