Quality Assurance

Testarea QA se realizeaza cu intentia de a gasi si localiza defectee intrun sistem.

 Economisirea resurselor financiare

 Mai bine de gasit buguri inca la analiza cerintelor sau etapa incepatoare de
dezvoltare.
 Foarte importante sunt cerintele.

Asigurarea calitatii reprezinta o prevenire a defectiunii prin inspectia si testarea

procesului.
Testarea periodica asigura ca softul sa fie dezvoltat in conformitate cu cerintele
clientului. Iar daca aplicatia va fi livrata cu defecte va fi mai complicat sa prezicem
cand cor aparea problemele, plus la acesta va fi mai greu sa corectam, scanarea a
sute si mii dde randuri de cod cautand cauza defectului si fixarea lui ulterioara.
De asemenea remedierea/fixarea unui defect poate duce la introducerea/cauzarea
altor defecte ocazionale.

De ce este necesara testare?

1. Este necesara pt. A verifica fiabilitatea (siguranta in aplicare) aplicatiei;

2. Trebuie sa asigure ca sistemul nu contine buguri care pot provoca alte
defectiuni.
3. Trebuie de asigurat ca procesul este dezvoltat in conformitate cu cerintele
clientului.
4. Ca produsul este user friendly
5. Nu conteaza cum designul aplicatiei este proiectat caci QA engineer cu
siguranta vom gasi numeroase defecte dupa ce produsul este dezvoltat si
livrat catre etapa de testare.

Testarea (testing) Quality control vs Quality Assurance

vs
-este un proces de -este mai mult
executare a unui Q. assurance concetrat pe
program cu intentia de gestionarea ciclului de
Q. control
a gasi buguri; viata a produsului si
-Punctul principal nu verifica daca produsul
este de confirmare ca Testing respecta standartele de
nu lucreaza corect, ci calitate definite sau
de a identifica punctele acordurile clintilor.
slabe. -in timp ce QA se refera la -Se focuseaza mai mult
activitati preventive, Q control pe posibilitatea
se focuseaza pe activitati aplicatiei sa functioneze
corective. intrun set de conditii
date.
-Atentia QA este spre
 prevenirea defectelor si
inbunatatirea continua
a proceselor.

Defecte/Bugs- orice ce nu este in conformitate cu cerintele clientului. De multe ori

developerii nu reusesc sa inteleaga cerintele clientului ceea ce duce la erori de
proiectare si dezvoltare.
In afara de aceaste erori defecte pot aparea din cauza unei logice sarace de codare
sau construirea app gresit sau de gestionare gresit a datelor.

 Ciclul de viata a produsului

-Analiza cerintelor (nu are dreptul nici clientul sa modifice cerintele daca sunt
intarite sau daca metodologia de creare asta nu permite.
-Proiectarea;
-Coding/dezvoltarea aplicatiei;
-Testare;
-Livrarea pe piata;
-Mentenanta (Fixarea bugurilor depistate de user la utilizare); Dureaza cat
timp folosim produsul.

Failure – atunci cand o cerinta nu este indeplinita.

Defect/issue/bug/fault- defectiune a aplicatiei.
Error- cauza unui defect sau a unui esec/bug este o eroare emisaa de catre o
persoana/echipa de developeri.
Crash- produsul/ aplicatia nu raspunde si poate fi inchisa doar prin task
manager/ restart.
 Testare/Debugging
Pt a putea corecta un defect sau un bug acesta trebuie localizat in software.
Initial cunoastem efectul unui defect dar nu stim locatia precisa in software
localizarea si corectarea defectelor sunt taskurile pt developeri si adesea sunt
numite debugging.
Testarea are ca scop de a:
1. De a depista esecurile/ defectele;
2. Masura calitatea
3. Executa un program pt a oferi incredere
4. Analiza unui program sau a documentatiai pt a preveni esecurile.

Principiil generale ale testarii:

1. Testarea arata prezenta defectelor, nu absenta lor;

2. Testarea completa nu este posibila;
3. Activitatile de testare trebuie sa inceapa cat mai curand posibile
4. Gruparea defectelor – daca sunt mai multe defecte intro arie , este foarte posibil
ca in acea arie sa fie mai multe si trebuie de analizat toate use case-urile mai
minutios.
5. Paradoxul pesticidelor- daca un defect a fost fixat nu trebuie sa ne focusam pe el
la urmatorul ciclu de testare.

Ce este un proiect?

Un proiect este un proces unic care consta din activitati controlate si coordonate
avand odata de inceput si o data de sfarsit, intreprinse pentru a atinge un obiectiv
(produs sau serviciu) ce corespund cerintelor specificate inclunzand constrangeri de
timp, cost si resurse.

Caracteristici:

1.timp limitat –finalul este atins cand toate obiectivile sunt indeplinite sau
neindeplinite cand proiectul sa oprit.
2. Livrare unica – orice proiect are ca scop sa produca produse livrabile, trebuie sa fie
analizate unicitatea proiectului poate sa difere de la un proiect la altul.
3. Elaborarea progresiva (indreptat spre atingerea scopurilor) – iteratiile succesive su
ca rezultat dezvoltarea unor solutii mai eficiente pt dezvolttarea proiectului.

Managmentul proiectului este disciplina de planificare, organizare, motivare si

control al resurselor pt atingerea obiectivelor specifice ale proiectului.

Principalele provocari a proiectului este atingerea scopurilor si obiectivelor .

Principalele constrangeri:

1. Scopul
2. Timpul
3. Calitatea
4. Bugetul

Rolul persoanelor ce contribuie la dezvoltare:

1. Clientul –o persoana sau managerul ce e responsabil pt asigurarea autorizatiei

clientilor si resurselor proiectului.
Rolul:
-obtinerea bugetului
-semnarea documentului, proiectului de initiere a produsului
-sustinera managerului de proiect in gestionarea de proiect.

2. Managerul de proiect- este persoana responsabila pt indeplinirea obiectivelor

proiectului, asigura ca echipa va finaliza proiectul.
Rolul:
-dezvoltarea planului de proiect;
-furnizarea rapoarte partilor interesate de proiect;
-gestioneaza echipa de proiect;
- gestioneaza riscurilor de proiect;
-gestioneaza programul/agenda proiectului;
-gestioneaza conflictele;
3. Managerul de produs- afla nevoile clientilor si incearca sa le satisfaca. El
defineste obiectivele strategice ce initiaza proiecte unice.
Rolul:
-urmareste programul proiectului si rapoartele despre starea proiectului;
-initiaza decizii critice pt lansare
-oferte de comercializare a produsului;

Diferenta dintre project manager si product manager:

project manager are ca scop finisarea proiectului in bugetul si timpul stabilit.
product manager are ca scop realizarea unui produs de succes.

4. Buissnes analyst- el indentifica nevoile de buissnes si determ. Sol. La prob. De

buissness. Este responsabil pt colectarea si crearea cerintelor pt. Produs si
traducerea lor in specificatii functionale.
Rolul:
-scrierea si gestionarea cerintelor si specificatiilor
-traducerea nevoilor de buissness echipei proiectului;
 -intelegerea buissnesului si crearea recomadarilor pt imbunatatire.

5. Arhitectul de sistem- este un designer a sistemului care trebuie de implimentat.

Rolul:
-proiectarea arhitectura software;
-stabilirea de baza a sistemului
-decide formatele de stocare si protocalele de transmitere a datelor.
-dezvoltarea standartelor de cod;
-ofera viziune tehnica a scopului proiectului;

6. Development- se ocupa de dezvoltarea aplicatiei.

Rolul:
-analiza cerintelor;
-designul sofware;
-codingul;
-participarea la lansarea produsului si la activitati dupa lansare;
-mentenanta sau intretinerea proiectului;

7. Developer leader- el distribuie sarcinile intre membrii echipei, el controleaza

dezvoltarea sarcinilor atribuite, rezolva problemele tehnice si organizatorice ale
echipei.

8. Developerii- creaza produsul, scriu cod.

9. QA (asigurarea calitatii)- se ocupa de asigurarea acuratetii si calitatea produsului

in conformitate cu cerintele proiectului.
Rolul:
-asigura ca sunt respectate standartele si procedurile cuvenite;
-asigura ca problemele sunt gasite si rezolvate;
-verifica daca produsul indeplineste cerintele si functioneaza asa cum trebuie.

10. QA leader- prezenta experientei in asigurarea calitatii.

Rolul:
-dezvoltarea planului de testare;
-intervierea, achizitionarea resurselor de testare;
-selectarea si intoducerea metodelor si strategiilor de testare potrivite;
-organizarea trainingurilor;
-ia decizii asupra mediului de testare si testarii de automatizare.
11. Testerii- sunt responsabile de executarea testelor si raportarea defectelor.
Rolul:
-actualizeaza teste;
-creaza teste;
-previzuie planul de teste;
-documtarea rezultatelor de teste;

12. Automation tester- cunostinte de baza in testare, dar au experienta in

programare.
Rolul:
-automatizarea testelor.

13. OPS (IT operations)- grup de persoane care sunt resp. De suportul tehic a
proiectului si pregatirea mediilor de test.

14. Managerii de release- ei coordoneaza partile sau componentele proiectului si

asigura ca sunt integrate corect. Coordoneaza timpul proiectului si ca proiectul
va fi livrat la timp., de asemenea gestioneaza ca dependentele de viitor nu vor fi
afectate. Interactioneaza cu DevOps, test leads, Ops, project manager.

15. Vendorii (vendors) sunt contractati pt a furniza produse sau servicii suplimentare
pe care proiectul le va solicita.

Cerintele si specificatiile functionale

Cerintele si specificatiile functionale este un document formal utilizat pt a descrie in

detalii pt echipa de developeri- capabilitatile, aspectul si interactiunile cu utilizatorii
al sistemului.

Scopul

De a descrie cerintele care trebuie implimentate de solutia software, este un acord

cu clientul despre cum exact sistemul va arata sau opera este un punct de
sincronizare pt echipa ce lucreaza la proiect si sunt instructiuni pt inginerii cu privire
la ce se va elabora.

Cerintele definesc o forma a functiilor a unui produs software si anume ce sistemul

ar trebui sa analizeze sau ce doreste clientul.

Specificatiile functionale definesc functiile necesare pt satisfacerea nevoilor

clientului.
Cerintele functionale vs cerintele non-functionale

cerintele non-functionale descriu modul cum sistemul trebuie sa functioneze.

Cerintele functionale descriu ce trebuie sa functioneze.

Testarea functionala se refera numai la cerintele functionale si acopera, asigura cat

de bine sistemul indeplineste functiile si realizeaza folosind specificatiile
functionale.

Testarea non-functionala- se bazeaza pe cerintele non-functionale este conceputa

pt a evalua pregatirea unui sistem in conformitate cu diverse criterii care nu sunt
acoperite de testarea functionala.

Cerintele Testarii non-functionala:

 Sistemul trebuie sa fie usor de utilizat

 Sistemul trebuie sa suporte: MacOS, Linux, Windows;
 Sistemul trebuie sa suporte fisiere deschise concomitent;
 Sistemul trebuie sa fie rapid.

Cerintele Testarii functionale:

 Sistemul trebuie sa puna la dispozitie abilitatea sa se inregistreze online;

 Sistemul trebuie sa puna la dispozitie introducerea datelor prin interpolarea
fisierelor si introducerea de la tastatura.
 Sistemul trebuie sa puna la dispozitie abilitatea de a monitoriza activitatile
utilizatorului

Testarea functionala:

1. Unit testing;
2. Integration testing;
3. Testarea de regresi

Testarea non-functionala:

1. Testarea de performanta
2. Security testing
3. Stress testing cu volume mari.
 Ce este testare dinamica si statica?

Testarea dinamica are loc atunci cand codul este executat, ea verifica
comportamentul functional, procesorul, memoria...

Nivelurile tehnice:

1. Testarea unitatilor
2. Testarea de integrare
3. Testarea de acceptare
4. Testarea de sistem

Testarea statica este atunci cand codul nu este executat.

Consta din 2 parti:

1. Revizuirea
2. Analiza statica

Revizuirea este utila pentru a gasi si a elimina defectele din documente precum
cerinte specifice functionale, design, cazuri de teste.

Analiza statica este utila pentru a analiza codul scris de developeri deobicei prin
document. Are scopul de agasi defectele structurale ale codului ce pot duce la
defecte functionale ale aplicatiei.

Revizuirea este un mijloc eficient pentru asigurarea calitatii documentelor si in mod

ideal treb efectuat cat mai curand posibil.

Avantajele:

1. Eliminarea defectelor
2. Timp de dezvoltare scurt
3. Daca defectele sunt gasite si corectate din timp, costul timpului pentru
executarea testelor dinamice scad, deoarece sunt mai putine defecte in
sistemul ce se testeaza.

Tipuri de revizuire:

1. Inspectia(formala)
2. Revizuirea tehnica
3. Parcurgerea
4. Revizuirea informala
  Inspectia este un proces formal prescris, fiecare persoana implicata are un rol
definit, regulile definesc procesul.

Obiectivele:

Gasirea elementelor neclare posibil defecte, masurarea calitatii obiectivului de

revizuire, inbunatatirea calitatii procesului de inspectie si a procesului de dezvoltare.

O revizuire consta din urmatoarele etape:

1. Planificare –conducerea trebuie sa decida ce documente din procesul de
dezvoltare a aplicatiei trebuie sa fie revizuit in avans.
In timpul planificarii revizuirii idividuale conducatorul selecteaza personalul
competent si formeaza echipa de revizuire.
2.Conducerea -
-se ofera informatii celor implicati in revizuire
-are loc printr-o invitatie
-scopu este schimbul informatiei despre documentul ce urmeaza sa fie revizuit.
3.Pregatirea individuala- membrii echipei studiaza intens obiectul de revizuire.
4.Reunirea de revizuire-obiectul este de a decide daca obiectul revizuit a indeplinit
cerintele si respecta prevederile sau standartele.
5.Reelaborarea-dupa sedinta de revizuire autorul va inlatura defectele pe baza
rezultatelor revizuite si va reedita documentul.
6.Monitorizarea- daca rezultatul primeste revizuiri se va programa o alta revizuire.

 Revizuirea tehnica – accentul este pe conformarea documentului cu

specificatii.
Membrii trebuie sa fie calificati tehnic;
Sedintele pot fi petrecute atat formale cat si informale.

 Parcurgerea- e metoda de revizuire manuala cu scopul de a gasi defecte.

Aceasta tehnica se utilizeaza pt. Echipe mici pana la 5 persoane.

 Revizuirea informala –este o versiune usoara adesea nu este nici o intalnire

sau schimb de constatari. Implica un efort relativ redus si costuri reduse.
Tehnici de testare:

Exista mai multe tehnici de elaborare a test case-urilor

1. White Box

2. Black Box

3. Grey Box

White Box

Testarea WB se testeaza in profunzime pana la nivelul de cod sursa al aplicatiei

In acest tip de testare, logica interna ,implementarea si functionarea sunt examiante. Test Cases au
rolul de a verifica cum aplicatia va functiona la nivel intern. Aceasta forma de testare nu verifica lipsa
cerintelor sau a specificatiilor. In WB testerul are acces la codul sursa spre deosebire de BB unde el nu
are acces la codul sursa.

Black Box

Se concentreaza numai pe functionalitatea software sau aplicatiei. Testerul nu examineaza datele

interne ale aplicatiei, el se concentreaza doar pe ceia ce se presupune ca aplicatia realizeaza. Nu se
focuseaza cum aplicatia gestioneaza functiile interne si cazurile de test sunt create avand in vedere de
cerinte si specificatii.

5 medote Black Box Testing:

1. Equivalence partitioning

2. Boundary value analysis

3. Decision table testing

4. State transition testing

5. Use case testing

Equivalence partitioning

O clasa de echivalenta este un set de valori de date pe care testerul le presupune ca sunt procesate in
acelasi mod de obiectul care este testat.

Testarea a unui reprezentant al clasei este considerata suficient deoarece se presupune ca pentru
orice ca pentru orice alta valoare de intrare ale aceleiasi clase de echivalente obiectul testat va arata
celeasi reactii sau comportament.

Pe langa testarea claselor de chivalenta cu introducerea datelor corecte trebuie de testat clasele de
chivalenta cu date incorecte.

Exemplu:

Sa presuunem ca aplicatia accepta un sir de numere de la 100 la 999.

 Valide: 100-999

Invalide: > 100 - 999 <

Boundary Values analysis

Defectele deseori apar la granitile claselor de echivalenta. Aceasta se intqampla deoarece granitile nu
sunt deseori clar definite sau sunt intelese gresit. Se verifica granitile claselor de echivalenta si se
testeaza:

1. Valoarea exacta

2. Ambele valori adiacente(una din diapazon, alta din afara)

Exemplu:

Un examen se socoate sutinut daca rezultatul e:

50% - nota 8

75% - nota 9

85% - nota 10

Valorile limita : 49, 50, 51 ...

49 - nota 7, iar 50 - nota 8

74 - nota 8, iar 75 - nota 9

Decision Table
Daca avem date de intrare diferite care au ca rezultat actiuni diferite sau avem o regula de business
care testeaza daca exista o combinatie diferita de date de intrare care realizeaza actiuni diferite atunci
folosim tabelul de decizie.

Politica de salarizare Reguli H - salariu pe ora

1 2 3 4 S - salariu pe lunar

1. Tipul de angajat S H H H conditii

2. Nr de ore lucrate - <40 40 40>

1. Achita salariu lunar +

2. Achita salariu ora + + +

3. Se achita overtime +

4. Fisa de absente +

State transition testing

In multe sisteme nu doar intrarea curenta ci si istoria de executie sau evenimente sau intrari
influenteaza calculul rezultatelor si modul in care se va comporta sistemul.

Diagrama de stare:

Starea actiunea

Obiectul trece de la o stare la alta atunci cand tranzitia se declanseaza sau are lo cun eveniment ce
are loc in domeniul probleme.
Testerii pot utiliza cazuri de testare pentru a obtine test cases.

Diagramele de caz se folosesc pentru a arata sistemul din punctul de vedere al utilizatorului sau
relatia lui cu altea sisteme.
Grey Box Testing

Se foloseste cand metodologiile White Box si Black Box sunt utile in combinatie.
Aceasta forma de testare va analiza atat partea functionala cat si codul sursa.
Testerul are cunostinte de baza in programare. Pentru proiecte mari este bine de
incorporat atat WB cat si BB testing.

1. Test Case - introducem pas cu pas cum trebuie de testat o cerinta, specificata
bazata oe functionalitatea aplicatiei. Scopul este de a valida o anumita
functionalitate sau integritate intre componentele aplicatiei si alte servicii ale
aplicatiei..

Validarea unei functionalitati inseamna ca testerul trebuie sa se asigure ca

comportamentul aplicatiei corespunde cerintelor ca urmare a actiunelor
intreprinse.

Tipuri de test cases:

1.negative
2.pozitive

Testarea negativa- sistemul e validat pe baza datelor de introducere nevalide. UN

TEST CASE negativ verifica daca aplicarea se comporta asa cum este de asteptat cu
intrebarile sale negative.

Scopul:
de a verifica daca aplicatia nu afiseaza eroarea atunci cand nu se presupune sa
afiseza eroare cand se presupune ca eroarea trebuie afisata.

Exemple avem 2 cerinte:

1.Id trebuie sa aiba un nr. Cuprins intre 1 si 250

2.Id este obligatoriu.

Scenariu pozitiv:

-Introducem o valoare valida, cuprinsa intre intervalul specificat -12

-Introducem valoarea limita pozitiva a intervalului specificat- 1 si 250.

Scenariu negativ:

-introducem text in loc de numar- abc;

-Introducem valoarea limita invalide- 0 si 252;
-introducem o valoare valida cu prefix- +56;
-introducem NULL;

Scenariu de test vs caz de test

Scenariu de test- (Test case Scenaria) scopul este de a testa functional end-to-end a
unei aplicatii si de a asigura ca procesele si fluxurile de buissness functional corect.
Testerul indentifica cazurile de utilizare care pot fi realizate. O data ce acestea
scenarii sunt determinate pt. Fiecare scaneriu. Scenariile de testare sunt coceptia
high-level (superficiala) la ce trebuie de testat.

Test case(caz de test) –un set de pasi ce trebuie de executat de catre tester pt. A valida
scenariul.

Scenariul de testare sunt derivate din caz de testare.

Caz de utilizare

Scenariu de test

Cazuri de test

 Scenarii de test sunt derivate din cazurile de utilizare iar cazurile de test din scenario de
test.
Scenarii de testare de obicei are mai multe cazuri de test associate lui de . Cazult de test
reprezinta detalii la nivel LOW level (detaliat) privind modul de testare al scenariului.

-Scenariul- ce trebuie sa testam.

-Test case- pasii concreti.

 Cum sa scrim un test case:

1. Folosim diateza active (spunem ce trebuie sa faca)
-Do this
-Enter that
2. Folosim forme exacte (denumiri de forme)
3. Scopul exact
4. Fara cuvinte in plus
5. Poate fi refolosit daca este necesar.
Defecte - o defectiune a unui program care determina un comportament incorect, defectul este gasit
atunci cand aplicatia nu corespunde cu cerintele specificate.

Cauza aparitiei defectelor:

1. Factorul uman

2. Specificatiile incomplete

3. Esee in comunicare la diferite nivele

- Stadiul de colectare a cerintelor

- Etapa de documentare

- Etapa de traducere a cerintelor la etapa de implementare

4. Eroare in logica de proiectare, aplicarea gresita a tehnoogiilor, a compnentelor poate duce la

erori sau defecte

5. Practici slabe de programare

6. Testarea incompleta sau incorecta

7. Schmbari in ultimele etape

8. Probleme de configurare ale mediului

Bugtracking -urmarire de defecte, sistem de urmarire.

Atributele unui defect:

1. Defect ID

2. Summary

3. Defect description

4. Product version

5. Detailed steps - pasii de reproducere a defectului

6. Actual result - defect propriu zis

7. Expected result

8. Notes

9. Platforma

10. Attachements

11. Specification ID
 12. Date raised

13. Reported by

14. Status

15. Fixed by

16. Date closed

17. Severity - cat de sever este bug-ul

18. Priority - Cat de urgent trebuie fixat

Severity Priority

- Critical - Immediate

- Serious - High

- Moderate - Medium

- Inconvinience - Low

Ciclul de viata al unui defect:

New -> Open -> Fixed -> In Test -> Verified ->( Closed || Re-open)

Open -> Rejected

-> Deffeded -> Closed

-> Enchangement

-> Duplicated

Ciclul de viata a produselor software:

Fiecare proiect de elaborare softwere trebuie planificat si elaborat folosind un model de ciclu de viata
ales in avans. Lipsa unei organizari bine structurate va duce la costuri suplimentare necesare pentru
realizarea proiectului. Ciclul de viata a unui soft este o secventa binedevinita si structurata in etape.

Etapele CVPS:

1. Initiation - pasul cand utilizatorul initiaza cererea pentru soft dorit el conecteaza furnizorii si
negociaza termenii.

2. Analysis and planing - etapa de analiza a dezvoltarii soft, implica definirea obiectivelor
proiectului ca functii.

3. Requirements and specifications - cerintele sunt colectate, aceasta este principalul obiectiv al
managerului de proiect si partilor interesate. Se organizeaza intalniri cu managerul si partile
interesate pentru a determina asa cerinte
 - Cine foloseste sistemul?

- Cum vor folosi sistemul?

- Ce date vor fi introduse? ...

4. Design - proiectarea sistemului este efectuata conform cerintelor si specificatiilor

5. Development - la primirea documentului de proiectare a sistemului, lucrarea e impartita in

module si unitati si se incepe elaborarea codului. Aceasta este cea mai lunga faza a ciclului de viata a
dezvoltarii prodului soft.

6. Testing - dupa dezvoltarea produsului soft acesta este testat conform cerintelor pentru a
asigura ca produsul indeplineste cerintele initiale adresate.

7. Delivery - dupa test cu succes produsul este livrat clientilor

8. Maintance/Support - odata ce produsul e livrat clientilor pot aparea probleme care necesita
solutionate.

Modelul Waterfall - a fost primul model introdus. E un model liniar secvential al ciclului de viata este
simplu inteles si utilizat. Fiecare faza trebuie finalizata complet inainte de a se trece la urmatoarea.
Testarea incepe abia dupa finalizarea dezvoltarii.

Schema Waterfall:

Requirement Specification -> Functional Specification -> Technical Specification -> Program
Specification -> Development -> Testing

Avantaje:

- Simplu si usor de utulizat

- Usor de gestionat datorita rigiditatii sistemului

- Fazele sunt procesate si finalizate pe rand

- Functioneaza bine pentru proiecte mai mici unde cerintele sunt bine determinate

Dezavantaje:

- Odata ce aplicatia este in etapa de testare este foarte dificil sa ne intoarcem si sa modificam
ceva e nu a fost bine gandit

- Nu se produce soft pana la etapele tarzii ale ciclului de viata

Cand utilizam acest model:

- Atunci cand cerintele sunt clare si bine definite, tehnologiile sunt bine intelese, cand scopul
proiectului etse stabil si cand proiectul este scurt.
Model V:

- Sarcinile de dezvoltare si testare au aceiasi importanta unde ramura stanga reprezinta procesul
de dezvoltare, iar dreapta procesul de testare si integrare

- In program specific definim fiecare sublistem utilizand task, compartiment si interfata legate cu
alte subsisteme

Avantaje:

- Sipmlu si usor de utilizat

- Activitati de testare asa ca:

Planificarea

Crearea testelor

Au loc inainte de coding ceia ce salveaza mult timp

- Defectele sunt gasite la etape timpurii

Acest model functioneaza cand cerintele sunt usor de inteles

Dezavantaje:

- Rigid si mai putin flexibil

- Daca au loc schimbari documentele pentru testare trebuie modificate

Model Spirala

Proiectul trece in mod repetat prin aceste faze in iteratiinumite spirale, spirala de baza incepand cu
etapa de planificare. Se aduna cerintele si se evalueaza riscul. Fiecare spirala urmatoare se
construieste pe spirala de baza.

Etapele:

1. Planificarea cerintelor

2. Analiza si proiectarea riscului - identificarea riscurilor si solutiilor alternative

3. Inginerie si coding - softul este dezvoltat impreuna cu testarea

4. Evaluarea - permite clientului sa evalueze aplicatia pana in momentul curent inainte ca

proiectul sa continuie la urmatoarea spirala

Avantajele:

- Cantitatea ridicata de analiza a riscurilor duce la evitarea lor

- Model bun pentru proiecte mari si misiuni critice

- Functionalitate suprimentara poate fi adaugata la o etapa mai tarzie

- Softul este produs la inceputul ciclului de viata

Dezavantaje:
 - Poate fi un model costisitor

- Analiza riscului necesita expertiza extrem de specificata

- Nepotrivit pentru proiecte mici

Testarea non-functionala - de obicei orice testare care nu are legatura cu testarea functionalitatii este
definita ca non-functionala.

La testarea non-functionala se testeaza caracteristicile calitatii componentelor sau sistemului.

Tiuri de testare non-functionala:

1. Load testing - verificam posibilitatea sistemului de a incarca mai multi utilizatori in acelasi
timp(Ex. Se conecteaza 100 de persoane concomitent la site)

2. Fault tolerance testing - verificam daca sistemul poate functiona dupa o eroare soft sau
hardware.(Ex. Oprirea unui server si verificarea daca site lucreaza)

3. Security testing - verificam daca sistemul nu are vulnerabilitati(Ex. Utilizatorul nu poate accesa
o pagina fara autentificare)

4. Operability testing (Maintenance) - verificarea unor proceduri de intretinere a sistemului

intern. (Ex. Repornirea serverilor, arhivarea logg-urilor, backup-uri)

5. Usability testing - cat de user-friendly este interfata sistemului(Ex. Cantitatea de clicuri pentru
a efectua ceva actiuni)

Load testing:

1. Performance testing - testarea sistemului sub incarcatura

2. Soak testing - comportarea sistemului in timpul unei incarcaturi indelungate (ex. 24 ore)

3. Stress testing - testarea componentelor sub incarcatura extrem de mare

Load testing de obicei nu se executa manual, sunt instrumente specifice pentru a emula
incarcatura.(HP performance testing)

Key Performance Indicators:

1. Response time - timpul in care utilizatorul simulatiei va astepta raspunsul programului

2. Utilizatori concurenti maxim suportati - reprezinta cantitatea maxima care paote lucra in
sistem

3. Suma maxima de tranzactii pe minut acceptata

4. Utilizarea resurselor - utilizarea resurselor de catre sistem in timpul efectuarii testelor

Fault tolerance testing:

 1. Failover / Resiliency testing - ceva local e defectat

2. Disaster recovery testing - cand centrul de date e defectat complet

Indicatorii de Pass / Failed:

1. Timpul luat pentru reactivare

2. Pierdere de date - cantitatea de date care va fi pierduta din cauza procesului de reancarcare

3. Efectul asupra performantei sistemului - ce va fi cu performanta in timpul reactivarii

Modelul Agile - un model implementat unde aplicatia este dezvoltata in cicluri incrementare, rapide.
Aceasta duce la mici versiuni incrementale, fiecare versiune e elaborata pe versiunea anterioara,
fiecare versiune este complet testata. E util pentru operatii critice de timp.

Caracteristicile:

1. Lucru in echipa si colaborare pe tot ciclul de viata al proiectului

2. Descompunerea sarcinilor in pasi mici cu o planificare minima

3. Fiecare echipa va contine un reprezentan din partea clientului si la sfarsitul fiecarei iteratii se
va revizui procesul, se vor reevalua prioritatile cu scopul de optimizare

4. Intaliri zilnice pentru a discuta statusul. Membrii vor discuta ce sa facut ieri si ce e planificat
astazi si daca sunt probleme ce impiedica lucrul

Metode Agile:

- Scrum

- Expreme programming

- Crystal Clear ...

Avantaje Agile:

1. Satisfactia clientului prin dezvoltare rapida si continua a aplicatiei

2. Interactiune intre membrii echipei

3. Sistemul e functional de la inceputul dezvoltarii

4. Cooperari cointeresati de acest business

5. Schimburi tarzii in ceerinte sunt binevenite

6. Adaptarea la schimbarea circumstantelor

7. Comunicarea face-to-face este cea mai buna

Dezavantaje Agile:
 1. Documentatie saraca

2. Pentru app mai e dificil de a evolua suportul necesar la inceputul ciclului de viata

3. Proiectul poate sa ia o directie gresita daca reprezentantul di partea clientului nu este

clar despre rezultatul final dorit

4. Doar programatori cu experienta pot lua decizii

Scrum

- un cadru de dezvoltare soft iterativ si incrementat pentru gestionarea proceselor.

- un sprint este unitate de baza de dezvoltare in scrum. Este un efort limitat la o durata specifica.

- pasii procesului :

1. Clientul creaza lista cu cerinte si prioritate numita backlog

2. In tjmpul planificarii sprintului exhipa extrage cateva cerinte din aceasta lista si decide
cum sa le implementeze.

3. Echipa are definit un timp limitat pentru a finaliza task-urile(se organizeaza intalniri
pentru a vedea progresul daily Scrum)

4. Scrum master are grija ca echipa sa fie focusata pe task-uri

5. Sprint-ul se finizeaza cu sprint review si retrospectiva

6. Cand urmatorul sprint incepe scrum masterul va alege alte taskuri din backlog

Nivele de testare:

1. Unit testing

2. Integration testing

3. System testing

4. Acceptance testing

Unit testing:

- codul este scris in parti componente sau unitati

- unitatile sunt construite izolat pentru a fi integrate mai tarziute- e destinat pentru a verifica
daca codul scris pentru unitate corespunde specificatiilor

- e realizat de developeri care au scris codul

- defectele gasite sunt fixate si adesea neraportabile

Integration testing:

- dupa creare unit testing modulele sunt unite pentru crearea sistemului

- scopul este de a expune defectele dintre interfete si din componente

- Structura metodei de testare a integritatii include BottomUp Integration(structura

arborescenta de jos in sus)

Avantaje:

1. Dezvoltarea si testare pot fi executate iimpreuna

2. Observare rezultatului de test este mai usoara

3. Conditii de test usor de creat

Dezavantaje:

1. Programul ca un tot integ nu exista pana cand ultimul modul nu va fi adaugat

2. Putem gasi defecte in interfata la sfarsit

TopDown Integration:

- sistemul e construit in etape incepand cu componentele care cheama alte componente

Dezavantaje:

1. Functionalul de baza e testat la sfarsitului ciclului

BigBang Integration(toate unitatile sunt conectate simultan)

Avantaje:

1. Totul e finisat inainte ca testarea de integrare sa inceapa

Dezavantajele:

1. In caz de depistare a defectelor e dificil de a descompune componentele si a gasi cauza

2. Sansa de a vea defecte critice e mare deoarece componentele sun integrate simultan

System testing

- odata ce testarea de integrare e finisata trecem la testarea sistemului, el fiind deja functional si
integrat cu toate componentele

- scopul este de ane asigura ca sistemul e in conformitate cu specificatiile functionale si tehinice

si cu standartele definite de organizatie

- testarea de sistem este blackbox

 - testarea se realizeaz din punct de vedere al utilizatorului

- testraea investigheaza cerinte functionale si non-functionale

- tipuri de System Testing

Testarea functionala este un tip de blackbox testing unde test case sunt elaborate pe baza
specificatiilor. Acest tip de tesatre verifica daca sistemul e in corcondanta cu cerintele clientului.

Trebuie sa verificam:

1. Functionalitatea pe care trebuie sa o execute app

2. Sa avem un set de date corect(valide si invalide)

3. Test cases acopera toate scenariile posibile

4. Rezultatul actual trebuie sa fie fixat si verificat conform rezultatului asteptat

5. Datele introduse si comportament app dupa introducerea acestor date trebuie sa fie verificat
pe baza specificului functional

Regresion testing - dupa detectarea unu defect in sistema el e trimis catre fixare. Odata ce el e fixat e
necesar de a testa intens pentru a asigura schimbarile efectuate nu au afectat alte functionalitati, alte
regiuni sau logica business. Testarea de regresie duce la reducerea golurilor in procesul de testare,
asigura ca aplicatia nu contine defecte inainte de a fi trimisa la urmatoarea faza de testare.

Performance testing - e efectuata pentru a determina cat de rapid se executa anumite aspecte ale
sistemului sub o anumita sarcina de lucru, poate demonstra ca sistemul indeplineste criteriile de
performanta.

Stress test - testarea dincolo de capacitatea operationala normala, adesea pana la un punct de rupere
break point pentru a se observa rezultatele se utilizeaza pentru a determina stabilitatea unui sistem.
Pune accent pe disponibilitate, gestionarea erorilor si puterea fizica a sistemului in conditii de
incarcarea grea . Obiectivele sunt de a demonstra ca sistemul nu face crash in conditii de resurse
insuficiente.

Portability testing- testeaza cat de usor poate fi mutata o componenta a aplicatiei sau aplicatia in alt
mediu.

Sequrity testing - testam securizarea aplicatiei, daca sistemul protejeaza datele si functionalitatea asa
cum e prevazut.
Recovery testing - verifica cat de repede putem restabili aplicatia dupa orice tip de crash sau defect
hardware.

Usability testing - testam usurinta cu care poate fi utilizat produsul, cat de usor poate fi testat.

Maintability testing - defineste cat de usor este mentinerea sistemului si cat de usor este analiza,
schimbarea si testarea aplicatiei.

Stability testing - pentru a determina daca sistemul indeplineste cerintele de fiabilitate.

Smoke tesing - asigura ca functiile majore functioneaza corect, e un tip de testare cu test case foarte
limitat pentru a asigura ca functiile importante functioneaza si putem trece la testare detaliata, poate
fi realizatat de developeri inainte de a transmite codul la testare. E realizat de testeri pentru a asigura
ca versiunea e suficient de stabila pentru testare avansata. E efectuata mereu cu scenarii pozitive.

Avantaje:

1. Ajuta la gasirea obiectelor de la testarea timpurie

2. Ajuta la depistarea defectelor care au aparut la integrarea componentelor

3. Un numar limitat de test case necesar

4. Poate fi executat in timp foarte scurt

5. Ajuta la verificarea defectelor care deja sunt fixate

Dezavantaje:

1. Nu copera testarea detaliata

2. Din cauza nr de test case min nu ne permite de a gasi alte defecte critice

Acceptance testing - este una din etapele finale de testare a unui siste de catre utilizatori. Rezultatele
acestor tipuri de testare ne da incredere crilentilor ca cum sistemul va functiona.

Tipuri de testare:

1. User acceptance testing se focuseaza pe capacitatea de utilizare a sistemului, e

fecectuata de utilizatori si manageri de aplicatie.

2. Operational acceptance testing - testarea produsului live e fectuata de administratorii de

sistem inainte ca sistemul sa fie realizat. Aceasta poate include testarea back-up si a tstelor de
mentinere.
 3. Contract acceptance testing - e executata pe baza criteriilor de acceptare a
contractului.

4. Compliance acceptance testing - se realizeaza in conformitate cu reglemenarile ce

trebuie testate (alfa si beta)

Mai intai se exec alfa apoi beta testing. Alfa asigura ca produsul are calitatea asteptata.

Beta are scopul de a imbunatati calitatea produsului si verifica cerintele clientului. Se

utilizeaza scenarii reale.

Exploratory testing - are loc explorarea sistemului, testerul singur ia decizii despre ce trebuie testat, e
binevenit cand avem specificatii sarace si timp limitat. Executarea e efectuata in paralel cu crearea
test case fara documentare formala.

End-to-end testing - testarea completa a app bazata pe procese buisness reale asa ca interactiunea cu
DB, alte aplicatii si componente hard

Experience based techniques - cunostintele, abilitatile si experienta testerilor este de a importanta

majora in cazuri de testare.

Exp ambelor persoane e necesara cu cunostinte tehnice si de buisness din cauza exp anterioare, cu
sisteme similare, ei pot avea idei despre ce poate fi incorect ceia ce ajuta la testare.