INTRODUCERE

Mediul online a beneficiat de o creștere impresionantă a popularității în ultimii ani,

făcându-și loc din ce în ce mai mult în viața de zi cu zi, cu sau fără voia noastră. Dezvoltarea
mediului online, a tehnologiei şi a aplicaţiilor a schimbat fundamental comportamentul
consumatorilor şi în acelaşi timp strategia de marketing a brandurilor. Astfel, producătorii de
software trebuie să se adapteze cerințelor și exigențelor consumatorilor. Consumatorii au nevoie
de diferite echipamente hardware și software pentru a ține pasul cu tehnologia deci este necesar
ca firmele din domeniul IT să fie capabile să țină pasul și să se dezvolte în mod continuu, având
bineînțeles în atenție aspectul calității.
În prezent, companiile din domeniul IT au mai multe alternative pentru monitorizarea și
controlul calității. Tocmai de aceea, în lucrarea intitulată „Metode și tehnici de lucru pentru
monitorizarea și controlul calității în cadrul firmelor producătoare de software” am ales să
prezint aceste alternative.
Lucrarea de față este structurată în trei capitole. Primul capitol, denumit „Metode și
tehnici de monitorizare a calității ” prezentă două dintre cele mai utilizate metode de lucru,
Agile (metoda iterativă) și Waterfall (metoda incrementală).
În cel de-al doilea capitol, denumit „Controlul calității” am ales să valorific importanța
etapei de testare din cadrul procesului de producție ce are loc în domeniul IT. Astfel, am
prezentat rolul testării și impactul pe care il poate avea în calitatea produsului. În plus, am
prezentat nivelurile de testare și tehnicile de testare ce pot fi folosite pentru controlul calității.
Cel de-al treilea capitol, denumit „Cercetare privind metodele și tehnicile de lucru pentru
monitorizarea și controlul calității” conține patru subcapitole în cadrul cărora am integrat o
cercetare exploratorie ce a fost realizată pe un esantion de 70 de persoane. Intrumentul de
recomltare a informațiilor a fost un chestionar de 16 întrebări adresate angajaților din domeniul
IT. În final am prezentat câteva propuneri obiective de îmbunătățiere a metodelor și tehnicilor de
lucru din domeniul producției de software, propuneri bazate pe rezultatele studiului și pe surse
specializate.

1
 CAPITOLUL 1
METODE ȘI TEHNICI DE MONITORIZARE A CALITȚII

În cadrul companiilor producătoare de software, multe echipe adoptă diverse

metodologii în scopul de a îi ajuta să creeze și să livreze un soft cât mai bun și cât mai apropiat
de cerințele clientului. Unii clienți, mai ales Instituțiile Guvernamentale sau clienții de pe piețe
internaționale, pot cere acestor companii să se ghideze după căile certificărilor ISO. Alte
companii pot selecta metodologii bazate pe anumite beneficii pe care le pot aduce, sau bazate pe
anumite trenduri din piață, care să le garanteze cât mai mulți clienți.
Organizația Internațională de Standardizare concepe diverse standarde la care
organizațiile pot alege să se alinieze. Certificarea unei organizații la unul dintre standarde poate
însemna un număr mai mare de clienți sau capabilitatea de a vinde anumitor Instituții
Guvernamentale sau anumitor entități internaționale.
Standardul ISO 9001 nu a fost scris inițial pentru companiile producătoare de software,
standardul 9000-3 a fost scris pentru a învăța acest tip de companii cum să aplice acest standard.
Standardele ISO sunt bogate în definiții, cerințe, resurse și proceduri ce vin în ajutorul
companiilor pentru a își îmbunătăți și rafina procesele și în final proiectele.
Orice metodologie reprezintă o colecție de cele mai bune practici formulate intr-o
imagine coerentă. Însă nu este obligatoriu ca oricare dintre cele mai bune practici să funcționeze
pentru fiecare echipă, proiect sau aplicație. Metodologiile sunt practici care au dat rezultate bune
pentru cineva în trecut. 1
Metodologia de lucru din cadrul unei companii poate fi una formală sau informală. Cel
mai important aspect este ca toate procesele din metodologia folosită să fie foarte clar
comunicate către toate persoanele implicate în activitate.

1.1 Metoda de lucru Agile

Metodolgia Agile descrie un set de principii și practici în scopul livrării produselor de tip
software. Ceea ce descriem noi ca fiind agile în prezent a apărut în urmă cu mult timp, mai precis
în urmă cu cateva decenii. Departamenul de Apărare al Statelor Unite împreună cu NASA au
început să utilizeze dezolvatea iterativă și incrementală încă din anii 1950 sau IID. IID se baza pe
construcția unui sistem caracterizat de executarea mai multor iterații într-o singură secventă,

1
Ash, L., (2003). The web testing companion, Editura Wiley Publishing, Inc, pag 324
2
fiecare iterație conținând lansarea unor noi funcționalități. IID este o metdă extrem de flexibilă,
deoarece multe decizii pot fi luate chaiar în timpul dezvoltării.
În 1960 Evolutionary project management recomandă dezvoltarea în iterații care se întind
pe una sau două săptămâni, în scopul de a livra părți din produs la finalul fiecărei iterații. Ideea
de livrare parțială mai devreme se face pentru a îmbunatăți proiectul la nivel de ansamblu,
deoarece livrând parțial și mai devreme, și feedback-ul vine mai devreme iar acest lucru ajută
echipa să își îmbunătățească tehnica, modul de lucru și cel mai important, să livreze părți din
proiect din ce în ce mai apropiate de ceea ce își dorește clienul. Explicând și aplicând acest
concept, Evolutionary project management demonstreaza că dezvoltarea incrementală, iteratvă,
care generează feedback din partea clientului pe parcurs sunt elemente ale dezvoltării de
software Agile.
Deși metda de lucru Agile a luat naștere din anii 50, abia recent, în ulimii ani una din
șapte companii producătoare de software au început să aplice practicile Agile. Pentru a înțelege
mai din conceptul Agile, să ne imaginăm „abordarea rugby”: în „abordarea rugby” membrii
echipelor dedicate, organizați singuri, lucrează împreună pentru obținerea mingiei în joc, în
scopul de a înscrie un gol pentru echipă.
Agile este o metodologie utilizată de marii producători de pe piața IT: Oracle, IBM,
Microsoft, și nu numai. Din ce în ce mai multe companii adoptă această metodă de lucru de la un
an la altul, evident – metodă adaptată în funcție de nevoile lor. Conform studiilor efectuate de
către specialiști, rata de ducces este următoarea:
- Proiectele Ad-hoc au o rată de success de 49%, 37% sunt contestate iar 14% sunt un
adevărat eșec
- Proiectele iterative, agile au o rată de success de 61%, 28% sunt contestate si doar
11% sunt considerate ca fiind eșuate

Agile înseamnă echipe formate dintr-un număr mic de membri, care lucrează pentru un
scop comun, care colaborează și au ca scop livrarea frecventă, incrementală a unor funcții noi din
cadrul unei aplicații, priotitizare în funcție de diverși factori (nevoie, timp, resurse financiare,
resurse umane). Dezvoltarea iterativă se face în conformitate cu viziunea utilizatorului final și
bazându-se pe feedback-ul clientului. În metodologia Agile scopul princilpal este de a produce
un soft valoros, care să merite efortul.
În cadrul firmelor producătoare de software, managerii de proiect, cei care ghidează și
urmăresc întreaga activitate a proiectelor, se luptă cu trei factori importanți:
- Să livreze la timp, fără întârzieri
- Echipa să își descfățoare activitatea bazându-se pe niște costuri minime
3
 - În final, scopul proiectului să fie atins, toate cerințele să fie acoperite
Alte constrângeri ale managerilor de proiect sunt satisfacerea clientului, eventualele
riscuri și calitatea produsului care urmează a fi livrat.
Metodologia Agile ascunde sub umbrela sa mai multe practici, în ideea de a veni în
sprijinul mai multor tipuri de proiecte, în funcție de nevoile echipei în raport cu activitatea în
sine pe care ar trebui să o desfășoare, și bineînțeles, în raport cu nevoile clientului:
- Scrum
- XP (Extreme Programming)
- The Crystal Family
- Kanban2

Principii:
1. Cea mai mare prioritate este satisfacerea clientului prin din timp și continuă a unui
software valoros.
2. „Îmbrașișați” schimbarea cerințelor, chiar dacă sunteți într-o fază avansată a
dezvoltării. Procesul Agile valorifică schimbarile în scopul avantajului competitiv al
clientului.
3. Livrează părți din softul la care lucrezi cu o frecventă de câteva săptămni, chiar și de
câteva luni, de preferat la o scală de timp cât mai redusă.
4. Analiștii și dezvoltatorii trebuie să lucreze îmrepuna, zilnic, până la finalul
proiectului.
5. Construiește-ți proiectul înconjurat de oameni motivați. Ofera-le un mediu de lucru
plăcut și suportul necesar, și oferă-le încrederea ta că vor termina la timp și vor face o
treabă excelentă.
6. Cel mai eficient mod de a transmite informații și de a dezbate anumite subiecte este
printr-o conversație față în față.
7. Softul la care lucrezi reprezintă măsura progresului.
8. Procesul Agile promovează o dezvoltare sustenabilă.
9. Investitorii, dezvoltatorii și utilizatorii trebuie să se afle în armonie.
10. Atenția continuă asupra unei tehnici excelente și asupra unui design bun crește
agilitatea
11. Simplitatea reprezintă arta maximizarii volumului de muncă nefăcut – este esențială.

2
Goodpasture, J., 2016. Project Management the Agile Way, Editura J.Ross pag 17
4
 12. Cea mai bună arhitectură, cele mai bune cerințe și cel mai bun design reies din munca
echipelor auto-organizate.3
13. La intervale de timp regulate, echipa reflectă împreună asupra conceptului de cu să
devina mai buni, mai eficienți, apoi membrii echipei iau măsuri în concecință, de
comun acord. 4

Lucrul in echipa (membri, roluri)

Metodele de lucru agile susțin echipele care se auto-organizează, a căror activitate nu este
planifică și controloată de către un lider. În cadrul echipelor de scrum managerul sau team
leaderul nu se implică deloc în asignarea rolurilor sau a task-urilor. El doar monitoizează detașat
activitatea echipei.
Membri:
- Product owner (analist)
- Scrum master
- Echipa

Product owner-ul (sau analistul) se ocupă de prioritizarea activităților, el decide care

sunt prioritățile, identifică acele activități care vor aduce o valoare cât mai mare proiectului
(aplicând principiul lui Pareto). El este cel care reprezintă interesele clientului, decide direcția
către care trebuie să se îndrepte echipa (însă nu decide modul în care va ajunge la destinație sau
cu ce viteza se va întâmpla acest lucru) și definește scopul ți își prezintă viziunea asupra pașilor
următori ai proiectului.

Scrum master-ul este acea persoană responsabilă ca Scrum să fie înțeles și adoptat
corect în cadrul echipei. Scrum Master-ul face acest lucru asigurându-se că Echipa Scrum aderă
la teoria, practicile și rolurile Scrum.Scrum Master-ul este un servitor-conducător (servant-
leader) pentru Echipa Scrum. Scrum Master-ul îi ajută pe cei din afara Echipei Scrum să
înțeleagă care din interacțiunile lor cu Echipa Scrum sunt folositoare și care nu. Scrum Master-ul
ajută pe toată lumea să schimbe aceste interacțiuni astfel încât să maximizeze valoarea creată de
Echipa Scrum.5 El decide care este cea mai potrivită persoană pentru o anumită activitate din
cadrul echipei.
3

4
Larman, C. , (2003). Agile and Iterative Development: A Manager's Guide, Editura Addison Wesley, pag. 10
5
Fătulescu, C., (2014). Ce înseamnă să fii Scrum Master? Care sunt responsabilitățile și abilitățile necesare
îndeplinirii cu succes a unui astfel de rol?, [online]. Disponibil la http://www.cornel.fatulescu.ro/educatieit/ce-
inseamna-sa-fii-scrum-master-care-sunt-responsabilitatile-si-abilitatile-necesare-indeplinirii-cu-succes-a-unui-astfel-
de-rol_2.html [Accesat 8 Apr. 2017].
5
 Echipa este formată din două categorii de persoane:
- Persoane care ajută la construirea sau la managerierea proiectului, de exemplu: testeri,
programatori, product owner, scrum master.
- Persoane care au interes cu privire la proiectul în lucru dar care nu au niciun fel de
responsabilitate în cadrul lui, de exemplu: utilizatorii finali, clientul, managerii.
Echipa trebuie să aibă în structura sa persoane cu toate calitățile tehnice necesare relizării
proiectului. Membri echipei trebuie să aibă o comunicare bună, de preferat să lucreze în același
birou, să fie entuziaști și să aibă spirit de echipă
Pentru a înțelegere cât mai bună a modului de lucru am ales să exemplific organizarea și
modul de lucru în cadrul practicii Scrum din metodologia Agile. Să ne imaginăm următorul
scenariu: în cadrul unei firme producătoare de software sunt angajate numeroase persoane, pe
diferite poziții:
- 5 analiști și un team leader
- 30 de programatori și un team leader
- 6 testeri și un team leader
- 1 manager de proiect
Deși angajații fac parte din cate o echipă (echipa de analiză, echipa de
programare/dezvoltare, echipa de testare) și au diverse activități în cadrul acestor echipe, ei sunt
implicați și in câte o echipă agilă, astfel:
- un analist care va fi o punte între ceea ce își dorește clientul și ceea ce urmează a fi
dezvoltat
- 4 sau 5 dezvoltatori, în funcție de necesități
- 1 sau 2 testeri, în funcție de necesități
- 1 manager de proiect care va avea întotdeauna p privire de ansablu asupra tuturor
proiectelor
- 1 scrum master

1.2Waterfall vs. Agile: identificarea erorilor și implicarea clientului

Metodologia tradițională utilizată de către managerii de proiecte în cadrul firmelor
producătoare de software este metoda cascadă sau waterfall. Această metodă are la bază
planificarea timpurie a unui proiect și dezvoltarea lui fără a schimba ideea inițială și cerințele.
Această metodă poartă această denumire (waterfall) deoarece fazele proiectului se întâmplă în
cascadă, astfel:

6
 - În prima fază sunt structurate cerințele clientului, adaptate la condițiile de lucru și la
resursele avute la dispoziție
- În a doua fază se formulează specificațiile tehnice ale proiectului
- În a treia fază se concepe design-ul aplicației
- În ultima fază se face implementarea în conformitate cu cerințele survenite din fazele
anterioare

Figura 1.1 – Fazele dezvoltării waterfall

Sursa: Scanlon, E., (2011). Breaking the Addiction to Process. Editura IT Governance, pag. 15

Odată finalizată una dintre faze, se face trecere către faza următoare, fără posibilitatea de
a reveni la oricare dintre fazele precedente.
Unul dintre termenii care sunt total excluși din această metodologie este flexibilitatea.
Din cauza faptului că pe parcursul proiectului nu sunt permise modificări și abateri de la planul
inițial, poate genera probleme grave pe parcurs, sau chiar în finalul proiectului. În astfel de
proiecte gigant, dezvoltate în cascadă există riscul ca în final să se ajungă la concluzia că
proiectul rezultat nu este ceea ce și-ar fi dorit clientul, iar acest lucru este cauzat de comunicarea
aproape inexistentă dintre client, echipa de producție și utilizatorul final între faza de planificare
și faza de livrare.
Cel mai mare dezavantaj al acestei practici este faptul ca feedback-ul, de regulă era
colectat de la client foarte târziu, abia în faza de acceptanță a proiectului (adică în faza de pre-
release) sau chiar după faza de release, după ce proiectul are să ajungă în producție și să fie
utilizat de utilizatorii finali. Astfel, în cazul în care în etapa de stabilire a design-ului sau în faza
de dezvoltare vor apărea ceva probleme, clientul poate să le sesiseze și să își exprime
nemulțumirile abia după faza de release. În cazul în care anumite modificări ar fi trebuit realizate
(spre exemplu s-a descoperit o lipsă de funcționalitate, neidentificată în faza de planificare, și se

7
dorește implementarea acesteia) pot avea un impact major asupra proiectului. Impactul se poate
reflecta în două sfere:
- În preț, deoarece orice modificare efectuată atât de târziu va presupune în primul rând
timp cheltuit. Este posibil ca în faza post release membrii echpei să fie deja focusați pe un
alt proiect, și este destul de dificil să se defocuseze de la munca actuală și să își
amintească proiectul precedent. Acest lucru ar însemna și o abatere serioasă de la planul
initial.
- În calitatea proiectului. Dacă se adaugă funcționalități noi într-o fază atât de înaintată a
proiectului, este posibil ca aceste modificări să impacteze mult mai multe zone la care
membrii echipei nu se pot gândi și pot genera erori sau defecte ale aplicației.

În metoda de lucru Agile se păstrează toate etapele din metoda de lucru tradițională, însă
se urmărește dezvoltarea în iterații. Astfel, release-ul (adică punerea în producție) se va face
după mai multe iterații.

Figura 1.2 – Fazele dezvoltării Agile

Sursa: Olaru, M., (2012). Agile - Scrum for Teams, [online]. Disponibil la www.pmaccess.ro
[Accesat 2 Mar. 2017].

O iterație poartă denumirea de sprint. Fiecare sprint conține o fază de planificare, în care
sunt stabilite niște obiective pe termen ceva mai scurt spre deosebire de planificarea din
metodologia tradițională, se stabilește design-ul doar pentru o parte din aplicație ce urmează a fi
dezvoltată și testată. Avantajul major în această metodologie este acela că, eventualele probleme
ce vor fi identificate vor fi „prinse” din timp de către echipa de testare sau chiar de către client și

8
sunt rezolvate fie în iterația curentă, fie într-o iterație următoare, în faza de release ajungându-se
cu o versiune a aplicației cât mai apropiată de ceea ce și-a dorit clientul.
Momentul în care sunt identificate erorile și/sau defectele este cel mai important: cu cât
trece mai mult timp de la apariția unei erori sau a unui defect până la descoperirea, raportarea,
resolvarea si testarea acestuia, cu atât costurile pot crește și problemele create vor afecta și mai
mult comportamentul aplicației. Acest lucru va crește totodată timpul de lucru, evetual numărul
membrilor echipei și va genera conflicte între producător și client. Atâta timp cât clientului i se
vor livra mai puține funcționalități de aplicație însă vor fi mai dese, această practică va genera
feedback progresiv, aducând un aport major pentru întregul proiect.
În ultimii ani din ce în ce mai multe companii producătoare de software încep să
îmbrățișeze metodologia Agile, în detrimentul metodologiei Waterfall din cauza faptului că
medoda cascadă nu aduce un mare succes.

1.3 Tehnici de monitorizare a calității

Estimarea sarcinilor este cheia către succesul proiectului. Este esențial ca membrii
echipei să dețină capabilitatea de a estima obiectiv sarcinile care vor intra în sprint și să poată să
aproximeze volumul de sarcini pe care îl pot livra în finalul sprintului.
În metodele de lucru tradiționale, de regulă estimările se face pe baza a cum ar trebui să
decurgă lucrurile în cazurile ideale, însă întotdeauna vor apărea variabile din cauza cărora nu se
vor putea garanta estimările inițiale.
Echipele agile văd lucrul la proiect ca pe o misiune a întregii echipe. Ei se gândesc la
efortul cumulat de care este nevoie pentru a finaliza sarcinile și la complexitatea și suma
concentrării susținute necesare pentru finalizarea sarcinilor din echipă. 6 De exemplu, poate să
dureze o oră pentru a schimba o anvelopă și o oră pentru a reîncărca cutia de siguranțe din
subsol, însă există o diferență majoră înre complexitatea si dificultatea celor două sarcini.
Dificultatea în a reîncărca cutia de siguranțe și a o testa este mult mai mare decât dificultatea
schimbării unei anvelope si a testării ei.
Pentru că echipa se comite că va termina sarcinile ca o entitate comună, este evident că
vor căuta o cale să evidențieze relația dintre sarcini si dificultatea lor.

Story point
Reprezintă un număr care indică mărimea relativă a unei unități de lucru raportată la o
referință mică. Story point-urile reprezintă o unitate de măsură foarte utilă pe termen lung.

6
Barbee, D., 2013. Agile Practices for Waterfall Projects, Editura J.Ross pag 107
9
Reprezintă probabil cea mai utilizată unitate de măsură din cadrul proiectelor agile. Estimarea în
story points reprezintă defapt o combinație între volumul de efort și complexitatea sarcinii.
Pentru o interpretare comună, story point-ul are o definiție dată în cadrul companiei.
Astfel , la nivel de companie va fi mult mai ușor de înteles și de interpretat dificultatea unei
sarcini dacă toată lumea se raportează la aceeași unitate de măsură.
De exemplu un story point poate fi echivalentul unei interogări în baza de date care face
legături între mai multe tabele. În evaluarea unei sarcini să presupune că se votează trei story
point-uri, asta însemnănd că efectuarea acelei sarcini este de aproximativ trei ori mai dificilă
decât o interogate în baza de date care face legături între mai multe tabele.
Această modalitate de estimare ajută și la raportare. Spre exemplu, la final de an se pot
face evaluările echipelor pe baza numărului de story point-uri livrate pe an. De aici poate rezulta
fie că în cadrul unor echipe se dezvoltă task-uri mai dificile, fie că unor echipe le consumă mai
puțin efort realizarea unor sarcini mai dificile.

Planning poker
Folosește șirul de numere al lui Fibonacci ușor adaptat în scopul de a estima cât de
dificilă va fi efectuarea unei sarcini, indiferent de durata de timp. Pentru planning poker avem
numerele 0,1,2,3,5,8 și 13. Au fost adăugate arbitrar numerele 20,40 și 100. Utilizând planning
poker se urmărește evitarea pierderii de timp cu estimările exacte. Scopul principal este acela de
a forma o idee relativă despre volumul de sarcini care poate fi livrat într-o iterație. 7
Pentru
planning poker, fiecare membru al echipei are la dispoziție un set de cărți cu numerele
menționate anterior, și, după ce s-a discutat sarcina care urmează să intre în lucru fiecare
membru al echipei arată câte o carte care să reflecte aprecierea lui cu privire la dificultatea
sarcinii (fiecare punct înseamnă câte un story-point).

Figura 1.3 – Estimare în story-point

Sursa: https://rsastories.wordpress.com/tag/user-story-points/

7
Barbee, D., 2013. Agile Practices for Waterfall Projects, Editura J.Ross. pag 111
10
 Status zilnic (daily scrum)
Într-un sprint, în metoda de lucru Agile fiecare echipă lucrează independent de celelalte și
are cobiective individuale. Din cauza independenței dintre echipe este destul de dificil să se
menționă transparența în cadrul proiectului. De aceea fiecare echipă face zilnic o ședință scurtă
de status, de 10 minute, ședință la care participă toți membrii echipei. Această ședintă se numește
daily scrum. Are loc în fiecare zi la aceeași oră, în același loc. Fecare membru al echipei trebuie
să răspundă la 3 întrebări:
- Ce a făcut în ziua precedentă
- Care sunt blocajele care îl împiedică să își desfășoare activitatea
- Ce va face în ziua curentă

Scrum of scrums
După ce fiecare echipă face ședința de status zilnic, are loc o altă ședință, tot de 10
minute la care participă doar scrum masterii fiecărei echipe și în care fiecare răspunde pe scurt la
aceleași trei întrebări, însă din punct de vedere al întregii echipe. Această ședință poartă
denumirea de scrum of scrums și are loc în fiecare zi la aceeași oră și în același loc. Această
ședință ajută la menținerea transparenței între echipe.

Figura 1.4 – Daily scrum

Sursa: http://techforceinfotech.com/blog-post/1000/

Practici din finalul iterațiilor:

Demonstrare
Pentru transparență și pentru dovedirea efortului susținut în timpul unui sprint, în finalul
acestuia echipa face o prezentare a sarcinilor efectuae în sprintul care tocmai se încheie. La
prezentare de regulă sunt invitate toate persoanele care ar putea fi interesate de sarcinile
terminate, și nu numai. În cadrul prezentarii se fac cunoscute noile funcționalități implementate.

11
Această prezentare are în primul rând un rol de informare, dar și un rol de îmbunătățire. La
sesiunile de demonstrare de regulă se primește feedback valoros cu privire la sarcinile încheiate.
Astfel, datorită feedback-ului, pe viitor membrii echipei vor dezvolta funcționalități mult mai
aproape de necesitățile clientului sau ale altor membri din cadrul companiei.
Retrospectivă
În finalul sprintului echipa se întâlnește pentru o scurta analiză a sprintului care tocmai s-
a încheiat. În baza unei discuții libere sunt punctate lucrurile care au mers bine, lucrurile care au
mers prost și îmbunătățirile care se pot avea în vedere pe viitor. Această analiză ajută membrii
echipei să elimine orice frustrări acumulate pe parcurs și să înceapă un nou sprint în care nu vor
mai repeta aceleași eventuale greșeli.
Se poate întâmpla ca în unele echipe, membrii să nu fie dornici să se exteriorizeze și să își
spună punctul de vedere de față cu ceilalți. În astfel de cazuri se pot aplica diverse practici care
sa colecteze feedback-ul de la membrii echipei pe parcurs. Spre exemplu, fiecare membru al
echipei poate face bilețele pe care să puncteze ce a mers bine, ce a mers prost și ce are loc de
îmbunătățiri și să le adauge într-o cutie comună, la daily-scrum sau chiar înainte de începerea
retrospectivei. Scrum master-ul va fi cel care le citește și astfel vor începe diverse dezbateri pe
baza bilețelelor scrise pe parcurs. Această practică este foarte apreciata, mai ales că, până în
finalul sprintului se uită o parte din lucrurile care nu au mers conform planului inițial.
Planificare
După demonstrare și retrospectivă echipa se întânește pentru a planifica sarcinile din
sprint-ul următor. Product owner-ul vine și prezintă sarcinile care vor intra în sprint. Pe baza
acestor sarcini au loc diverse dezbateri pentru stabilirea soluției, după care se fac estimările în
story point-uri.
Velocitate
Se poate întâmpla ca product owner-ul să propună pentru sprint-ul următor prea multe
sarcini. Astfel, pe baza numărului cumulat de story point-uri, scrum master-ul poate menționa că
echipa nu mai are capacitate de lucru, restul de task-uri urmând să fie dezvoltate în sprint-ul
următor. Velocitatea reprezintă capacitatea măsurată a echipei de a livra. 8

8
Barbee, D., 2013. Agile Practices for Waterfall Projects, Editura J.Ross pag 124

12
 CAPITOLUL 2
CONTROLUL CALITĂȚII

În cadrul companiilor producătoare de software (fie că este vorba despre producerea a

diverse programe, aplicații sau site-uri) calitatea este cheia către succes, de aceea managementul
calității este unul dintre cele mai importante elemente din cadrul acestor companii. Scopul final
al producătorilor din acest domeniu este, pe lângă producerea de programe, aplicații sau site-uri,
să livreze un produs de calitate, fără erori sau defecte, care să satisfacă nevoile utilizatorului și
cerințele clientului într-o măsură cât mai mare.
Etapele procesului de producție în acest domeniu sunt similare în toate companiile de
acest gen, indiferent de metoda de lucru. Pentru orice proiect este nevoie de o bună planificare,
discutată și agreată împreună cu clientul, de stabilirea design-ului produsului final, de
dezvoltarea propriu-zisă (adică de scrierea codului în diverse limbaje de programare), de testarea
produsului pe un mediu „de test” (utilizând toate metodele de testare necesare), înainte de
punerea în producție pentru a prinde cât mai multe erori și defecte și punerea produsului în
producție, ajungând astfel la utilizatorul final. Toate aceste etape trebuie urmate cu strictețe
indiferent de metoda de lucru (iterativă – care livrează pe parcurs sau incrementală – care
livrează tot proiectul la final) pentru ca în final să rezulte un produs de calitate în intervalul de
timp stabilit. „Creșterea exigențelor clienților și ale societăților care au impus calitatea ca factor
determinant al competivității întreprinderilor” 9 tocmai de aceea managementul calității ar trebui
să fie una dintre cele mai importante priorități ale producătorului, pentru a se asigura că fiecare
etapă este respectată întocmai și pe lângă acest lucru, pentru a se asigura că echipele care
lucrează în cadrul proiectului sunt bine închegate, sunt formate din oameni motivați și bine
pregătiți, care-și cunosc rolurile și atribuțiile. De asemenea, este esențial ca încă de la începutul
proiectului să se aleagă o metodă de lucru care să poată fi aplicată de toți cei implicați.

2.1 Testare (rolul testarii, costul erorilor, cauzele defectelor)

Rol:
„Oricine poate avea o opinie cu privire la semnificaţia “calităţii”, dar fiecare înţelege
noţiunea altfel.”10 Cea mai importantă etapă pentru controlul calității din cadrul companiilor

9
Stanciu, C., Fometescu, I., L., Chiru, L., Sevan, I., L., (2008). Manualul consumatorului de alimente. București:
Editura Oscar Print.
10
Toma, J., (2006). SR EN ISO 9000:2006 – Sisteme de management al calităţii. Principii fundamentale şi
vocabular. Revista Standardizarea, [online]. Disponibil la
http://standardizarea.ro/revista_standardizarea/Iunie2006.pdf [Accesat 2 Mar. 2017].
13
producătoared de software este etapa de testare a produsului. Fie că este vorba despre un
program, o aplicație sau un site, înainte de faza de lansare a proiectului este nevoie de un proces
bine stabilit și bine executat de testare.
“Testarea este procesul prin care se execută un program cu intenția de a găsi erori.” 11

Testarea este una dintre etapele importante în dezvoltarea produselor software prin care se poate
evalua și îmbunătății calitatea acestuia. Prin urmare, scopul testării este detectarea sistematică a
diferitelor clase de erori în cel mai scurt timp posibil și cu un minim de efort.
Una dintre caracteristicile testării este aceea că pune la dispoziție o viziune independentă
și obiectivă cu privire la produsul software ce se află în primele faze ale dezvoltării.
Testarea este importantă deoarece oricine poate greși în dezvoltarea unui produs
software. Unele dintre aceste greșeli sunt lipsite de importanță, iar unele pot influența foarte mult
modul în care produsul se dezvoltă. Este nevoie să se verifice mereu ceea ce se dezvoltă pentru a
se asigura un nivel ridicat de calitate.
Din moment ce se prespune că se poate greși în implementarea unui produs software, toți
programatorii ar trebui să-și verifice codul. De cele mai multe ori programatorului îi scapă
erorile deoarece știe cum trebuie să funcționeze sistemul și nu are o vedere obiectivă asupra
activității sale. Ideal este ca altcineva să verifice activitatea programatorului, în speță testerul.
Testarea software este foarte importantă din urmatoarele motive:
 Este foarte necesar ca defectele și erorile care au fost făcute în timpul fazei de dezvoltare
să fie găsite.

 Este important să fie asigurată calitatea produsului software. Un produs de calitate ajută
la câștigarea încrederii beneficiarului aplicatiei sau utilizatorului final.

 Asigurarea ca aplicația nu are erori, deoarece acestea pot fi foarte costisitoare în viitor
sau în etapele finale de dezvoltare.

Costul erorilor:
Eroarea este „o acțiune provocată de om care produce un rezultat incorect. Erorile pot
apărea în orice fază a ciclului de dezvoltare.
Defectul (bug-ul sau problema) într-o componentă a sistemului poate determina sistemul
să nu mai funcționeze conform cerințelor și așteptărilor clientului, ba chiar este posibil ca întreg
sistemul să nu mai funcționeze.”12

11
Myers, G., Sandler, C., Badgett, T., (2012). The Art of Software Testing . Editura 3rd Edition, pag. 112
12
Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag. 11
14
 Un defect este orice comportament neașteptat al aplicației; softul face ceva ceea ce
utilizatorul consideră că nu este bine. Poate fi o deviație de la specificațiile funcționale furnizate
de către product owner. 13
Un singur defect poate cauza un cost foarte mic, sau chiar un cost de milioane.
Dacă luăm drept exemplu un design necorespunzător al unui raport, afișarea datei nu se
face în formatul dorit, acest defect poate fi catalogat drept un cost foarte mic. Impactul este
minimal. În schimb, valoare greșită dintr-un raport poate costa milioane.
Pe de altă parte, erorile unor sisteme pot cauza chiar pierderi de vieți omenești. Spre
exemplu, o defecțiune a sistemului de control al traficului aerian. În general, testarea nu este
exhaustivă, însă pentru aceste domenii, cele care pot impacta viețile oamenilor se încearcă
efectuarea unei testari exhaustive, care să acopere aproape tot sistemul.
Creșterea costurilor cauzate de defecte crește proporțional cu trecerea prin fazele
succesive ale dezvoltarii. Cu cât un defect este identificat mai devreme, cu atât costurile de
reparare sunt mai mici. Spre exemplu, dacă un defect este identificat încă de la începutul
proiectului, de la faza de cerințe, costul de reparare este aproape 0. Dacă defectul este identificat
în timpul dezvoltării, în primele faze, costul de reparare este foarte mic, ca și timp și ca și preț.
Însă dacă un defect este identificat post-producție, costurile pentru rezolvarea lui pot fi majore,
atât ca timp, cât și financiar vorbind. Rezolvarea defectelor în etapa post-producție de asemenea
pot genera și alte probleme în alte zone ale sistemului.
Modelul pentru escalarea costurilor:
Costul corectării unui defect poate fi demonstrat grafic cu ajutorul modelului pentru
escalarea costurilor. Costul corectării unui defect crește alarmant de la o etapă la alta. În industria
testării de software este general acceptat faptul că, costurile pentru fixarea defectelor vor crește
10% odată cu depășirea unei etape de dezvoltare a proiectului.

13
Ash, L., (2003). The web testing companion, Editura Wiley Publishing, Inc, pag 16
15
 Figura 2.1 – Fazele testării
Sursa: Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag. 11

Unde:
UR = cerințele utilizatorului
FS = specificații funcționale
TS = specificații tehnice
UAT = testare de acceptanță a utilizatorului

Cauzele defectelor:
Sunt multe cauze prin care în produsele software pot fi introduse defecte sau bug-uri. Cea
mai comună cauză este eroarea umană în proiectarea și implementarea produsului. Pe lângă
aceasta mai pot fi enumerate câteva cauze:
 Comunicare greșită. Acest factor se poate interpreta în diferite feluri: lipsă de
comunicare sau comunicare incorectă, poate apărea atunci când cerințele sunt incomplete
sau neclare.
 A face greșeli este un lucru natural, care ni se întâmplă tuturor. Testarea ne ajută să
identificăm greșelile. Asigurarea calității sau programele de îmbunătățire ne ajută să
învățăm din aceste greșeli și să nu le mai repetăm pe viitor.
 Presiunea dezvoltării unui proiect cu constrângeri legate de timp, de buget, de resurse
sau de deadline vor crește probabilitatea ca noi, oamenii, să facem greșeli.
 Timp de dezvoltare ireal. În această situație se poate ajunge când testerul nu are
suficiente informații despre produsul pe care îl testează și aplicația este livrată foarte des.
Acest lucru poate duce la un produs cu un nivel scăzut de calitate și cu multe defecte.

16
  Erori de programare. Programatorii, ca oricine altcineva, pot face greșeli; cei mai puțin
experimentați sau fără cunoștințe în domeniul ales sunt succeptibili erorilor în timpul
implentării. Lipsa practicii de implentare simple, testarea unitară, metodele de debug sunt
cele mai comune motive prin care sunt introduse bug-uri în fazele de dezvoltare.
 Schimbarea cerințelor. Utilizatorul final se poate să nu înțeleagă efectul schimbărilor sau
să-l înțeleagă și să le dorească oricum. Indiferent de dimensiunea schimbărilor, acestea
pot influența părți ale sistemului de altfel fără o legatură directă, introducând defectele de
regresie.

Test, caz de test, plan de test

Un test reprezintă unul sau mai multe cazuri de testat ce urmează a fi executate în vederea
evaluării resultatelor. Testele se fac în mai diferite etape din ciclul de viață al aplicațiilor, site-
urilor sau a programelor pentru a valida comportamentul așteptat și pentru a identifica eventuale
abateri de la acesta.
Un caz de test reprezintă „un set de date de intrare precondiții pentru executare, rezultate
așteptate și condiții post-execuție, dezvoltate pentru un obiectiv particular sau pentru o condiție
de testat, pentru a verifica conformitatea cu o cerință specifică.” 14 Cazul de test reprezintă “intrări
specificate de documentație, rezultate așteptate și un set de condiții de execuție pentru un item al
testului.”15
Cazurile de test sunt redactate în general de către echipa de testare, pe baza unui
document de analiză bine pus la punct, într-o formă finală, care descrie clar comportamentul
așteptat din soft-ul, aplicația sau site-ul ce urmează a fi testat. Cazurile de test trebuie să acopere
toate funcționalitățile menționate în documentul de analiză. Cazurile de test sunt în general
înregistrate într-o aplicație, în vederea păstrării lor și a rulării lor, în final rezultând un raport din
care să reiasă câte teste au trecut, câte teste au picat și câte teste nu au putut fi rulate din diverse
motive.
Prin rularea cazurilor de test se înțelege parcurgerea pașilor menționați în cadrul cazului
de test de către unui sau mai mulți membrii ai echipei de testare, verificând astfel că rezultatele
așteptate (conform datelor de intrare) sunt returnate.
Rulând cazurile de test se vor parcurge toate funcționalitățile aplicației și astfel vor fi
identificate numeroase erori și defecte încă din faza de producție, înainte ca versiunea finală a
aplicației să ajungă la client sau la utilizatorul final.
Statusurile prin care trece un caz de test pot fi: neexecutat, trecut, picat, locat, invalid.
14
Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag 26
15
Standard Român 2008, Sistem de management al calității. Cerințe, (SR EN ISO 9001:2008), Asociația de
Standardizare din România (ASRO).
17
 Figura 2.2 – Statusurile cazurilor de test
Sursa proprie

- Cazul de test trece din statusul de neexecutat în statusul Trecut dacă rezultatele așteptate
sunt îndeplinite, în conformitate cu datele de intrare.
- Cazul trece din statusul neexecutat în statusul Picat dacă rezultatele așteptate nu sunt
îndeplinite, în conformitate cu datele de intrare. Pentru acest caz este necesară
argumentarea prin înregistrarea unui defect a motivului pentru care a fost picat cazul de
test.
- Cazul trece din statusul neexecutat în statusul Blocat dacă pe parcursul rulării cazului de
test se identifică un defect blocant, care împiedică continuarea rulării cazului de test curent
sau a cazurilor de test ulterioare. Pentru acest caz este necesară argumentarea prin
înregistrarea unui defect cu statusul blocat, a motivului pentru care a fost blocat cazul de
test.
- Cazul trece din statusul neexecutat în statusul Invalid,dacă pe parcursul rulării se remarcă
faptul că testul în lucru nu mai poate fi executat conform noilor specificații.
Toate defectele și erorile identificate la rularea cazurilor de test vor fi înregistrate, pentru
a argumenta astfel de ce cazul de test a fost picat. Este esențial ca testerul care rulează cazurile
de test să facă o legătură între cazul testat și defectul sau eroarea identificată. Toate defectele și
erorile identificate vor fi fixate de către echipa de dezvoltare. După fixarea lor, va fi necesară
retestarea defectului și reparcurgerea cazului de test.
Un plan de test este un document care descrie care este scopul testării și care sunt
activitățile care vor fi desfățurate în această fază. „Un plan de test trebuie să specifice cum este
aplicată strategia de testare și cu se va efectua testarea softului. Trebuie să identifice toate
excepțiile strategiei de testare și toate celelalte programe cu care software-ul care va fi testat va
18
iteracționa în timpul execuției” 16. De asemenea trebuie să specifice care sunt toate resursele
necesare din această fază și care este graficul activităților ce urmează a fi desfășurate.
Exemplu:

- Numele produsului
- Pregătit de (numele persoanei/persoanelor, data)
- Cuprins
1.0 Introducere
2.0 Obiective și sarcini
2.1 Obiective
2.2 Sarcini
3.0 Scop
4.0 Strategia de testare
4.1 Testare la nivel de unitate de cod
4.2 Testare de integrare
4.3 Testare de performanță
4.4 Testare de acceptanță
4.5 Testare automata
5.0 Graficul activităților
6.0 Controlul procedurilor
7.0 Funcționalități care vor fi testate
8.0 Funcționalități care nu vor fi testate
9.0 Resurse/roluri, responsabilități
10.0 Departamente impactate
11.0 Dependințe
12.0 Riscuri
13.0 Instrumente folosite
14.0 Aprobări17

Inregistrarea si fixarea defectelor. Instrumente folosite. Ciclul de viață al unui defect

Pentru a conferi transparență proiectului în lucru și pentru o mai bună organizare, este
recomandat ca toate defectele identificate să fie înregistrate într-un sistem. Astfel, în cazul în

16
Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag 30
17
Thomas, R., (2006). Test plan sample: SoftwareTesting and Quality assurance Templates, [online].
Disponibil la http://www.softwaretestinghelp.com/test-plan-sample-softwaretesting-and-quality-assurance-
templates/ [Accesat 8 Apr. 2017].
19
care în etapa de testare sunt identificate mai multe defecte, se poate realiza o prioritizare a
acestora, în funcție de diverse aspecte, cum ar fi: în funcție de severitate, de dificultate, de
categorie. În plus, în diverse etape ale proiectului sau chiar în finalul lui se pot construi diverse
statistici pe baza defectelor identificate. Presupunând că în prima etapă a proiectului a fost
identificat un număr mare de defecte, în finalul acestei etape se poate realiza o retrospectivă în
baza numărului de defecte, analizând în cadrul echipei ceea ce nu a mers bine, de ce a apărut un
număr așa de ridicat de defecte și cum se poate îmbunătăți activitatea din faza de dezvoltare
pentru ca în faza de testare să fie identificat un număr cât mai redus de defecte.
În cadrul fiecărei companii se impune un anumit șablon pentru înregistrarea defectelor.
Când se identifică un defect este esențial ca persoana care l-a identificat să își amintească ce a
cauzat problema. Această instrucțiune poate părea evidentă, însă identidicarea cauzei și a pașilor
pentru a reproduce problema reprezintă cel mai important punct pentru a putea reproduce
defectul.18 În general, la înregistrarea unui defect trebuie enumerate următoarele elemente:

- Subiectul – presupune o descriere foarte scurtă a problemei raportate și menționarea

zonei în care a fost identificată problema
- Descrierea - conține:
 descrierea detaliată a problemei
 pașii necesari pentru a reproduce problema
 referințe care pot exemplifica problema, precum: contul pe care se poate
reproduce problema, mediul în care a fost identificată (pe mediul de test, pe mediul de
producție), versiunea soft-ului pe care a fost identificată problema
- Rezultatul actual – menționarea comportamentului greșit
- Rezultatul așteptat – menționarea comportamentului corect
- Atașamente – pot fi orice resurse care pot fi folosite pentru exeplificarea și pentru
reproducerea cât mai rapidă a problemei. Pot fi imagini, email-uri, log-uri etc.
- Prioritatea – măsoară cât de urgentă este fixarea defectului. Prioritatea unui defect
descrie în ce măsură acesta afectează intern compania și, în raport cu alte defecte, cât de
rapid ar trebui să fie rezolvat. 19A nu se confunda cu severitatea. Un defect poate avea o
prioritate ridicată deoarece impactează procese importante sau un număr mare de
utilizatori. Nivelurile de prioritate pot fi:
 Scăzut
 Normal
18
Ash, L., (2003). The web testing companion, Editura Wiley Publishing, Inc, pag 30
19
Ash, L., (2003). The web testing companion, Editura Wiley Publishing, Inc, pag 32

20
  Ridicat
 Urgent
 Imediat
Cele mai multe defecte sunt raportate cu prioritate Normal. Prioritățile Ridicat, Urgent,
Imediat ar trebui folosite numai în cazuri excepționale.

- Categoria – ar trebui să existe o opțiune de selecție dintre mai multe categorii. În funcție
de categorie se pot face diferse filtrări customizate (spre exemplu, în finalul uneia dintre
fazele proiectului se poate face o filtrare după categoria Prețuri pentru a vedea câte
defecte au fost identificate în această zonă).
- Severitatea – măsoară cât de devastatoare pot fi efectele unui defect. Severitatea descrie
care este impactul asupra unui client – reprezintă riscul și vizibilitatea. 20
- Cine a identificat defectul – defectele pot fi identificate în diverse etape ale proiectului
și de diverse echipe: pot fi identificate de către echipa de testare, în timpul etapei de
testare sau pot fi identificate ulterior acestei etape, adică în producție, fie de către alte
echipe din companie, fie de către utilizatorii finali. Este esențială această mențiune și nu
doar pentru raportare, ci și pentru proces. Defectele identificate de către utilizatorii finali
vor fi tratate cu prioritate, indiferent de prioritatea marcată la înregistrarea defectului.

Pentru transparență și pentru o raportare cât mai eficientă se recomandă utilizarea unor
sisteme speciale pentru înregistrarea defectelor (numite si bugtracking tools). Cu ajutorul lor, nu
numai că înregistrarea defectelor se va face complet, corespunzător, urmând un șablon standard,
cu elemente obligatorii de completat, însă vor ajuta și la filtrarea defectelor în funcție de anumite
criterii, în funcție de necesități.
Exemple de sisteme de bugtracking: RedMine, Mantis, Application Lifecycle
Management, etc. Toate sistemele de bugtracking pot fi configurate astfel încât să fie pliabile pe
nevoile proiectului.
Doar raportarea unui defect sau a unei erori nu este suficientă. Faptul că un defect sau o
eroare a fost raportată nu aduce niciun plus în cadrul procesului dacă defectul sau eroarea nu va
fi rezolvată de echipa de dezvoltare. Prin urmare, defectele și erorile au un întreg ciclu de viață.
În momentul adăugării unui defect în sistemul de bugtracking acesta va dobândi un
status: Nou. Ulerior, defectul va fi preluat de către echipa de dezvoltare în vederea fixării lui și
va dobândi statusul: In progres. Din această fază există doua posibile statusuri ulterioare:
- Rejectat – în cazul în care defectul s-a fixat anterior

20
Ash, L., (2003). The web testing companion, Editura Wiley Publishing, Inc, pag 33
21
 - Rezolvat – în cazul în care defectul a fost fixat
Din momentul în care defectul a fost marcat ca rezolvat, acesta poate fi preluat din nou
de către echipa de testare în vederea verificării fixului. Statusul defectului va deveni: În testare.
După ce testerul finalizează testarea defectului, exista două posibile statusuri:
- Redeschis – în cazul în care defectul initial încă se reproduce sau nu a fost fixat în
totalitate
- Testat – în cazul în care defectul a fost fixat
Dacă defectul a fost redeschis, va trece din nou în progres pentru a fi rezolvat.
Dacă defectul fost testat, va ajunge la un manager de release care va valida calitatea
codului scris și valida faptul că a fost respectat standardul de scriere a codului impus în cadrul
companiei. În cazul identificării unor neconformități, managerul de release va putea să
redeschidă defectul pentru a reintra în procesul de fixare. În cazul în care codul este în regulă,
defectul va trece în statusul Închis. Odată cu închiderea defectului, fixul pentru acesta va ajunge
în mediul de producție.

2.2 Niveluri de testare: testare de componente, testare de integrare, testare de

sistem, testare de acceptanță
Pentru a asigura o bună funcționare a aplicației atunci când ajunge în mediul de producție
indiferent de elementele cu care va interacționa (fie că este vorba de diferse interfețe sau alte
aplicații) este necesară efectuarea testării pe mai multe niveluri.
Testarea de componente este prima formă de testare efectuată pe codul scris și de regulă
este efectuată imediat după ce codul a fost scris. Testarea de componente este efectuată de către
dezvoltatori. Cea mai potrivită persoană pentru a efectua testarea de componente este însuși
autorul codului pentru că el este cel mai familiar cu codul și cel mai în măsură să identifice și să
fixeze defectele existente. 21
Testarea de componente este o metodă prin care se testează fiecare metodă separat. Mai este
cunoscută și sub numele de testare pe module. Diferența dintre testarea de componente și testarea
unitară este aceea că, la testarea unitară programatorii verifică doar câte o secțiune de cod, în timp ce
la testarea de componente este testat întregul modul.
De exemplu se dezvoltă o aplicație de înregistrare a studenților unei facultăți. În cadrul
aplicației vor exista două module: unul dintre module va face salvarea înregistrărilor studenților iar

21
Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag 54

22
celălalt modul va face încărcarea rezultatelor studenților. Deși ambele module sunt dezvoltate
separat, acestea vor fi testate unul câte unul iar această metodă definește testarea de componente.

Figura 2.3 – Testarea de componente

Sursa proprie

Testarea de integrare are rolul de a examina modul în care un sistem interacționează cu

alte sisteme sau aplicații cu care va fi conectat în momentul în care sistemul va ajunge în mediul
de producție. Practic, testarea de integrare este efectuată în scopul de a verifica funcționalitatea
combinată după integrarea a două sau mai multe sisteme.

Figura 2.4 – Testarea de integrare

Sursa proprie

Testarea de sistem reprezintă procesul prin care se efectuează testarea tuturor sistemelor
din aplicație integrate pentru a verifica faptul că, sistemul integrat este în conformitate cu
cerințele. 22
22
Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag 62

23
 Figura 2.5 – Testarea de sistem
Sursa proprie

Testarea de acceptanță reprezintă unul dintre ultimele niveluri de testare. Se face în

scopul de a verifica faptul că cerințele clientului au fost respectate. Testarea de acceptanță se
realizează de regulă de către client sau de către utilizator. Scopul principal al testării de
acceptanță este acela de a câștiga încrederea clientului sau a utilizatorului în aplicația creată și de
a identifica eventuale defecte în ideea de a fi fixate înainte ca aplicația să ajungă pe mediul de
producție.

2.3 Tehnici de testare:black box testing, white box testing, smoke testing,
testare de regresie, re-testare, testare de performanță, testare de stres, testare
de securitate, testare de mentenanță
Black box testing: este testare funcțonală, fără a face referire la structura internă a
compenentelor din cadrul sistemului. 23 Această tehnică de testare are la bază testarea funcțională
și urmărește ce face sistemul, nu cum face. Făcând analogia cu conducerea unui autoturism,
backbox testing este echivalunt cu a conduce mașina. Utilizatorul știe să conducă mașina însă nu
știe (neapărat) ceea ce se întâmplă sub capota mașinii în timpul deplasării.
În cadrul acestui tip de testare, testerul introduce date în aplicație urmărește output-ul
cazului testat. Practic, testerul urmărește ca datele de ieșire să fie în conformitate cu rezultatul
aștepat. Persoana care efectuează acest tip de testare nu trebuie să cunoască structura tehnică a
proiectului, ci trebuie să pornească de la premisa: Codul trebuie să conțină erori.
Avantaje ale testării blackbox:

23
Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag 116
24
 - Persoana care efectuează testarea nu trebuie (neapărat) să dețină informații tehnice,
precum limbaje de programare
- Cazurile de test sunt concepute din prisma utilizatorului, astfel cresc șansele unei evaluări
obiective a comportamentului în raport cu specificațiile
- Cazurile de test pot să fie construite după ce se stabilesc specificațiile, adică într-o fază
incipientă a proiectului

Metode de blackbox testing:

- Equivalence partitioning – datele de intrare ale sistemului sunt impărțite în diferite
categorii. De la fiecare categorie de date se așteptă același rezultat. Datele de intrare cunt
clasificate în date valide și date invalide. Această tehnică poate utilizată la toate nivelele
de testare.
- Boundary Value Analysis – se analizează comportamentul datelor de intrare la limitele
fiecărui interval de echivalență. Toate testele se fac pentru valorile limită valide, dar și
pentru valorile limită invalide.

White box testing: este testarea bazată pe analiza structurii interne a componentelor din
cadrul sistemului. 24
În această tehnică de testare cazurile de test sunt construite pe baza
cunoștiințelor detaliate ale funcționării interne a sistemului, adică pe baza cunoașterii codului. În
cazul acesta accentul pică pe cum lucrează sistemul. Făcând analogia cu conducerea unui
autoturism, whitebox testing este echivalent cu a verifica motorul de către un mecanic după ce a
fost fixată o problemă a acestuia.

Metode de whitebox testing:

- Acoperirea tuturor instrucțiunilor: toate instrucțiunile din unitatea care este testată vor fi
verificate pentru a depista toate zonele de cod nefolositoare.
- Acoperirea tuturor ramurilor: toate ramurile din cod trebuie să fie testate. Astfel,vor fi
parcurse valorile adevărate și false din cod.
- Acoperirea tuturor condițiilor:

Smoke testing: Această tehnică de testare caută să evidențieze dacă produsul este
funcțional înainte de a efectua testarea detaliată a acestuia. Practic sunt validate modificările
făcute asupra codului înainte de rularea cazurilor de test propuse. Acest tip de testare urmărește
ca, cu un efort minim să fie identificate defectele severe. Testele de acest gen se focusează
24
Buwalda, P., (2010). Basics of Software Testing. Editura Quality House, pag 116
25
exclusiv pe modificările aduse în noua versiune a soft-ului. Prin rularea unei suite de smoke test
nu este garantată calitatea, ci doar se validează faptul că softul este încă funcțional după ultimele
modificări, nu are defecte blocante, deci poate fi începută etapa următoare de testare. În cazul în
care există defecte blocante, care împiedică începerea etapei urătoare de testare, versiunea de soft
curentă poate fi respinsă de către echipa de testare, în vederea rezolvării cu prioritate a defectelor
blocante de către echipa de dezvoltare.
Testare de regresie: Testarea de regresie se efectuează fie în finalul unei iterații, fie în
finalul proiectului, fie după retestarea unui defect. Motivul pentru care este necesară testarea de
regresie este că, după numeroase defecte identificate este posibl ca fixurile pentru acestea să
genereze alte defecte sau erori. În timpul testării de regresie practic se testează „în mare”
aplicația, fiind atinse cele mai sensibile zone ale acesteia, zonele care pot avea impact major.
Retestare: Aceasta tehnică de testare se aplică după fixarea defectelor care au fost
redeschise (este vorba despre defectele care au trecut prin următoarele statusuri: Nou, In progres,
Rezolvat, In testare și au fost redeschise din cauza unor neconformități în vederea rezolvării lor).
După rezolvarea defectelor, ele trec prin aceleași etape, deci este nevoie ca echipa de testare să
reteseze fixurile.
Testare automată: Testarea automată este recomandată pentru cazurile în care anumite
cazuri de testare ar trebui repetate de mai multe ori, în diferite faze ale proiectului. Astfel, se vor
compune scenarii de testare pentru cazurile care se repetă, scenarii care vor fi ulterior transpuse
în scripturi, folosind un limbaj de programare. Scriptul va putea fi rulat folosind instrumentele
tehnice aferente ori de câte ori va fi necesar. În general, testarea automată vine în sprijinul
testării de regresie. Astfel, în finalul unei iterații, al unui proiect sau după retestarea unui defect
se recomandă rularea unei suite de teste automate care să acopere cazuri de test din cele mai
importante zone ale proiectului.
Testare de performanță: Definiţia ISTQB pentru Testarea de Performanţă este
"procesul de testare prin care se determină performanţa unui produs". Cu alte cuvinte scopul
nostru este de a afla cât de bun este un produs software, cât de rapid, câţi useri poate să susţină
precum și timpul de răspuns pentru fiecare dintre ei, sau care sunt limitele produsului.
Rezultatele obţinute în urma testelor de performanţă vor ajuta factorii de decizie din Business să
ia o decizie informată cu privire la lansarea unui produs. Testarea de performanţă va oferi
informaţii despre cum se va comporta produsul în utilizarea zilnică, cu acces concurent din
partea utilizatorilor. Rezultatele vor folosi în estimarea resurselor hardware necesare pentru a
susține un anumit număr de utilizatori.25

25
Cosma, A., (2017). Planificarea Testării de Performanţă, [online]. Disponibil la
https://www.todaysoftmag.ro/article/392/planificarea-testarii-de-performanta [Accesat 8 Apr. 2017].
26
 Testare de stres: Aceată tehnică de testare este efectuată în scopul de a determina
stabilitatea sistemului în diferite condiții. Spre exemplu, se verifică timpul de răspuns al bazei de
date atunci când se efectuează interogări complexe, care returnează un număr foarte mare de
date. Se mai poate testa comportamentul aplicației în cazul în care nu mai există spațiu în baza
de date, sau atunci când este întreruptă conexiunea la server.
Testare de securitate: securitatea unei aplicații sau a unui program este unul dintre cele
mai importante aspecte. Un software securizat poate fi numit un software de calitate. Este demult
știut faptul că hackerii forțează aplicațiile web în vederea acesării unor conținuturi interzise fi a
furtului de date. Tesarea de securitate urmărește identificarea timpurie a vulnerabilităților
aplicației. Asigurarea securităţii aplicaţiilor informatice este una dintre cele mai importate
probleme care trebuie rezolvată în contextul societăţii informaţionale. Aplicaţiile informatice
primesc, prelucrează, stochează şi transmit o multitudine de informaţii şi date, utilizând o
multitudine de tehnologii de transport şi interfaţă (zone de memorie, socket-uri, variabile de
mediu, fişiere, protocoale de comunicaţie etc.). Identificarea punctelor slabe ale aplicaţiilor şi
corectarea acestora încă timpul fazelor de dezvoltare se realizează printr-un proces de testare
specific, bine planificat şi organizat, conduce la asigurarea încrederii26
În vederea dovedirii faptului că o companie producătoare de software este securizată, este
necesară obținerea unei certificări OWASP (Open Web Application Security Project). OWASP
este o comunitate online care creaza articole disponibile gratuit, metodologii, documentații,
instrumente și tehnologii pentru sfera securității web. 27
Anual, OWASP publică topul celor 10
cele mai întâlnite vulnerabilități identificate în cadrul aplicațiilor web.
Pentru a fi ferită de atacurile hackerilor, o companie producătoare de software trebuie să
efectueze teste de vulnerabilitate pentru a identifica eventuale posibilități de accesare a datelor
confidențiale.
Testare de mentenanță: După ce aplicația la care se lucrează ajunge în mediul de
producție, la utilizatorul final, nu înseamnă că proiectul s-a încheiat. În faza post-producție se vor
face diverse optimizări în scopul de a îmbunătăți aplicația și experiența utilizatorului. Aceste
optimizări au nevoie de testare, atât pentru a garanta corectitudinea codului scris, cât și pentru a
garanta că în urma implementărilor post-producție nu au fost afectate alte funcționalități ale
aplicației.

CAPITOLUL 3
26
Toma, J., (2006). SR EN ISO 9000:2006 – Sisteme de management al calităţii. Principii fundamentale şi
vocabular. Revista Standardizarea, [online]. Disponibil la
http://standardizarea.ro/revista_standardizarea/Iunie2006.pdf [Accesat 2 Mar. 2017].
27
(2017). OWASP, [online]. Disponibil la https://en.wikipedia.org/wiki/OWASP [Accesat 8 Apr. 2017].
27
 CERCETARE PRIVIND METODELE ȘI TEHNICILE DE
LUCRU PENTRU MONITORIZAREA ȘI CONTROLUL
CALITĂȚII

3.1 Stabilirea obiectivelor și a ipotezelor cercetării

Pentru a se asigura că metodele și tehnicile pe care le utilizează pentru monitorizarea și
controlul calității sunt cele potrivite, managerii companiilor producătoare de software sunt
nevoiți să conceapă, resprectiv să realizeze cercetări de marketing. Pe baza rezultatelor lor se pot
stabili diverse planuri, strategii cu ajutorul cărora să îmbunătățească metodele utilizate și să
optimizeze procesele de luare a deciziilor, de producție, de testare și de livrare.
Scopul pincipal pe care îl au cercetările de marketing este acela de a scoate în evidentă
toate informațiile necesare despre metodele și tehnicile posibile, ceea ce preferă angajații și ceea
ce utilizează în prezent și mai ales ceea ce și-ar dori să utilizeze pe viitor.
Simpla evidențiere a informațiilor despre metodele și tehnicile utilizate și despre ceea ce-
și doresc angajații nu este suficientă, drept urmare, prin intermediul planurilor și a strategiilor de
marketing se urmărește totodată și identificarea tuturor problemelor cu care se pot contrunta
angajații utilizând metodele și tehnicile actuale. De asemenea, se intenționează și efectuarea
calculării tuturor șanselor posibile de a intra puternic pe piață.
“Cercetarea de marketing reprezintă culegerea, procesarea şi analiza informaţiilor supra
unor teme relevante pentru marketing. Ea începe cu definirea problemei şi se încheie cu un
raport şi recomandări de acţiune”28.
Asociația Americană de Marketing (AMA) definește cercetările de marketing ca fiind
defapt legătura dintre cumpărători/consumatori/angajați/publicul larg și toate informațiile care
ajung la aceștia pentru a putea defini eventualele probleme existente și posibilele oportunități,
Cercetările de marketing se efectuează pentru a evalua și clarifica toate actiunile de marketing,
reprezentănd un proces sistematic și obiectiv, care poate genera informații valoroase pentru
procesul decizional, prin culegerea, investigarea și prin analizarea tuturor informațiilor legate de
domeniul analizat.
Cercetările de marketing analizează diferitele cerințe ale agenților economici și pot fi
împărțite în cercetări exploratorii sau pure, folosite pentru fundamentarea și evaluarea
conceptelor și teoriilor, și cercetări aplicative care au ca scop găsirea unui răspuns la problemele

28
Lehmann, D.R., Gupta, S., Steckel, J.H., (1998). “Marketing Research, Addison-Wesley, Reading”, Editura Wiley
Publishing, Inc., pag.1.
28
reale specifice firmelor/instituțiilor/organizațiilor. De asemenea cercetările pot fi și cantitative
sau calitative29.
Astfel, pe baza realizării cercetărilor de marketing în domeniul producției de software,
producătorii vor deveni din ce în ce mai capabili să livreze la timp produsele cerute, la o calitate
înaltă, produse demne de competiție, sigure și fără vulnerabilități. Piața IT pune la dispoziția
clienților și a utilizatorilor produse din ce în ce mai variate, cererea fiind din ce în ce mai mare,
astfel în întregul proces de planificare, producție și livrare este o nevoie permanentă de implicare
atât din partea managementului, cât și din partea angajaților pentru a putea face față cererii în
crește și pentru a satisface dorințele unei palete de clienți din ce în ce mai mare.

În vederea cercetării privind percepţia persoanelor care lucrează în domeniul producției

de software cu privire la metodele și tehnicile de lucru utilizate pentru monitorizarea și controlul
calității, s-a folosit ca instrument cercetarea exploratorie.

Primul obiectiv al acestei cercetări este de a determina care este cea mai utilizată
metodă de lucru. S-a pornit de la următoarele ipoteze:

Ř fiecare companie folosește o metodă de lucru pentru monitorizarea și controlul

calității, iar cea mai utilizată metodă de lucru este metoda Agile
Ř angajații acordă o importanță majoră etapelor de analizare, planificare,
retrospectivă a activităților desfășurate în echipă
 angajații apreciază utilitatea estimării task-urilor

Cel de-al doilea obiectiv al acestei cercetări este de a urmări care este importanța
acordată de angajați etapei de testare. S-a pornit de la următoarele ipoteze:

Ř majoritatea angajaților acordă o importanță majoră etapei de testare

Ř angajații remarcă beneficiile pe care le poate aduce etapa de testare
Ř în viziunea angajaților, securitatea produselor create este cea mai importantă

Cel de-al treilea obiectiv al acestei cercetări este de a evalua care este importanța
acordată de angajați defectelor și înregistrării lor. S-a pornit de la următoarele ipoteze:

Ř cele mai importante elemente de menționat în momentl înregistrării unui defect

sunt pașii de reprodus și prioritatea

29
Naresh, M.K, (2007). Marketing research. An Applied Orientation, Editura Pearson Prentice Hall, Upper Saddle
River, pag. 87
29
 Ř înregistrarea defectelor este importantă în primul rând pentru că ajută la o
rezolvare mai eficientă iar în al doilea rând pentru că îmbunătățește vizibilitatea
în procesul de producție.

În cadrul acestei cercetări s-au urmărit acele probleme care se află în legătură cu impactul
pe care îl poate avea existența unor defecte în cadrul programelor create.

Au fost parcurse următoarele etape:

Ř s-au identificat cele mai utilizate metode și tehnici de lucru pentru monitorizarea
și controlul calității în domeniul producției de software
Ř s-a definit scopul cercetării, adică stabilirea celei mai utilizate metode de lucru
Ř au fost alese sursele informaţiilor. Eşantionul pe baza căruia au fost generate
resultatele cercetrii de față a fost de 70 persoane de vârste diferite, care lucrează
în domeniul prducției de software, provenite atât din mediul rural cât și din
mediul urban
Ř ca metodă de recoltare a informațiilor a fost folosit chestionarul online
Ř informațiile au fost recoltate, prelucrate și interpretate în vederea calculării
ponderilor răspunsurilor în scopul realizării graficelor reprezentative.
Ř au fost prezentate principalele rezultate obținute
 au fost formulate concluziile studiului, aceasta fiind ultima etapă a cercetării de
față. În această

Toate obiectivele care au fost menţionate anterior vor fi atinse prin intermediul cercetării
exploratorii, folosind ca instrument de recoltare a informațiilor un chestionar ce a fost distribuit
online.
Prin intermediul studiului de față se verifică o serie de ipoteze formulate în legatură cu
interesul manifestat de angajați față de metodele și tehnicile de lucru utilizate în domeniul
producției de software.
Concluziile cercetării de față pot constitui baza unor cercetări ulterioare în acest domeniu,
cercetări mai ample care pot fi realizate atât la nivelul companiilor existente pe piața din
România, cât și la nivelul companiilor existente pe piața internațională.

3.2 Proiectarea instrumentrului de recoltare a informațiilor

30
 În general, denumirea de cercetare ne poate duce duce cu gândul la o investigație
sistematică, controlată și critică asupra unor ipoteze, o activitate pentru descoperirea adevărului,
un efort de dobândire a unor noi cunoștințe. Pentru a realiza o cercetare corectă aceasta trebuie
proiectată în funcţie de scopurile pe care le urmărim, obiectivele fiind extrem de variate.30
Cеrcеtаrеа dе piаţă еstе аcеl tip dе cеrcеtаrе cаrе trаnsformă dаtеlе în informаţii mеnitе
să rеzolvе o problеmă rеcеnt аpărută şi prompt dеfinită, să confеrе аrgumеntе cаntitаtivе şi
cаlitаtivе dеciziеi. Аcеst tip dе cеrcеtаrе еstе dеfinit cа o orgаnizаrе dе mеtodе, procеdее şi
tеhnici dе culеgеrе şi înrеgistrаrе а dаtеlor, prеlucrаrе, prеzеntаrе şi rеprеzеntаrе, аnаlizа şi
intеrprеtаrе а informаţiilor, prognozаrе а modificărilor piеţеi şi mеdiului еxtеrn аl firmеi, dаr şi
dе promovаrе а unеi dеcizii justе şi profitаbilе fundаmеntаlе prin intеrmеdiul unui sistеm dе
indicаtori cе pеrmit cunoаştеrеа şi аnticipаrеа schimbărilor în concеpţiilе şi аtitudinilе
cumpărătorilor, în prеfеrinţеlе şi аspirаţiilе аcеstorа31

O cercetare dе piаţă аr trеbui să urmеzе următoarele trеi еtаpе principale32:

 Plаnificаrеа – constă în formularea încă de la început a unui scop clar, ce vine în

sprijinul realizării oricărei cercetări dе mаrkеting. Este posibil ca etapa de planificare să
gеnеrеze după sine şi o anumite probleme. În cadrul acestei etape pot fi rеlеvаtе sеmnе
dе întrеbаrе sаu chiar anumite oportunităţi cаrе într-o companie pot cаuzа incеrtitudini
аsuprа dirеcţiеi ce ar trebuie urmata. Aceste posibile probleme sau incertitudini sunt
tratate încă din etapa de planificare, astfel fiind eliminate riscurile ce pot pune diverse
piedici pe parcursul implementării planului sau chiar după implementarea lui.
 Implеmеntаrеа – constă în confirmarea faptului că metoda aleasă în vederea colectării
datelor este cea potrivită, deoarece dă rezultate. Întotdeauna etapa de implementare va fi
puternic influențată de etapa anterioară, de planidicare a cercetării.
 Intеrprеtаrеа – această etapă constă în interpretarea informațiilor colectate în contextul
obicetivelor cercetate. Practic, etapa de interpretare reprezintă analizarea datelor și
formularea unor concluzii pe baza lor.
În scopul efectuării aceste cercetări, recoltarea informatiilor a fost efectuată cu ajutorul
metodei sondajului. Chestioarul de 16 întrebări a fost dat spre completare către 70 de
respondenți. Chestionarul a fost aplicat online, respondenții lucrând în domeniul producției de
software dar având funcții diferite.

30
S. D. Șandor, ” Metode și tehnici de cercetare în științele sociale”, pag 50 , disponibil la http://www.apubb.ro/wp-
content/uploads/2011/02/Suport-MTCS-Ro.pdf
31
Săvoiu, G., Grigorescu, R., Asandei, M., Manole, S., (2004). “Cеrcеtаri si modеlаri dе mаrkеting”, Еditurа
Univеrsitаrа, Bucurеști, 2004.
32
Ibidеm

31
 Chestionarul reprezintă acel instrumеnt folosit pentru culegerea datelor de care depinde
reusita oricărei cercetări. Chestionarul conține diverse întrebări cheie, ce sun analizate iar pe
baza lor rezultă îndeplinirea obiectivelor propuse.
În vederea realizării acestui chestionar s-а ţinut seama dе orientarea, obiectivele și
ipotezele cercetării. Întrebările formulate în chestionar sunt unele simple, clare, concise. În
anumire cazuri întrebările pot să lase loc de subiectivism dar fără să influențeze persoana căreia
îi sunt adresate întrebările.
După cum a fost menționat și anterior, chstionarul ce stă la baza acestei cercetări conține
16 întrebări care le permit respondenților să aleagă răspunsul potrivit (Anexa 1).
Еşаntionul este acel аnsаmblu dе unităţi stаtisticе ce sunt еxtrаsе dintr-o anumită
colectivitate, prin mеtodе variate. Principala caracteristică ce ar trebui să fie îndeplinită de
eșantion ar trebui să fie reprezentativitatea, adică mărimеа еşаntionului. Mărimea eșantionului ar
trebui să fie cât mai mare, astfel să poată fi furnizate informații exacte, redundante.
Еşаntionul este format din 70 de persoane, toate cu vârsta mai mare de 18 ani. Întrucât la
întrebarea filtru toate răspunsurile au fost afirmative (toate persoanele care au completat
chestionarul lucrează sau au lucrat în domeniul producției de software), este considerat că toate
răspunsurile pentru acest chestionar au fost eligible în vederea realizării acestei cercetări.
Motivul principal pentru care a fost aleasă cercetarea online, cu ajutorul instrumentului
Google Docs, îl constituie faptul că cercetarea s-a realizat la distanșă, respondenții aflându-se în
mare parte la locul lor de muncă din mai multe locații din București.
Intervalul de timp în care a fost desfășurată cercetarea a fost 15 aprilie – 18 mai 2017.

3.3 Prelucrarea datelor și interpretarea rezultatelor

Pentru a îndeplini obiectivele menționate la punctul 3.1 a fost conceput un chestionar cu

16 întrebări adresate către 70 de angajați din domeniul IT. Pe baza răspunsurilor care au fost
centralizate și analizate s-au putut crea diverse grafice care reprezintă procentual percepția
angajaților din domeniul producției de software cu privire la metodele și tehnicile de lucru
utilizate pentru monitorizarea și controlul calității.
La întrebarea filtru toți cei 70 de respondenți au dat răspuns afirmativ, toți cei 70 au lucrat
sau lucrează la momentul efectuării cercetării de fată în domeniul producției de software pe
diverse poziții.
Obiectivele cercetării de față au fost îndeplinite. Ipotezele de la care s-a pornit au fost
dovedite în urma centralizării răspunsurilor și a interpretării lor.

32
 Analizând figura 3.1, pot afirma faptul că s-a confirmat ipoteza conform căreia, metoda
de lucru Agile este cea mai utilizată. 39 de persoane din totalul de 70 susțin că folosesc Agile, în
timp ce 27 dintre ele folosesc Waterfall. Se pare că în prezent, un procent foarte mic de companii
(5,7%) mai folosesc alte metode de lucru în afară de cele două menționate.

Fig. 3.1 – Cea mai utilizată metodă de lucru din cadrul companiilor de IT
Sursа:originаl

În continuare, pe baza rezultatelor obținute se poate dovedi faptul că angajații care

folosesc metoda de lucru Agile apreciază cel mai mult planificarea activităților care se vor
desfășura în iterația ulterioară și ședințele de status. Putem afirma că angajații acordă o
importanță majoră etapelor de analizare, planificare, retrospectivă a activităților desfășurate în
echipă deoarece, pe o scală de la 1 la 5 aceștia au apreciat etapele menționate începând de la nota
3, cei mai mulți dintre respondenți acordând note de 4 și 5 acestor etape. Faptul că niciun
respondent nu a evaluat cu notele 1 și 2 aceste activități întăresc această afirmație.

Fig. 3.2 – Imporanța acordată etapelorde lucru

Sursа:originаl

33
 După cum se poate observa din figura 3.3, o altă ipoteză a fost confirmată, și anume că
angajații apreciază utilitatea estimării sarcinilor de lucru. Doar 4 din 70 de respondenți,
reprezentând un procent de doar 8,3% sunt de părere că estimarea dificultății sarcinilor nu este
utilă, nu aduce niciun plus de valoare proiectului în lucru.

Fig. 3.3 – Utilitatea estimării sarcinilor

Sursа:originаl

Cea de-a patra ipoteză de la care s-a pornit, și anume că angajașii din domeniul IT
apreciază etapa de testare ca fiind una extrem de delicată și utilă în vederea livrării unui produs
la timp și de calitate, a fost confirmată. Pe o scală de la 1 la 5, 54 de respondenți apreciază
această etapă din procesul de producție ca fiind importantă și foarte importantă. 16 respondenți,
adică 22.9% acordă importanță medie acestei etape. Nicio persoană nu a apreciat testarea ca fiind
inutilă, prin urmare se poate afirma că angajații chiar cred în rezultatele testării.

Fig. 3.4 – Importanța etapei de testare

Sursа:originаl

34
 Ba mai mult decât atât: persoanele chestionate sunt de părere că testarea nu aduce o
creștere inutilă a timpului de livrare a unui produs, ci din contră: scade costul de mentenanță, iar
efectuarea unui plan de testare poate chiar să îmbunătățească relația dintre producător și client. În
plus, respondenții au apreciat faptul că testarea nu poate fi considerată exhaustivă. Oricât de
multe arii ale produsului ar fi acoperite de testare, cel mai probabil tot vor rămâne „corner-cases”
care nu vor putea fi testate din diverse motive: fie nu se cunosc acele zone, fie este asumat că
acele zone nu vor fi atinse.

Fig. 3.5 – Afirmații despre procesul de testare

Sursа:originаl

În aprecierea respondenților, cel mai important tip de testare în procesul de producție

software este testarea de securitate. 52.9% dintre respondenți sunt de părere că testarea de
securitate este cea mai importantă, urmată de testarea de performanță, cu un procent de 30% și
de testarea de stres, cu un procent de 17.1%. Este un lucru bun că și angajații din domeniu
apreciază faptul că securitatea este cea mai importantă pentru client, conștietizând astfel riscurile
care pot apărea în cazul în care se vor strecura anumite vulnerabilități în aplicație.

Fig. 3.6 – Cel mai important tip de testare

Sursа:originаl

35
 O altă ipoteză de la care s-a pornit a fost aceea că cele mai importante elemente de
menționat în momentul înregistrării unui defect sunt pașii de reprodus și prioritatea. Această
ipoteză a fost parțial confirmată întrucât în percepția respondenților pașii pentru reproducerea
unui defect sunt cei mai imporanți (78.6%). Angajații din domeniul IT consideră că prioritatea
unui defect este la fel de importantă ca subiectul detaliat și rezultatele așteptate. Severitatea a
obținut cel mai mic procentaj dintre răspunsurile posibile (48.6%). 14.3% dintre persoanele care
au răspuns întrebărilor din chestionar sunt de părere că mai sunt și alte elemente necesate de
menționat la momentul înregistrării defectelor, și anume: capturi de ecran, date de intrare,
utilizatori.

Fig. 3.7 – Înregistrarea defectelor

Sursа:originаl

Ultima ipoteză de la care s-a pornit, și anume că înregistrarea defectelor este importantă
în primul rând pentru că ajută la o rezolvare mai eficientă iar în al doilea rând pentru că
îmbunătățește vizibilitatea în procesul de producție, a fost confirmată: 38.6% dintre răscpunsuri
au fost pentru rezolvarea rapidă, iar 30% pentru îmbunătățirea vizibilității. De menționat ar fi că
cele mai multe răspunsuri au fost pentru toate varianteșe de răspuns.

Fig. 3.8 – Importanța rezolvării defectelor

36
 Sursа:originаl

În plus, se pare că angajații din domeniul IT sunt de părere că testarea manuală,

tradițională, nu va putea fi în locuită de tesatrea automată. Această apreciere vine cumva în
sprijinul unei ipoteze anterioare: testarea nu este exhaustivă. În condițiile în care manual este
aproape imposibil de acoperit toate ariile unei aplicații sau ale unui program, automat, cu
ajutorul unor scripturi va fi și mai dificil. Scripturile automate sunt create doar pentru anumite
fluxuri din aplicație și este foarte costisitoc ca timp și ca bani să fie întreținute și actualizate în
mod continuu. În plus, utilizând testarea automată se pierde obiectivismul unei ființe umane,
capabilă să privească „out-of-the-box”.

Fig. 3.9 – Va putea înlocui testarea automată pe cea manuală?

Sursа:originаl

În urma interpretării rezultatelor se poate observa faptul că angajații din domeniul IT sunt
în general tineri, cei mai mulți dintre ei (64.3%) încadrându-se în intervalul de vârstă de 25-34
ani. Un singur respondent are peste 45 de ani, fapt care dovedește că generația tânără domină
sectorul IT de la noi din țară.

37
 Fig. 3.10 – Vârsta
Sursа:originаl

În plus, în continuare cei mai mulți angajați din acest domeniu sunt de sex masculin. Doar
17 dintre cei 70 de respondenți sunt femei, restul de 53, adică peste 75% fiind bărbați. Astfel,
echipele mixte sunt din ce în ce mai rare. Se simte nevoia prezenței feminine în producția
software.

Fig. 3.11 – Sex

Sursа:originаl

Principala concluzie formulată pe baza rezulatelor interpretate anterior este aceea că cea
mai utilizată metoda de lucru din domeniul IT este metoda Agile. Ba mai mult: angajații care o
utilizează apreciază eficiența tehnicilor de lucru ce aparțin acestei metode. Se poate afirma că
angajații din acest domeniu pun preț pe calitate, prin urmare remarcă beneficiile pe care pe poate
aduce etapa de testare, efectuată corect și cât mai complet, bazată pe un plan de test bine pus la

38
punct. Încurajează în continuare testarea tradițională, manuală, fiind de părere că scripturile
automate nu pot genera obiectivitatea și atenția unei ființe umane.
O altă concluzie ar putea fi formulată pe baza aprecierii înregistrării defectelor: angajații
din domeniul IT remarcă importanța existenței unui întreg sistem de bugtracking (de înregistrare
a defectelor) în care să fie înregistrare defectele pe baza unui șablon, care să conțină în primul
rând pașii de reprodus ai defectului, iar în al doilea rând subiectul detaliat, rezultatele așteptate și
prioritatea rezolvării defectului. Toate aceste elemente sunt importante de menționat în vederea
rezolvării mai rapide a defectelor de către echipa de dezvoltare și pentru îmbunătățirea
vizibilității în întregimea procesului de producție.
De accentuat ar fi faptul că în continuare în domeniul IT cei mai multți angajați sunt
bărbați, doar un sfert din nuărul total de respondenți sunt de sex feminin. Angajații sunt tineri
entuziaști, proveniți în general din mediul urban ce lucrează în proporție de aproape 100% tot în
mediul urban.

3.4 Propuneri

În urma construirii bazei teoretice a lucrării de față și a analizării și interpretării

rezutatelor cercetării exploratorii consider că am dobândit capabilitatea necesară de a formula
propuneri obiective de îmbunătățiere a metodelor și tehnicilor de lucru din domeniul producției
de software, propuneri bazate pe rezultate concrete și pe surse specializate în domeniul ales.
Deși cea mai utilizată metoda de lucru este metoda Agile, nu înseamnă că este neapărat
cea mai bună, și nici că toate practicile agile se pot aplica în cadrul tuturor companiilor.
Recomand managerilor proiectelor din acest domeniu să conceapă și să aplice metode și tehnici
de lucru care dau randament în cazul lor concret, adică în propria companie, în propriul
departament. Metoda de lucru aleasă depinde foarte mult de tipul de proiect:
 În cazul în care echipa trebuie să livreze tot proiectul o dată iar clientul este unul
mai rigid din punct de vedere al specificațiilor tehnice și funcționale, recomand
utilizarea metodei de lucru în cascadă, Waterfall.
 În cazul în care echipa trebuie să livreze proiectul progresiv, să adauge
funcționalități noi progresiv, pe baza nevoilor clientului și a utilizatorilor,
recomand utilizarea metodei de lucru iterative, Agile.
Faptul că o companie nu utilizează una dintre metodele pe baza căruia a fost realizat acest
studiu, nu înseamnă că respectiva companie nu va da rezultate și nu va livra la timp un program
sigur și de calitate. Indiferent de metodele și tehnicile utilizate, este important ca procesul în sine

39
să fie documentat, să fie procedurizat pentru ca angajații să conștientizeze și să înțeleagă ciclul
etapelor din procesul de producție. Și mai important este ca angajații să înțeleagă impactul pe
care îl poate avea în tot proiectul nerespectarea unei singure etape.
Propun crearea unei proceduri pentru înregistrarea defectelor. Această procedură aș
recomanda să conțină în primul rând următoarele elemente:
 Subiectul detaliat
 Pașii de reprodus
 Rezultatele actuale
 Rezultatele așteptate
 Prioritatea
 Severitatea
 Statusul curent
 Persoana care a înregistrat defectul
 Persoana resbonsabilă cu rezolvarea defectului
Toate aceste detalii ar contribui la scăderea timpului de rezolvare a defectelor.
Pe lângă procedura pentru înregistrarea defectelor recomand și o procedură pentru
explicarea ciclului de viață al unui defect, pentru a evida eventuale blocaje în timpul etapelor de
dezvoltare – testare – punere în producție și pentru a genera date rapoarte cât mai relevante,
bazate pe activitatea reală a angajaților.
Deși a fost dovedit faptul că testarea automată nu poate înlocui 100% testarea manuală,
recomand efectuarea testării automate în continuare și în paralel cu cea manuală. Această
propunere vine în sprijinul ideii că testarea de regresie poate, într-adevăr să fie înlocuită cu
testarea automată. Astfel, pentru regresie, pentru a testa că alte fluxuri din aplicație nu au fost
afectate de ultimele implementări, se poate concepe o suită automată care să ruleze în finalul
dezvoltării. Astfel, se va economisi timp în echipa de testare.
A fost observată o diferentă majoră între numărul de bărbați și numărul de femei care
lucrează în domeniul IT, raportul fiind de 4 la 1. Propun încurajarea femeilor să activeze în acest
domeniu, pentru a omogeniza echipele. Conform site-ului biziday „specialiștii în recrutare susțin
că nu este vorba despre o discriminare sau o reticență din partea patronilor atunci când vine
vorba despre angajarea unei femei pe o poziție tehnică. Pur și simplu bărbații sunt mai des
interesați de o astfel de carieră.” Recomand în părimul rând echipelor de HR să susțină femeile
într-o astfel de carieră. Să acerde mai multă atenție femeilor care aplică CV-ul pe site-ul de
recrutare. În plus, ar putea să publice pe site-ul propriu sau pe paginile le de socializare diverse
articole motivaționale care să atragă femeile în domeniul IT.

40
 Pentru a livra un produs software de calitate, recomand efectuarea a cât mai multe feluri
de testare, care să poată surprinde defectele în diverse faze. Propun implementarea unui proces
de testare pe nivele, care să permită verificarea fiecărei componente în parte a sistemului, apoi a
sistemelor integrate. Cel mai important este ca, în etapa dinaintea punerii proiectului în producție
să se efectueze o testare de sistem, să se verifice comportamentul aplicației cu toate
componentele integrate. Astfel, ar putea fi evitate eventuale probeleme de performanță care pot
apărea în etapa post-producție.
În plus, consider că ar trebui aplicate tehnici de testare cât mai variate, care să implice
testare funcțională dar și non-funcțională pentru a valida că produsul dezvoltat răspunde în
parametri normali indiferent de condiții.
Pentru a asigura transparența necersară pe parcursul desfășurării proiectului și pentru a
încuraja și îmbunătăți comunicarea în cadrul echipelor, dar și comunicarea echipelor între ele,
recomand ședințele zilnice de status în care fiecare angajat să povestească pe scurt ce a făcut în
ziua precedentă, să menționeze eventualele blocaje și să menționeze ce va face în ziua curentă.
Din punctul meu de vedere, comunicarea este cheia către succe, este cea mai importantă la
nivelul oricărei echipe și al oricărei organizații.
Pe lângă ședințele zilnice, sunt de părere că ar fi potrivit ca angajaților să le fie acordat
timpul necesar pentru ședințe de planificare și de retrospectivă. Evident, nu recomand ședințele
în exces, care să îi plictisească pe angajați și care îi fac să le scadă productivitatea, însă susțin
ideea de „brainstorming”. Consider că cele mai bune idei sunt generate în grup, pe urma
dezbaterilor și a părerilor tuturor persoanelor implicate în proiect. Doar acordându-le cuvântul
angajaților putem afla părerile lor, și doar astfel, în calitate de manageri de calitate sa de proiect,
putem lua deciziile potrivite.

CONCLUZII

Nevoia de calitate și de îmbunătățire a proceselor și a tehnicilor este din ce în ce mai

pronunțată. Trăind în era tehnologică, consumatorii sunt din ce în ce mai pretențioși, nevoia de
tehnologie crește este în continuă creștere, iar direct proporțional cu creșterea tehnologiei se află
și creșterea atenției asupra detaliilor. Astfel, este esențial ca în cadrul companiilor producătoare
de software, echipele să adopte diverse metodologii în scopul de a îi ajuta să creeze și să livreze
un soft cât mai bun și cât mai apropiat de cerințele clientului.

41
 Efectuând cercetarea de față am avut ca scop identificarea metodelor și a tehnicilor de
lucru utilizate de angajații din cadrul firmelor producătoare d esoftware în scopul de a monitoriza
și de a controla calitatea.
În prima fază a cercetării am consultat literatura de specialitate din acest domeniu pentru
a mă informa cu privire la metodele și tehnicile posibile, dar și pentru a vedea care este trendul
lor în domeniul IT. Astfel, am făcut o paralelă între cele două cele mai utilizate metode de lucur:
Agile și Waterfall, prezentând punctele esențiale ale metodei itereatile și ale metodei
incrementale.
În cea de-a doua fază a cercetării am consultat literatura de specialitate în vederea
stabilirii tehnicilor utilizate pentru efectuarea controlului calității. Am prezentat informații despre
procesul de testare pentru a exprima astfel importanța lui în procesul de producție, și ulterior am
prezentat beneficiile testării pe niveluri și beneficiile pe care le poate aduce tesatarea dacă sunt
utilizate tehnici variate.
În cea de-a treia fază a lucrării am ales să fac o cercetare a percepției angajaților din
domeniul producției de software cu privire la metodele și tehnicile de lucru utilizate pentru
monitorizarea și controlul calității. Cercetarea are la bază un chestionar care conține 16 întrebări,
ce a fost adresat către 70 de angajați din domeniu. Pe baza răspunsurilor lor am putut să trag
anumite concluzii relevante pentru studiul meu.
O primă concluzie pe baza cercetării efectuate este acea că metodologia de lucru din
cadrul unei companii poate fi una formală sau informală. Consider că nu este neapărat important
care este metoda de lucru utilizată. Cel mai important aspect este ca toate procesele din
metodologia folosită să fie foarte clar comunicate către toate persoanele implicate în activitate,
pentru a asigura astfel și respectarea lor. Cert este că, pentru clienți și pentru utilizatorii finali ai
produselor create, cel mai important aspect este calitatea produselor. Pentru ei nu este important
cum se întâmlă lucrurile, atâta timp cât produsul finit este unul de calitate.
Astfel, o altă concluzie poate fi aceea că, pentru livrarea unor produse de calitate, care să
satisfacă nevoile consumatorilor dar să fie și sigure din punct de vedere al securității datelor este
necesară efectuarea testării pe mai multe nivele și utilizând tehnici variate. Doar astfel clientul
sau utilizatrul poate primi garanția că produsul utiliat este unul conform cerințelor și nevoilor.
Pot afirma că înregstrarea defectelor identificate în faza de testare poate pe de o parte să
scadă timpul de rezolvare a lor, însă de pe altă parte poate îmbunătăți procesul de producție și
vizibilitatea asupra lui, si totodată poate îmbunătăți relația cu clientul.
Am mai concluzionat faptul că, în acest domeniu este nevoie de mai multă forță de
muncă feminină. Raportul de 1 la 4 nu este unul satisfăcător, ci aduce un dezechilibru în cadrul
echipelor.
42
 Concluzia finală a studiului realizat este aceea că domeniul producției de software este
unul complex, în continuă rezolvare, care a devenit esențial existenței umane deoarece în
prezent, întreaga noastră existență are la bază foarte multă tehnologie fie că ne referim la
domeniul medical, domeniul transporturilor, domeniul comunicațiilor etc. România a devenit un
concurent foarte capabil în domeniul producerii de software la nivel internațional. Multe
companii multinaționale optează pentu a-și dezvolta produsele sofware utilizând forță de muncă
românească. Acest lucru se întâmplă în primul rând pentru că raportul calitate – preț al
angajaților români este unul avantajos pentru producătorii străini.

43