irea Procesului de Testare folosind Tehnologiile Agile COORDONATOR ȘTIINȚIFIC: ABSOLVENT: Conf. Univ. Dr. Viorel Ionescu Popa Dan-Valentin SESIUNEA… [611968]
UNIVERSITATEA “TITU MAIORESCU” DIN BUCUREȘTI
FACULTATEA DE INFORMATICĂ
LUCRARE DE LICENȚĂ
Îmbunătă
ț
irea Procesului de Testare folosind
Tehnologiile Agile
COORDONATOR ȘTIINȚIFIC: ABSOLVENT: [anonimizat]. Univ. Dr. Viorel Ionescu Popa Dan-Valentin
SESIUNEA IUNIE/IULIE
2020
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Cuprins
1.
Testare software
4
1.1 De ce conteaz
ă
testarea software-ului
4
1.2 Ce este testarea software
4
1.3 Defecte
ș
i e
ș
ecuri
5
1.4 Combina
ț
ii de intrare
ș
i precondi
ț
ii
5
1.5 Scopul
6
1.6 Ce este SDLC
6
1.6.1 De ce sa folosesti SDLC
7
1.6.2 Caracteristicile SDLC
7
1.7 Ce este STLC
7
1.7.1 De ce sa folosesti STLC
8
1.7.2 Caracteristicile STLC
8
1.8 Diferen
ț
e dintre SDLC
ș
i STLC
8
1.9 Metodologia Agile
8
1.10 Impactul Agile in testare
9
2.
Metodologia Agile
10
2.1 Despre Metodologia Agile
10
2.2 Ce înseamn
ă
s
ă
test
ă
m într-o echip
ă
Agile
10
2.3 Agile nu este potrivit pentru toate organiza
ț
iile
10
2.3.1 Tipuri de Metodologii Agile
11
2.3.2 Metodele de testare Agile
14
2.3.3 Cum s
ă
alinia
ț
i testarea cu un proces de livrare Agile
19
3.
Metodologia SAFe
20
3.1 Ce este Scaled Agile Framework (SAFe)
20
3.1.1 De ce sa folosesti Agile Framework
20
3.1.2 Cand se folose
ș
te Scaled Agile Framework
21
2
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
3.1.3 Cum se diferen
ț
iaz
ă
de alte practici Agile
21
3.2 Funda
ț
ia Scaled Agile Framework
22
3.2.1 Principiile SAFe Lean-Agile
22
3.2.2 SAFe Agile – Valori de baz
ă
22
3.2.3 Liderii Lean Agile
23
3.2.4 Modul de gandire in Agile
23
3.3 Manifestul Agile
25
3.3.1 Nivelul echipei
26
3.3.2 Nivel de program
27
3.3.3 Nivelul portofoliului
28
3.3.4 Nivelul fluxului valoric
29
4. Testarea
ș
i calitatea în cadrul SAFe
30
4.1 Calitate la nivel de echip
ă
30
4.2 Calitate la nivel de program
31
4.3 Calitate la nivel de portofoliu
33
4.3.1 Definirea temelor strategice cu un accent pe calitate
33
4.3.2 Prioritizeaz
ă
conformitatea Epice-lor
34
4.4 Un rol pentru testeri, manageri de testare
ș
i al
ț
i profesioni
ș
ti de calitate
34
5. Crearea unui Framework de testare automat
ă
35
5.1 Alegerea unui limbaj de programare
35
5.2 Alegerea unui Unit Test framework
36
5.3 Arhitectura framework-ului: Page Object Model
ș
i Page Factory
38
5.4 Exemplu proiect: Page Object Model
ș
i Page Factory
41
5.5 Alegerea unui mecanism de raportare
48
5.6 Implementarea Docker
49
5.7 Implementarea Selenium Grid
51
5.8 Implementarea cu GitHub pentru controlul versiunilor
53
5.9 Implementarea CI / CD
55
3
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
1.
Testare software
1.1 De ce contează testarea software-ului
Testarea
este
o
parte
vitală
a
întregului
proces
de
dezvoltare
software.
Fără
aceasta,
companiile
au
mai
multe
ș
anse
să
livreze
produse
de
calitate
slabă,
dificil
de
utilizat,
predispuse
la
erori
ș
i
chiar
vulnerabile la amenin
ț
ările de securitate.
În
cel
mai
rău
caz,
e
ș
ecul
de
a
testa
ș
i
apoi
furniza
produse
inferioare
poate
aduce
prejudicii
grave
reputa
ț
iei
unei
companii.
De
asemenea,
poate
face
clien
ț
ii
să
se
gândească
de
două
ori
la
cumpărarea
produselor companiei.
Testarea
a
fost
mult
timp
o
parte
cheie
a
ciclului
de
via
ț
ă
al
dezvoltării
software,
dar
abordarea
testării
suferă
modificări
fundamentale.
Una
dintre
cele
mai
mari
tendin
ț
e
este
folosirea
Metodei
Agile
pentru
procesul de testare ca înlocuitor al metodelor tradi
ț
ionale de testare.
1.2 Ce este testarea software
[1]
Este o investiga
ț
ie realiza tă pentru a oferi păr
ț
ilor interesate informa
ț
ii despre calitatea produsului sau
serviciului software testat. Testarea software poate oferi, de asemenea, o viziune obiectivă
ș
i
independentă a software-ului pentru a permite companiei să aprecieze
ș
i să în
ț
eleagă riscurile
implementării software-ului. Tehnicile de testare includ procesul de executare a unui program sau a
unei aplica
ț
ii cu inten
ț
ia de a găsi bug-uri
[2]
software (erori sau alt e defecte)
ș
i verificarea dacă
produsul software este potrivit pentru utilizare.
Testarea software implică executarea unei componente software sau a unei componente de sistem
pentru a evalua una sau mai multe proprietă
ț
i de interes. În general, aceste proprietă
ț
i indică măsura în
care componenta sau sistemul testat:
●
îndepline
ș
te cerin
ț
ele care au ghidat proiectarea
ș
i dezvoltarea acestuia;
●
răspunde corect la tot felul de intrări;
●
î
ș
i îndepline
ș
te func
ț
iile într-un timp acceptabil;
●
este suficient de utilizabil;
●
poate fi instalat
ș
i rulat în mediile propuse;
●
realizează rezultatul general dorin
ț
a păr
ț
ilor interesate .
Deoarece numărul de teste posibile chiar
ș
i pentru componente software simple este practic infinit,
toate testările software utilizează o anumită strategie pentru a selecta teste care sunt realizabile pentru
timpul
ș
i resursele dispon ibile. Drept urmare, testarea software de obicei (dar nu exclusiv) încearcă să
execute un program sau o aplica
ț
ie cu inten
ț
ia de a găsi bug-uri software (erori sau alte defecte).
4
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Sarcina de testare este un proces iterativ, deoarece atunci când este rezolvat un bug, poate lumina alte
bug-uri mai adânci sau chiar poate crea altele noi.
Testarea software poate furniza informa
ț
ii obiective
ș
i independente despre calitatea software-ului
ș
i
riscul e
ș
ecului utilizatoril or sau sponsorilor.
Testarea software poate fi efectuată imediat ce există software executabil (chiar dacă par
ț
ial complet).
Abordarea generală a dezvoltării software determină adesea când
ș
i cum se efectuează testarea. De
exemplu, într-un proces pe etape, majoritatea testării au loc după ce cerin
ț
ele sistemului au fost
definite
ș
i apoi implemen tate în programe testabile. În schimb, sub o abordare Agile, cerin
ț
ele,
programarea
ș
i testarea su nt deseori efectuate simultan.
Un scop principal al testării este detectarea defec
ț
iunilor software, astfel încât defectele să poată fi
descoperite
ș
i corectate. T estarea nu poate stabili că un produs func
ț
ionează corect în toate condi
ț
iile,
ci doar că acesta nu func
ț
ionează corect în condi
ț
ii specifice. Domeniul de testare software include
adesea examinarea codului
ș
i execu
ț
ia codului respectiv în divers e medii
ș
i condi
ț
ii. În cultura actuală
de dezvoltare de software, o organiza
ț
ie de testare poate fi separată de echipa de dezvoltare. Există
diverse roluri pentru membrii echipei de testare. Informa
ț
iile derivate din testarea software pot fi
utilizate pentru a corecta procesul prin care este dezvoltat software.
1.3 Defecte
ș
i e
ș
ecuri
Nu toate defectele software sunt cauzate de erori de codificare. O sursă obi
ș
nuită de defecte
costisitoare sunt lipsurile de cerin
ț
ă, adică cerin
ț
ele nerecunoscute care duc la erori de omisiune din
partea proiectantului de programe. Lacunele de cerin
ț
ă pot fi adesea cerin
ț
e nefunc
ț
ionale, cum ar fi
testabilitatea, scalabilitatea, mentenabilitatea, performan
ț
a
ș
i securitatea.
Defec
ț
iuni software apar prin următoarele procese. Un programator face o eroare (gre
ș
eală), care are
ca rezultat un defect (defect, eroare) în codul sursă al software-ului. Dacă acest defect este executat, în
anumite situa
ț
ii, sistemul va produce rezultate gre
ș
ite, provocând o defec
ț
iune. Nu toate defectele vor
duce neapărat la e
ș
ecuri. De exemplu, defectele codului mort nu vor duce niciodată la e
ș
ecuri. Un
defect se poate transforma într-un e
ș
ec atunci când mediul este schimbat. Exemple de schimbări în
mediu includ software-ul rulat pe o nouă platformă hardware computer, modificări ale datelor sursă
sau interac
ț
iunea cu difer ite programe software. Un singur defect poate duce la o gamă largă de
simptome de e
ș
ec.
1.4 Combina
ț
ii de intrar e
ș
i precondi
ț
ii
O problemă fundamentală a testării software este aceea că testarea sub toate combina
ț
iile de intrări
ș
i
precondi
ț
ii (stare ini
ț
ială) nu este posibilă, chiar
ș
i cu un produs simplu. Aceasta înseamnă că numărul
de defecte dintr-un produs software poate fi foarte mare, iar defectele care apar rar sunt dificil de găsit
la testare. Mai semnificativ, dimensiunile nefunc
ț
ionale ale calită
ț
ii (modul în care se presupune că
este fa
ț
ă de ceea ce se pre supune că trebuie) – utilizabilitatea, scalabilitatea, performan
ț
a,
5
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
compatibilitatea, fiabilitatea – pot fi extrem de subiective; ceva care constituie o valoare suficientă
pentru o persoană poate fi intolerabil pentru alta.
Dezvoltatorii de software nu pot testa totul, dar pot utiliza designul combinator de teste pentru a
identifica numărul minim de teste necesare pentru a ob
ț
ine acoperirea dorită. Proiectarea combinată a
testelor permite utilizatorilor să ob
ț
ină o acoperire mai mare a testelor cu mai pu
ț
ine teste. Indiferent
dacă sunt în căutarea vitezei sau a adâncimii testelor, pot utiliza metode de proiectare combinatorie a
testelor pentru a construi varia
ț
ii structurate în cazurile lor de testare.
1.5 Scopul
Scopul primordial pentru procesul de testare este identificarea erorilor de software, izolarea
ș
i
fixarea/corectarea defectelor care au cauzat aceste erori. Deseori este un exerci
ț
iu non-trivial,
deoarece testarea nu poate demonstra cu certitudine de 100% că produsul fun
ț
ionează corect în
orice condi
ț
ii; testarea do ar poate demonstra că produsul nu func
ț
ionează corect în anumite
condi
ț
ii. În scopul testării deseori se include atât examinarea statică a codului sursă, cât
ș
i
examinarea codului în execu
ț
ie în diferite împrejurări
ș
i sub diferite condi
ț
ii. Informa
ț
ia ob
ț
inută
în urma procesului de testare poate fi folosită pentru corectarea
ș
i îmbunătă
ț
irea procesului
conform căruia se dezvoltă produsul software.
[3]
1.6 Ce este SDLC
SDLC (Software Development Life Cycle – Ciclul de Via
ț
ă al Dezvoltării Software) define
ș
te
toate etapele standard implicate în procesul de dezvoltare a software-ului. Ciclul de via
ț
ă SDLC
este un proces de dezvoltare a software-ului printr-o manieră treptată în următoarea ordine
[4]
:
1.
Faza cerin
ț
elor;
2.
Faza de analiză;
3.
Faza de proiectare;
4.
Faza de dezvoltare;
5.
Faza de testare;
6.
Faza de implementare
ș
i între
ț
inere.
Fiecare etapă are un criteriu definit de intrare
ș
i
ie
ș
ire.
1.6.1 De ce sa folosesti SDLC
●
Acesta î
ș
i propune să producă un sistem
software de înaltă calitate, care vă ajută
să îndeplini
ț
i a
ș
teptările clien
ț
ilor;
6
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
●
O revizuire formală este creată după finalizarea fiecărei etape care asigură un control
optim al managementului;
●
SDLC vă ajută să crea
ț
i documenta
ț
ii de sistem;
●
Produce multe produse intermediare care pot fi revizuite pentru a verifica dacă pot
satisface nevoile utilizatorului
ș
i sunt în conformitate cu cerin
ț
ele men
ț
ionate;
●
SDLC ajută la asigurarea faptului că cerin
ț
ele de sistem pot fi urmărite înapoi la cerin
ț
ele
de afaceri declarate;
●
Fiecare fază are un criteriu specific de livrare, intrare
ș
i ie
ș
ire;
●
Etapele de dezvoltare merg una câte una, ceea ce este o op
ț
iune ideală pentru proiectele
mici sau mijlocii în care cerin
ț
ele sunt clare.
1.6.2 Caracteristicile SDLC
●
Structura
ș
i func
ț
iile modelului sunt bine documentate, iar rezultatul testat este disponibil;
●
Proiectul poate fi finalizat pas cu pas înainte de începerea unui alt proiect. Unită
ț
ile de
proiect sunt distincte
ș
i u
ș
or de identificat;
●
Gestionarea riscurilor este parte integrantă a modelului;
●
Proiectul poate fi documentat astfel încât toate piesele lipsa să fie descoperite din timp.
1.7 Ce este STLC
STLC (Software Testing Life Cycle – Ciclul de via
ț
ă al testării software) este procesul de testare
care este executat într-o manieră bine planificată. În procesul STLC, se desfă
ș
oară diverse
activită
ț
i pentru îmbunătă
ț
irea calită
ț
ii produsului. Cu toate acestea, etapele STLC se ocupă doar
de testarea
ș
i detectarea e rorilor, dar nu
ș
i de dezvoltarea în sine.
Ciclul de via
ț
ă al testarii software are următoarele
etape.
[5]
1.
Analiza cerin
ț
elor
2.
Planificarea testelor
3.
Proiectare test
4.
Configurarea mediului de testare
5.
Executarea testelor
6.
Încheierea testelor
1.7.1 De ce sa folosesti STLC
●
STLC îmbunătă
ț
e
ș
te procesul de testare
devenind mai sofisticat, consistent
ș
i mai eficient;
●
Pute
ț
i include rep ere
ș
i rezultate pentru fiecare etapă a pro iectului;
7
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
●
U
ș
or de în
ț
eles
ș
i de implementat chiar dacă modelul este extins la diferite niveluri;
●
Fiecare modul al proiectului este testat înainte de începutul unui nou modul;
●
Cerin
ț
a proiectulu i specific este măsurată în func
ț
ie de rezultatul real.
1.7.2 Caracteristicile STLC
●
STLC analizează cerin
ț
ele sistemului colectate de la clien
ț
i
ș
i păr
ț
i interesate;
●
Ajută la crearea Matricei de Trasabilitate;
●
Identifica tehnica de testare
ș
i tipurile de testare;
●
Pute
ț
i analiza feza bilitatea automatizării cu STLC;
●
Identifica informa
ț
iile despre mediul de testare unde testul propriu-zis ar trebui să fie
executat.
1.8 Diferen
ț
e dintre SDL C
ș
i STLC
●
SDLC define
ș
te toate fazele standard implicate în procesul de dezvoltare a software-ului,
în timp ce procesul STLC define
ș
te diverse activită
ț
i pentru a îmbunătă
ț
i calitatea
produsului;
●
SDLC este un ciclu de via
ț
ă pentru dezvoltare, în timp ce STLC este un ciclu de via
ț
ă
pentru testare;
●
În SDLC, echipa de dezvoltare creează planuri de proiectare la nivel înalt
ș
i scăzut, în
timp ce în STLC, analistul de testare creează planul de testare pentru System Testing
ș
i
Integration Testing;
●
În SDLC, codul real este dezvoltat, iar activitatea efectivă se desfă
ș
oară conform
documentelor de proiectare, în timp ce în STLC echipa de testare pregăte
ș
te mediul de
testare
ș
i execută cazuri de testare;
●
Ciclul de via
ț
ă SD LC ajută o echipă să finalizeze cu succes dezvoltarea software-ului, în
timp ce etapele STLC acoperă doar testarea software-ului.
1.9 Metodologia Agile
Metoda
Agile
de
dezvoltare
a
software-ului
oferă
o
abordare
alternativă
pentru
testarea
software-ului.
Printre
reperele
Agile
se
numără
faptul
că
folose
ș
te
secven
ț
e
incrementale,
iterative
ale
lucrărilor
cunoscute în mod obi
ș
nuit ca „
Sprinturi
”
[6]
.
Sprinturile
sunt
perioadele
alocate
pentru
fazele
specifice
ale
unui
proiect
de
dezvoltare
ș
i
sunt
considerate
complete
atunci
când
perioada
stabilită
pentru
o
fază
expiră.
Lucrările
la
acea
fază
se
încheie,
chiar
dacă
membrii
echipei
consideră
că
este
nevoie
de
mai
mult
efort,
iar
următoarea
fază
a
proiectului
începe
ș
i
parcurge
intervalul
de
timp
desemnat.
Acest
proces
continuă
până
la
finalizarea
tuturor etapelor proiectului.
8
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Cele
două
modele
principale
de
dezvoltare
care
se
încadrează
în
Metoda
Agile
sunt
Scrum
ș
i
Kanban
.
Scrum
este
una
dintre
cele
mai
populare
metodologii
de
testare
software
ș
i
este,
de
asemenea,
un
cadru
pentru
gestionarea
lucrărilor,
cu
accent
pe
dezvoltarea
de
software.
Modelul
Scrum
oferă
o
strategie
flexibilă
de
dezvoltare
a
produselor
care
permite
echipelor
de
dezvoltare
să
lucreze
ca
unită
ț
i
indiv iduale
pentru
a
atinge
un
obiectiv
comun
ș
i
permite
echipelor
să
se
autoorganizeze prin încurajarea apropierii fizice sau a colaborării online a tuturor membrilor echipei.
Kanban
este
o
modalitate
de
a
proiecta,
gestiona
ș
i
îmbunătă
ț
i
fluxul
de
lucru
al
unui
proiect
de
dezvoltare,
permi
ț
ând
organiza
ț
iilor
să
înceapă
cu
fluxul
de
lucru
existent
ș
i
să
realizeze
îmbunătă
ț
iri
treptate
prin
vizualizarea
fluxului
de
muncă,
limitarea
lucrărilor
în
curs
ș
i
concentrarea
pe
finalizarea
lucrărilor.
1.10 Impactul Agile in testare
În
metodele
Agile,
testarea
este
încorporată
în
procesul
de
dezvoltare.
Dezvoltatorii
de
software
sunt
instrui
ț
i
să
scrie
teste
fie
înainte,
fie
odată
cu
scrierea
codului.
Fiecare
subsistem
al
unui
program
este
încapsulat
într-un
set
de
teste
unitare
care
se
asigură
că
continuă
să
facă
ceea
ce
ar
trebui
să
facă.
Acest
lucru
face
mult
mai
u
ș
or
să
identifica
ț
i
ș
i
să
izola
ț
i
problemele
pe
măsură
ce
produsul
evoluează
în
timp.
Dat
fiind
faptul
că
dezvoltarea
produselor
software
poate
fi
dinamică
ș
i
că
mul
ț
i
factori
pot
afecta performan
ț
a
ș
i vulnerabilitatea, aceasta este o capacitate im portantă de testare.
Testerii
sunt
integra
ț
i
ca
membri
ai
echipei
de
dezvoltare,
astfel
încât
să
poată
efectua
teste
pe
măsură
ce
sunt
finalizate
mici
bucă
ț
i
de
func
ț
ionalitate.
O
colaborare
mai
strânsă
ș
i
bucle
de
feedback
mult
mai scurte permit găsirea problemelor mai devreme, împiedicând crearea unor probleme ulterioare.
Testerii
din
organiza
ț
iile
Agile
primesc
adesea
instruire
suplimentară
ș
i
acces
la
instrumente
mai
bune,
ceea ce le permite să scrie
ș
i să execute teste automate la nivelul
GUI
ș
i
API
.
Aceste
teste
automate
ș
i
testele
unitare
men
ț
ionate
anterior
sunt
factori
critici
în
capacitatea
echipelor
Agile
de
a
livra
rapid
pe
o
perioadă
prelungită.
Fără
ele,
metodele
Agile
pot
genera
o
explozie
ini
ț
ială
de
viteză,
dar
apoi
se
pot
opri,
deoarece
greutatea
testării
manuale
face
imposibilă
eliberarea
rapidă
a
noilor functionalitati.
9
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
2.
Metodologia Agile
2.1 Despre Metodologia Agile
Metodologiile Agile î
ș
i au rădăcinile în planificarea adaptativă, livrarea timpurie
ș
i îmbunătă
ț
irea
continuă, toate având în vedere posibilitatea de a răspunde rapid
ș
i u
ș
or la schimbări. Drept urmare, nu
este surprinzător faptul că 88% dintre responden
ț
i din Raportul de State of Agile al VersionOne 2017
[7]
au clasat „capacitatea de a se adapta la schimbare” drept beneficiul numărul unu al îmbogă
ț
irii Agile.
Cu toate acestea, pe măsură ce tot mai multe echipe de dezvoltare adoptă o filozofie Agile, testerii s-au
străduit să păstreze ritmul. Acest lucru se datorează faptului că adoptarea pe scară largă a Agile a
determinat echipele să emită versiuni
ș
i software complet fără documente pe o bază mai frecventă.
Această frecven
ț
ă a oblig at testerii să se deplaseze atunci când efectuează teste, cum lucrează cu
dezvoltatorii
ș
i
BA
[8]
ș
i chiar ce teste efectuează, toate păstrân d standardele de calitate.
2.2 Ce înseamnă să testăm într-o echipă Agile?
Principiile Agile se referă la a fi colaborativ, flexibil
ș
i adaptativ. Este construit pe premisa că lumea
se schimbă acum în mod regulat
ș
i asta înseamnă că echipele software nu mai au ani de zile pentru a
aduce noi produse pe pia
ț
ă. În acel timp, ofertele concuren
ț
ilor sau a
ș
teptările clien
ț
ilor se pot
schimba, iar echipa riscă irelevan
ț
a. Agile minimizează acest risc, ajutând echipele să colaboreze mai
mult împreună prin adaptarea la ceea ce trebuie să aibă succes echipa. Face acest lucru prin încurajarea
echipelor să-
ș
i arate în m od regulat munca
ș
i să adune feedback, astfel încât să se poată adapta la
schimbare rapid.
2.3 Agile nu este potrivit pentru toate organiza
ț
iile
Fiecare organiza
ț
ie este u nică
ș
i se confruntă cu factori interni dif eri
ț
i (adică dimensiunea organiza
ț
iei
ș
i păr
ț
ile interesate)
ș
i factori externi (adică clien
ț
ii
ș
i reglementările). Pentru a ajuta la satisfacerea
diferitelor nevoi ale diferitelor organiza
ț
ii, există diferite metodologii Agile
ș
i mai multe tipuri diferite
de teste pe care le pute
ț
i face în timp ce lucra
ț
i în cadrul uneia dintre aceste metodologii agile. Care
mix este potrivit pentru echipa ta va depinde de factorii, nevoile
ș
i obiectivele tale interne
ș
i externe.
Să aruncăm o privire la ce presupun unele dintre cele mai populare metodologii Agile
ș
i metode de
testare:
10
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
❖
Metodologiile Agile
➢
Scrum
➢
Kanban
❖
Metodele de Testare
➢
Modalită
ț
ile de testare în cadrul Dezvoltării conduse de comportament (
BDD
)
[9]
➢
Modalită
ț
ile de testare în cadrul Dezvoltării conduse de testul de acceptare
(
ATDD
)
[10]
➢
Testarea exploratorie
➢
Testarea bazată pe sesiune
2.3.1 Tipuri de
Metodologii Agile
I.
Scrum:
–
Ce este?
Scrum este un cadru de proces Agile pentru gestionarea lucrărilor complexe de
cunoa
ș
tere, cu un accent ini
ț
ial pe dezvoltarea de software , de
ș
i a fost utilizat în alte domenii
ș
i
începe lent să fie explorat pentru alte lucrări complexe, cercetare
ș
i tehnologii avansate. Este
conceput pentru echipe de zece sau mai pu
ț
ini membri, care î
ș
i desfă
ș
oară activitatea în
obiective care pot fi finalizate în cadrul itera
ț
iilor de tip timeboxed, numite sprinturi, nu mai
mult de o lună
ș
i cel mai frecvent două săptămâni, apoi urmăresc progresul
ș
i re-planifică în 15
minute întâlniri zilnice în timp, numite
scrumuri
[11]
zilnice.
Scrum începe cu o cerin
ț
ă sau o “poveste de utilizator”
[12]
care prezintă modul în care func
ț
iile ar
trebui să fie efectuate
ș
i testate. Echipa apoi trece printr-o serie de sprinturi pentru a oferi rapid mici
explozii de valoare. Pentru a ajuta echipa să func
ț
ioneze în acest mod flexibil
ș
i pentru a evita
schimbarea priorită
ț
ilor, S crum cere ca răspunsurile la întrebări să fie primite de la bun început.
–
Cum este diferit de modelul Waterfall?
În timp ce Waterfall include mai multe cicluri de
testare
ș
i remedier e a erorilor înainte de a lansa un produs, Scrum este mult mai colaborativ
ș
i
mai iterativ. Una dintre cele mai mari diferen
ț
e este că Waterfall solicită documente din timp.
Această documenta
ț
ie face mai dificilă schimbarea caracteristicilor pe măsură ce procesul
continuă, ceea ce poate fi negativ în unele medii (cum ar fi software de calitate pentru
consumatori)
ș
i unul pozitiv (cum ar fi cele în care echipa încearcă să lanseze o rachetă,
deoarece nimeni nu dore
ș
te cerin
ț
e pentru ceva periculos c are se schimbă frecvent). Acestea
fiind spuse, s-ar putea să vă gândi
ț
i la Scrum ca la multe „mini Waterfall-uri”, deoarece
cerin
ț
ele sunt bine definite la începutul fiecărui sprint
ș
i nu ar trebui să se schimbe în interiorul
11
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
acestuia. Diferen
ț
a este că cerin
ț
ele detaliate pentru următ orul sprint nu sunt stabilite cu luni
înainte.
Scrum solicită o colaborare mai regulată între testeri, dezvoltatori
ș
i BA, de obicei sub formă de
scrumuri zilnice
ș
i retrosp ective sprint, pentru a asigura o comunicare
ș
i aliniere adecvată. În plus,
există un Scrum Master
[13]
care ajută cu eliminarea impedimentelor din calea progresului echipei de
dezvoltare, eliminând blocarile din echipă pentru a se asigura că pot fi cei mai eficien
ț
i. Scrum Master
poate fi oricine din echipă, cum ar fi un dezvoltator sau un tester.
–
Ce presupune?
Scrum oferă una dintre cele mai u
ș
oare tranzi
ț
ii pentru echipele care provin
dintr-un mediu de tip Waterfall, deoarece este bazat pe timp cu sprinturi
ș
i versiuni ce poate fi
planificat în avans. Acestea fiind spuse, necesită itera
ț
ii mai rapide
ș
i o colaborare mai
puternică.
–
Pentru cine este?
Datorită itera
ț
iilor sale rapide, Scrum este cel mai potrivit pentru echipele ai
căror clien
ț
i
ș
i păr
ț
i interesate doresc să fie implicate activ. Această colaborare permite echipei
să facă modificări pentru viitoarele itera
ț
ii. Membrii cheie ai echipei care ar trebui să fie
implica
ț
i în abord area Scrum includ:
●
Proprietarul produsului (PO)
[14]
;
●
Scrum Master (SM);
●
Dezvoltatori;
●
Ingineri de automatizare;
●
Testeri;
●
Păr
ț
ile inter esate.
–
Care sunt cele mai bune practici?
Pe lângă comunicarea puternică, colaborarea
ș
i
adaptabilitatea, alte bune practici pentru testeri, urmând o metodologie Scrum, includ:
●
Determinarea criteriilor de acceptare bazate pe comunicarea (de obicei sub forma unei
pove
ș
ti a ut ilizatorului) de la un reprezentant de vânzări sau un client (notă: această
conexiune directă ar trebui să contribuie la reducerea comunicărilor gre
ș
ite);
●
Utilizarea criteriilor de acceptare pentru a dezvolta codul
ș
i a asigura aprobarea echipei
pentru acel cod;
●
Testarea codului în medii asemănătoare cu cutii de nisip, precum
ș
i în medii
asemănătoare produc
ț
iei înainte de a-l implementa în produc
ț
ie.
II.
Kanban:
12
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Ce este?
Kanban este un cadru popular utilizat pentru implementarea Metodologia Agile. Acesta
necesită o comunicare în timp real a capacită
ț
ii
ș
i transparen
ț
a deplină a muncii. Articolele de lucru
sunt reprezentate vizual pe o placă kanban
[15]
, permi
ț
ând membrilor echipei să vadă în orice moment
starea fiecărei lucrări.
[16]
Spre deosebire de Scrum, Kanban nu este bazat pe timp. Mai degrabă, se bazează exclusiv pe
prioritate. Când un dezvoltator este pregătit pentru următoarea sarcină (task), o va lua pe următoarea
cea mai prioritară din lista de activită
ț
i. Deoarece există mai pu
ț
ine întâlniri de planificare, această
abordare înseamnă că echipa trebuie să fie extrem de apropiată. În acest tip de mediu, dacă
dezvoltatorii lucrează mult mai repede decât testerii, blocajele vor cre
ș
te. În aceste situa
ț
ii, oricine din
echipă ar trebui să sară
ș
i să ajute în diferite domenii. Desigur, satisfacerea acestei nevoi necesită o
mare flexibilitate
ș
i adapt abilitate.
–
Cum este diferit de tipul Waterfall?
Kanban are în continuare cerin
ț
e precum Waterfall, dar
cerin
ț
ele se pot sc himba, deoarece echipa de testare nu începe să se gândească la testarea
fiecărei cerin
ț
e până când dezvoltatorul nu o va selecta din partea de sus a listei. Planificarea
grea care vine într-un mediu de Waterfall este excelentă în unele cazuri, cum ar fi atunci când
construie
ș
ti lucrur i scumpe, dar nu este întotdeauna necesară. Cu Kanban, lansările sunt încă
planificate, dar echipele nu promit, de obicei, nimănui func
ț
ii până la anumite date, cu excep
ț
ia
cazului în care articolul în cauză este aproape de partea de sus a listei.
–
Ce presupune?
Kanban oferă o tranzi
ț
ie simplă pentru echipele potrivite. Pentru a face o
tranzi
ț
ie lină către Kanban, BA, dezvoltatorii, testerii
ș
i păr
ț
ile interesate ar trebui să comunice
în mod regulat. Atunci când trece
ț
i la Kanban, este important să re
ț
ine
ț
i că această metodologie
oferă cea mai rapidă modalitate de a aduce codul la produc
ț
ie, dar este posibil ca acesta să aibă
unele datorii tehnice. Acest lucru se datorează faptului că echipa de dezvoltarea, fără a
ș
ti
întotdeauna ce urmează, nu produce cel mai reutilizabil cod.
–
Pentru cine este?
Kanban este cel mai potrivit pentru echipe mici sau echipe care nu produc
caracteristici pentru public
ș
i / sau promit anumite date pentru lansări. În plus, este o
metodologie de vârf la alegere pentru orice produse sau echipe axate în principal pe lucrările de
între
ț
inere, deoare ce bug-urile nu sunt întotdeauna simple
ș
i deseori necesită cercetări pentru
rezolvare, ceea ce face ca gestionarea timpului să fie dificilă. Echipele care nu pot minimiza
cantitatea de planificare pentru probleme sunt probabil mai bune în urma unei metodologii
Scrum sau Waterfall. Membrii echipei care ar trebui să fie implica
ț
i într-un mediu Kanban
includ:
●
Proprietarul produsului(PO);
●
Manager de proiect(PM);
●
Dezvoltatori;
●
Ingineri de automatizare;
13
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
●
Testeri.
–
Care sunt cele mai bune practici?
Pe lângă men
ț
inerea vizibilită
ț
ii
ș
i prioritizarea colaborării,
cele mai bune practici pentru testeri urmând o metodologie Kanban includ:
●
Păstrarea unei linii de comunicare foarte deschise între proprietarii de afaceri,
dezvoltatori
ș
i testeri;
●
Asigurarea echipei are flexibilitate pentru a-
ș
i asuma alte roluri în afara
responsabilită
ț
ilor de bază pentru a ajuta la eliminarea blocajelor;
●
Făcând pe toată lumea un proprietar al produsului, astfel încât să fie orientate spre
rezultat.
2.3.2 Metodele de testare Agile
I.
Modalită
ț
ile de te stare în cadrul
Dezvoltării conduse de comportament (BDD):
–
Ce este?
Mul
ț
i oameni au auzit despre sau au folosit Test Driven Development (TDD). De
exemplu, dezvoltatorii folosesc TDD pentru a scrie teste unitare
[17]
. BDD se bazează pe
acelea
ș
i principii ca TDD, dar în loc de teste unitare, solicită teste de nivel superior la nivel de
afaceri. În loc să înceapă cu un teste unitare tehnic orientat către TDD, BDD începe cu o
cerin
ț
ă ini
ț
ială bazată pe comportamentul utilizatorului fin al
ș
i solicită teste care „pot fi citite
de om”
ș
i chiar po t înlocui unele documenta
ț
ii cu cerin
ț
e. Această cerin
ț
ă se bazează pe
comportamente pe care ar trebui să le prezinte produsul, creând un ghid etan
ș
pentru ca
inginerii să-l poată utiliza în timp ce dezvoltă teste.
Mai exact, BDD începe cu o specifica
ț
ie func
ț
ională folosind sintaxa Give / When / Then. Această
specifica
ț
ie ghidează apo i dezvoltatorii, testerii
ș
i proprietarii de produse(PO). Utilizează func
ț
ii de
testare automate pentru a determina completitudinea
ș
i rafinarea codului până la trecerea testului, la fel
ca în abordarea TDD, cu excep
ț
ia nivelului echipei. Pentru a asigura trecerea testului (
ș
i de obicei
necesită mai multe încercări), dezvoltatorul ar trebui să refactorizeze codul, nu să adauge
func
ț
ionalită
ț
i noi.
Pe scurt, BDD necesită o strategie de automatizare „inteligentă” care conduce la un nivel ridicat de
eficien
ț
ă. Această strateg ie diferen
ț
iază BDD de alte metodologii Agile.
–
Prin ce se diferen
ț
iază de testarea standard în Waterfall?
BDD este extrem de diferită de
testarea standard de tip Waterfall, deoarece metoda Waterfall necesită scrierea timpurie a
cazurilor în conformitate cu cerin
ț
ele
ș
i solicită executarea acestor teste până la sfâr
ș
itul
ciclului de dezvoltare. Cu BDD într-un mediu Agile, testele nu se bazează însă pe cerin
ț
e, iar
testarea se întâmplă împreună cu dezvoltarea func
ț
iilor.
14
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
În plus, în cadrul unei metodologii Waterfall, testerii sunt cei care scriu cazurile de testare. În
abordarea BDD,
BO
[18]
sunt cei care definesc testele. Acest mod de lucru reduce comunicarea (sau
comunicarea gre
ș
ită) între BA, dezvoltatori
ș
i testeri.
–
Ce presupune?
Modificarea unei metodologii BDD poate fi dificilă atunci când echipa se
obi
ș
nuie
ș
te cu un stil tradi
ț
ional de testare. Este necesar ca un BA sau un tester să scrie teste
înainte ca dezvoltatorii să scrie specifica
ț
ia testului în cod care să se potrivească. Este un nou
tip de coordonare în cadrul echipei, dar este extrem de pozitiv prin faptul că echipa lucrează
împreună ca o unitate,
utilizatorii comerciali
[19]
inclu
ș
i.
–
Pentru cine este?
Metodologia BDD este ideală pentru echipele care lucrează pe software
centrat pe caracteristici
ș
i / sau echipe care pun experien
ț
a utilizatorului pe primul loc. Printre
membrii cheie ai echipei care ar trebui să fie implica
ț
i se numără:
●
BO / BA;
●
PM
[20]
;
●
Dezvoltatori;
●
Inginer automat / testerul .
–
Care sunt cele mai bune practici?
Cele mai bune practici pentru testeri care urmează o
metodologie BDD includ:
●
Simplificarea documenta
ț
iei pentru a men
ț
ine întregul proces cât mai simplist posibil;
●
Îmbră
ț
i
ș
area unui model „
trei prieteni
”
[21]
în care p roprietarul, dezvoltatorul
ș
i testerul
produsului formează o echipă unită;
●
Folosirea unui cadru de testare precum Cucumber
[22]
pentru a defini criteriile;
●
Construirea de teste automate într-un mod care să le faciliteze reutilizarea cât mai mult
posibil;
●
Având anali
ș
tii de afaceri să înve
ț
e sintaxa Gherkin
[23]
ș
i să scrie cazuri de testare direct.
II.
Modalită
ț
ile de te stare în cadrul
Acceptance Test Driven Development (ATDD):
–
Ce este?
ATDD este asemanator cu BDD, deoarece necesită mai întâi crearea de teste
ș
i
solicită ca, codul să fie scris pentru a trece aceste teste. Cu toate acestea, spre deosebire de
TDD, unde testele sunt de obicei teste unitare orientate spre tehnică, în ATDD testele sunt de
obicei teste de acceptare orientate către clien
ț
i.
Ideea din spatele ATDD este că percep
ț
ia utilizatorului asupra produsului este la fel de importantă ca
func
ț
ionalitatea, deci acea stă percep
ț
ie ar trebui să conducă la per forman
ț
a produsului pentru a ajuta la
cre
ș
terea adoptării. Pentru a aduce la via
ț
ă aceste idei, ATDD colectează informa
ț
iile de la clien
ț
i,
ș
i le
folose
ș
te pentru a dezvolt a criteriile de acceptare pentru testele manuale sau automate
ș
i apoi dezvoltă
15
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
traducerea criteriilor de testare în testele de acceptare. Ca
ș
i TDD
ș
i BDD, ATDD este o metodologie
de
testare mai intai
, nu un proces bazat pe cerin
ț
e.
La fel ca metodologiile TDD
ș
i BDD, ATDD ajută la eliminarea zonelor poten
ț
iale pentru
neîn
ț
elegere, eliminând n evoia dezvoltatorilor de a interpreta modul în care produsul va fi utilizat.
ATDD merge cu un pas mai departe decât TDD
ș
i BDD, însă, deoarece merge direct la sursă (clientul)
pentru a în
ț
elege cum va fi utilizat produsul. În mod ideal, această conexiune directă ar trebui să
contribuie la minimizarea necesită
ț
ii de reproiectare a func
ț
iilor în noile versiuni.
–
Cum este diferit de testarea standard în Waterfall?
ATDD este diferită de testarea standard
în Waterfall, deoarece este o metodologie de prim test. Testarea standard solicită ca
ș
i cazurile
de testare să fie scrise în avans pe baza cerin
ț
elor, în timp ce ATDD nu este un proces de
testare condus de cerin
ț
e.
–
Ce presupune?
Deoarece ATDD reprezintă o astfel de îndepărtare de la metodele tradi
ț
ionale,
trecerea de la una la alta nu este u
ș
or pentru echipe. Pentru a fi în cea mai bună pozi
ț
ie pentru a
adopta o metodologie ATDD, echipele trebuie să ob
ț
ină achizi
ț
ionarea păr
ț
ilor interesate, ceea
ce se poate dovedi provocator uneori.
–
Pentru cine este?
Datorită accentului său pe percep
ț
ia utilizatorului, ATDD este cel mai
potrivit pentru echipele care sunt concentrate pe experien
ț
a utilizatorului, au obiective în jurul
ratelor ridicate de adop
ț
ie
ș
i doresc să reducă la minimum numărul de modificări ale func
ț
iilor
în versiunile viitoare. Membrii cheie ai echipei care ar trebui să fie implica
ț
i într-un mediu
ATDD includ:
●
Client / Avocat client;
●
Dezvoltator;
●
PO / BA;
●
Inginer testare automată / testeri;
●
PM.
–
Care sunt cele mai bune practici?
Cele mai bune practici pentru testeri care urmează o
metodologie ATDD Agile includ:
●
Interac
ț
ionând strâns cu clien
ț
ii, pentru a determina a
ș
teptările;
●
Se bazează pe membrii echipei orientate către clien
ț
i, cum ar fi reprezentantul vânzărilor,
agen
ț
ii de s ervicii pentru clien
ț
i
ș
i managerii de cont, pentru a în
ț
elege a
ș
teptările
clien
ț
ilor;
●
Dezvoltarea criteriilor de acceptare bazate pe a
ș
teptările clien
ț
ilor;
●
Prioritizarea a două întrebări:
○
Clien
ț
ii vor folosi sistemul dacă face X?
○
Cum putem valida dacă sistemul face X?
16
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
III.
Testare Exploratori
[24]
:
–
Ce este?
Este un tip de testare software în care cazurile de testare nu sunt create în avans, ci
testerii verifică sistemul din mers. Ace
ș
tia pot nota idei despre ce trebuie testat înainte de
executarea testului. Testarea exploratorie se concentrează mai mult pe testare ca activitate de
„gândire”.
Testele exploratorii nu sunt scrise. Mai degrabă, este vorba despre dezvoltarea celor mai bune teste
bazate pe fiecare software unic. Datorită abordării sale nescrise, testarea exploratorie imită adesea
modul în care utilizatorii vor interac
ț
iona cu software-ul în via
ț
a reală.
Testarea exploratorie respectă patru principii cheie:
➢
Planificarea testelor paralele, proiectarea testelor
ș
i executarea testelor;
➢
Specific, dar flexibil;
➢
Aliniat la investigarea poten
ț
ialelor oportunită
ț
i;
➢
Impartasire de cuno
ș
tin
ț
e.
–
Cum este diferit de testarea standard în Waterfall?
Testarea exploratorie se poate efectua
atât în mediul Waterfall, cât
ș
i în Agile, dar integrarea strânsă între testeri
ș
i dezvoltatori
într-un mediu Agile ajută la u
ș
urarea oricăror blocaje care ar putea ie
ș
i la suprafa
ț
ă în timp ce
se efectuează teste exploratorii într-un mediu de tip Waterfall.
În plus, pentru a efectua teste exploratorii într-un mediu de tip Waterfall, documenta
ț
ia privind
rezultatele testelor este o necesitate, iar această documenta
ț
ie ar trebui să fie u
ș
or de urmărit la cerin
ț
e.
–
Ce presupune?
Îmbră
ț
i
ș
area testării exploratorii este rela tiv u
ș
oară, deoarece este rapid de
lansat (
ș
i la scară) , simplu de învă
ț
at
ș
i oferă avantaje pentru întreaga echipă. Acestea fiind
spuse, este important să re
ț
ine
ț
i că nu ar trebui să fie singu ra formă de testare (mai degrabă, ar
trebui să informeze ce tip de testare se întâmplă în continuare). În plus, de
ș
i este nescris,
testarea exploratorie nu ar trebui să fie nestructurată (testerii mai trebuie să stabilească un
obiectiv, să vă înregistreze activită
ț
ile
ș
i să adopte mental itatea unui anumit utilizator).
–
Pentru cine este?
Testarea exploratorie poate ajuta la reducerea timpului petrecut în testare, la
găsirea mai multor defecte
ș
i la îmbunătă
ț
irea acoperirii codului. Drept urmare, testarea
exploratorie este cea mai potrivită pentru echipele care nu au suficient timp pentru testare
Membrii cheie ai echipei care ar trebui să fie implica
ț
i în testarea exploratorie sunt:
●
Testeri (de
ș
i to
ț
i cei din echipă ar trebui să participe într-un fel).
17
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
–
Care sunt cele mai bune practici?
Cele mai bune practici pentru testerii care utilizează teste
exploratorii includ:
●
Organizarea func
ț
ionalită
ț
ii din aplica
ț
ie folosind ceva precum un Mindmap
[25]
sau o
foaie de calcul;
●
Concentrarea pe anumite zone sau anumite scenarii;
●
Urmărirea a ceea ce este testat pentru a ajuta la reproducerea eventualelor erori;
●
Documentarea rezultatelor într-un instrument precum qTest Explorer, Squash etc., deci
există o anumită responsabilitate pentru ceea ce a fost testat.
IV.
Testarea bazată pe sesiune:
–
Ce este?
Este o metodă de testare software care are ca scop combinarea responsabilită
ț
ii
ș
i
testarea exploratorie pentru a oferi descoperirea rapidă a defectelor, controlul managementului
ș
i raportarea metr icilor. Testarea bazată pe sesiuni a fost dezvoltată în 2000 de Jonathan
ș
i
James Bach. Testarea bazată pe sesiune poate fi utilizată pentru a introduce măsurarea
ș
i
controlul într-un proces de testare imatur
ș
i poate constitui o bază pentru îmbunătă
ț
iri
semnificative ale productivită
ț
ii
ș
i detectării erorilor. Test area bazată pe sesiune poate oferi
beneficii atunci când cerin
ț
ele formale nu sunt prezente, incomplete sau se schimbă rapid
[26]
.
Testarea bazată pe sesiune asigură această structură prin efectuarea de teste în timpul sesiunilor fără
întreruperi, în timp ce se testează se solicită testerilor să raporteze testele care au avut loc în fiecare
sesiune. În plus, testarea bazată pe sesiuni ar trebui eliminată cu un „reziduu” între testatorul
(testatorii)
ș
i managerul c are acoperă cele cinci puncte PROOF: Ce s-a întâmplat (
P
ast), ce s-a ob
ț
inut
(
R
esults), ce s-a ob
ț
inut (
O
bstacles), ce mai trebuie făcut (
O
utlook)
ș
i cum simte testerul despre asta
(
F
eelings).
–
Cum este diferit de testarea standard de tip Waterfall?
Testarea bazată pe sesiuni poate fi
efectuată atât în mediile Agile, cât
ș
i în Waterfall, dar este mai favorabilă colaborării strânse
între testeri
ș
i dez voltatori, care se găse
ș
te de obicei în me diile Agile.
–
Ce presupune?
La fel ca în cazul testării exploratorii, adoptarea testării bazate pe sesiuni se
dovede
ș
te relativ u
ș
oară, deoarece este u
ș
or de ridicat
ș
i lansat rapid. Pentru testerii obi
ș
nui
ț
i
deja cu testarea exploratorie, cel mai mare obstacol este aceea de a include structura
suplimentară pentru care apelează testarea bazată pe sesiune. La fel ca în cazul testărilor
exploratorii, echipele care efectuează testarea bazată pe sesiuni ar trebui să-
ș
i amintească că nu
este o oprire finală, ci mai degrabă o metodă care să ajute la determinarea celui mai bun tip de
testare pe care urmează să-l efectueze.
–
Pentru cine este?
Testarea bazată pe sesiune poate ajuta la reducerea timpului de testare,
cre
ș
terea descope ririi defectelor
ș
i a acoperirii codului, ce ea ce este ideal pentru echipele care
18
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
se confruntă cu restric
ț
ii de timp
ș
i au nevoie de mai mult e îndrumări pentru a determina ce
tipuri de teste trebuiesc executate. Este ideal
ș
i pentru echipele care au găsit beneficii în
testarea exploratorie, dar care trebuie să îmbunătă
ț
ească responsabilitatea pe parcursul
întregului proces. Membrii cheie ai echipei care ar trebui să fie implica
ț
i în testarea bazată pe
sesiuni includ:
●
Testeri;
●
Manageri.
–
Care sunt cele mai bune practici?
Cele mai bune practici pentru testerii care utilizează
testarea bazată pe sesiuni sunt:
●
Schi
ț
ează o misiune, astfel încât testerii să
ș
tie cat mai mult despre software-ul pe care îl
testează;
●
Dezvoltarea unui plan clar care indică misiunea, zonele software-ului de testat, care
testerul va rula sesiunea, când va avea loc sesiunea
ș
i cât timp, testele proiectate
ș
i
executate, bug-urile găsite
ș
i notele generale;
●
Executarea sesiunii de testare fără întreruperi;
●
Documentarea clară a activită
ț
ilor
ș
i a notelor în tim pul sesiunii;
●
Ț
inerea une i mini
ș
edin
ț
e între tester
ș
i manager pentru a examina rezultatele sesiunii
ș
i
a discuta pa
ș
ii următori pentru testare.
2.3.3 Cum să alinia
ț
i test area cu un proces de livrare Agile
După ce stabili
ț
i ce metod ologie de testare este potrivită pentru organiza
ț
ie, procesul încă nu este
finalizat. Încă trebuie să alinia
ț
i testarea la livrare. Pentru a atinge acest obiectiv, vă recomandăm o
abordare în trei rânduri:
1.
Implica
ț
i-vă în procesul de dezvoltare cât mai devreme posibil:
Cu cât testerii se pot implica mai devreme, cu atât mai bine. În mod ideal, testerii ar trebui să fie
prezen
ț
i încă din prima zi . Acest lucru se datorează faptului că acordarea testerilor un loc la masă oferă
la fiecare pas un nivel mai bun de cunoa
ș
tere a cerin
ț
elor
ș
i obiectivelor, încurajează colaborarea.
2.
Testa
ț
i frecvent:
19
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Pe măsură ce tot mai multe echipe adoptă metodologii Agile, eficien
ț
a este totul. Această nevoie de
viteză a determinat echipele să îmbră
ț
i
ș
eze
ș
i DevOps
ș
i integrarea continuă(
CI
[27]
) pentru a men
ț
ine
lucrurile în mi
ș
care
ș
i asta necesită testare mai frecventă..
3.
Testele trebuie create cât mai repede cu putin
ț
ă:
Ț
inând cont de nevoia de viteză în lumea Agile, condusă de DevOps, testerii trebuie să grabeasca
procesul de creare a testelor. Dacă ave
ț
i un loc la masă pentru toate conversa
ț
iile de la bun început, ar
trebui să vă ajute în această privin
ț
ă.
3.
Metodologia SAFe
3.1 Ce este Scaled Agile Framework (SAFe)?
Scaled Agile Framework (SAFe)
[28]
este o bază de cuno
ș
tin
ț
e online disponibilă gratuit, care vă
permite să aplica
ț
i practic i u
ș
oare la nivel de companie. Oferă o e xperien
ț
ă simplă, u
ș
oară pentru
echipa de dezvoltare software. Întregul cadru este împăr
ț
it în trei segmente
Echipa
,
Programul
ș
i
Portofoliul
. SAFe permite echipei:
●
Implementarea de software
ș
i sisteme Lean-Agile la nivel de întreprindere;
●
Se bazează pe principiile Lean
ș
i Agile;
●
Oferă îndrumări detaliate pentru activitatea la portofoliul companiei, fluxul valoric, program
ș
i
echipă;
●
Este conceput pentru a răspunde nevoilor tuturor păr
ț
ilor interesate din cadrul unei organiza
ț
ii.
3.1.1 De ce sa folosesti Agile Framework:
Este simplu
ș
i u
ș
or, dar se extinde pentru a face fa
ț
ă nevoilor fluxurilor de valori mari
ș
i dezvoltării
complexe a sistemului. Prin implementarea unui Agile Framework, ve
ț
i avea următoarele avantaje:
[29]
20
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
●
Productivitatea
crescută
cu
20 – 50%;
●
Calitatea
crescută
cu peste
50%;
●
Timpul de comercializare
mai rapid cu
30-75%;
●
Cre
ș
terea implic ării angaja
ț
ilor
ș
i a
satisfac
ț
iei în muncă.
3.1.2 Cand se folose
ș
te Scaled Agile Framework:
●
Atunci când o echipă este interesată să implementeze o abordare Agile în mod constant pe
programe
ș
i porto folii mai mari, cu mai multe echipe;
●
Când mai multe echipe î
ș
i desfă
ș
oară propriul mod de imp lementare Agile, dar se confruntă în
mod regulat cu obstacole, întârzieri
ș
i e
ș
ecuri;
●
Când echipele vor să lucreze independent;
●
Când dori
ț
i să sca la
ț
i Metodologia Agile la nivelul întregi i organiza
ț
ii, dar nu sunte
ț
i sigur ce
roluri noi pot fi necesare sau ce roluri existente (adică, management) trebuie să se schimbe
ș
i
cum;
●
Când a
ț
i încercat să extinde
ț
i Metodologia Agile în întreag a organiza
ț
ie, dar trebuie aliniata o
strategie uniformă sau consecventă între departamentele de afaceri, la nivel de program
ș
i de
echipă;
●
Atunci când o organiza
ț
ie trebuie să-
ș
i îmbunătă
ț
ească timpul de dezvoltare a produsului
ș
i
dore
ș
te să
ș
tie cum alte companii au reu
ș
it să escaladeze în Metodologia Agile cu SAFe.
3.1.3 Cum se diferen
ț
iază de alte practici Agile:
●
Este disponibil public
ș
i gratuit;
●
Disponibil într-o formă extrem de accesibilă
ș
i utilizabilă;
●
Rezultă u
ș
or, prac tic dovedit
ș
i specific nivelului;
●
Modifică / men
ț
ine constant / men
ț
ine regulat practicile A gile utilizate cel mai frecvent;
●
Oferă extensii utile practicilor comune Agile;
●
Motivează practicile Agile într-un context al întreprinderii;
●
Oferă o imagine completă de dezvoltare de software;
21
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
●
Vizibilitatea sau transparen
ț
a este prezentă pe toate nivelurile;
●
Continuă sau face feedback regulat cu privire la calitate
ș
i îmbunătă
ț
ire.
3.2 Funda
ț
ia Scaled Agi le Framework:
1.
Principiile Lean-Agile;
2.
Valorile de bază;
3.
Conducere Lean-Agil;
4.
Mod de gândire Lean-Agile;
5.
Comunită
ț
i de pra ctică (grup de oameni care lucrează constant la practicile SAFe);
6.
Implementarea 1-2-3.
3.2.1 Principiile SAFe Lean-Agile
[30]
:
Aceste principii
ș
i valori de bază pentru SAFe trebuie în
ț
elese, expuse
ș
i continuate pentru a ob
ț
ine
rezultatele dorite:
●
Ave
ț
i o perspectiv ă economică;
●
Aplica
ț
i sisteme d e gândire;
●
Asumă variabilitatea; păstra
ț
i op
ț
iunile;
●
Construi
ț
i treptat cu cicluri rapide de învă
ț
are integrate;
●
O evaluare obiectivă a sistemelor de lucru;
●
Vizualiza
ț
i
ș
i limita
ț
i
WIP
[31]
(lucrări în curs), reduce
ț
i dimensiunile lotului
ș
i gestiona
ț
i
lungimile cozii;
●
Aplica
ț
i caden
ț
a, sincroniza
ț
i cu planificarea dintre mai multe domenii;
●
Deblochează motiva
ț
ia intrinsecă a lucrătorilor pregatiti;
●
Descentraliza
ț
i luarea deciziilor.
3.2.2 SAFe Agile – Valori de bază:
SAFe Agile se bazează pe aceste patru valori.
a)
Alinierea:
●
SAFe acceptă alinierea.
●
Alinierea începe de la:
22
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
○
Teme strategice în portofoliul de datea and;
○
Se deplasează la Vision
ș
i Road Map a listelor de date
ș
i apoi;
○
Se mută în Backlog-urile echipei.
b)
Calitate încorporată:
●
Se asigură că fiecare livrare incrementală reflectă standardele de calitate;
●
Calitatea nu este „adăugată mai târziu” este încorporată de la început;
●
Calitatea încorporată este o condi
ț
ie prealabilă a Lean
ș
i este obligatorie.
c)
Transparentă:
●
Transparen
ț
a este facilitatorul încrederii;
●
SAFe ajută compania să ob
ț
ină transparen
ț
ă la toate nivelurile – Executivi, manageri de
portofoliu
ș
i alte păr
ț
i interesate;
●
Toată lumea poate vedea în portofoliu Backlog / Kanban, Backlogs de programe /
Kanban
ș
i Team Backlog / Kanban;
●
Fiecare nivel are o în
ț
elegere clară a obiectivelor
PI
[31]
;
●
Programele Train au vizibilitate în întârzierile echipei, precum
ș
i alte date din program;
●
Echipele
ș
i programele au vizibilitate în Epics.
d)
Executarea programelor:
●
SAFe pune accentul pe sistemele de lucru
ș
i pe rezultatele afacerii.
●
SAFe nu este util dacă echipele nu pot executa
ș
i oferi în mod continuu valoare.
3.2.3 Liderii Lean Agile:
Liderii Lean Agile sunt studen
ț
i
ș
i profesori pe tot parcursul vie
ț
ii. Ajută echipele să construiască
sisteme mai bune prin în
ț
elegerea
ș
i expunerea Principiilor Lean- Agile SAFe.
În calitate de facilitator pentru echipe, responsabilitatea finală este adoptarea, succesul
ș
i îmbunătă
ț
irea
continuă a evolu
ț
iilor Lea n-Agile. Pentru schimbare
ș
i îmbunătă
ț
ire continuă, liderii trebuie să fie
instrui
ț
i.
Principiile acestor lideri Lean-Agile
●
Conduce schimbarea;
●
Cunoa
ș
te calea; A ccentuează învă
ț
area pe tot parcursul vi e
ț
ii;
●
Dezvolta
ț
i oamen ii;
●
Inspira
ț
i
ș
i alinia
ț
i la misiune; Minimizează restric
ț
iile;
●
Descentralizarea luării deciziilor;
●
Debloca
ț
i motiva
ț
ia intrinsecă a lucrătorilor califica
ț
i.
23
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
3.2.4 Modul de gandire in Agile:
Modul de gandire in Agile este reprezentat de doua lucruri:
A.
The SAFe House of Lean;
B.
Manifestul Agile.
A. The SAFe House of Lean
:
Obiectivul Lean este imbatabil: Pentru a oferi o valoare maximă a clientului în cel mai scurt timp, cu
cea mai înaltă calitate posibilă clientului.
În figura mai jos sunt explicate Obiectivul, Stâlpii
ș
i Funda
ț
ia „SAFe House of Lean”
[33]
.
24
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
B. Manifestul Agile
Descoperim modalită
ț
i mai bune de a dezvolta software. Prin această lucrare am ajuns să punem în
valoare:
25
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
[34]
De aceea, de
ș
i există o valoare în articolele din dreapta, valorizăm mai mult elementele din stânga.
3.3 Manifestul Agile
1.
Cea mai mare prioritate este satisfacerea clientului printr-o livrare continuă
ș
i timpurie a unui
software valoros;
2.
Îmbră
ț
i
ș
a
ț
i cerin
ț
ele în schimbare, chiar târziu în dezvoltare. Procesele agile valorifică
schimbările în beneficiul clientului;
3.
Furniza
ț
i un softw are func
ț
ional frecvent, de la câteva săp tămâni la câteva luni, cu o preferin
ț
ă
pe termenul cat mai scurt;
4.
Dezvoltatorii
ș
i oamenii de afaceri trebuie să colaboreze zilnic pe toată durata proiectului;
5.
Construi
ț
i proiect e în jurul unor persoane motivate. Dă-le sprijin
ș
i mediul de care au nevoie
ș
i
ai încredere în ei pentru a-
ș
i termina munca;
6.
Cea mai eficientă metodă de comunicare cu o echipă de dezvoltare este o conversa
ț
ie fa
ț
ă în
fa
ț
ă;
7.
Software-ul func
ț
ional este măsura principală a progresului;
26
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
8.
Procesele agile promovează dezvoltarea durabilă. Sponsorii, dezvoltatorii
ș
i utilizatorii ar
trebui să poată men
ț
ine un ritm constant la nesfâr
ș
it;
9.
O aten
ț
ie continuă la excelen
ț
a tehnică
ș
i un design bun îmbunătă
ț
e
ș
te agilitatea;
10.
Simplitatea – arta de a maximiza cantitatea de muncă nerealizată – este esen
ț
ială;
11.
Cele mai bune arhitecturi, cerin
ț
e
ș
i proiecte apar din echi pe de auto-organizare;
12.
La intervale regulate, echipa reflectă asupra modului de a deveni mai eficace, apoi ajustează
ș
i
î
ș
i reglează compo rtamentul în consecin
ț
ă.
3.3.1 Nivelul echipei
Toate echipele SAFe fac parte dintr-unul
Agile Release Train
[35]
(ART):
●
Echipele SAFe sunt echipe împuternicite, auto-organizatoare, autogestionatoare;
●
Fiecare echipă este la fel de responsabilă pentru definirea, construirea
ș
i testarea Story-urilor
din Backlog-ul echipei lor într-o itera
ț
ie de lungime fixă;
●
Echipele planifică
ș
i execută itera
ț
ii într-un timp de două săptămâni, în conformitate cu
obiectivele convenite;
●
Echipele vor folosi rutina Scrum / Kanban pentru a livra sisteme de înaltă calitate
ș
i pentru a
efectua un Demo către echipa de UAT
[36]
la fiecare două săptămâni;
●
Toate echipele diferite din ART vor crea un sistem integrat
ș
i testat. Păr
ț
ile interesate vor
evalua
ș
i vor răsp unde cu feedback rapid;
●
Acestea aplică practici de calitate deja încorporate.
●
Fiecare echipă Scrum va avea 5-9 membri, care include toate rolurile necesare pentru a
construi o valoare incrementală a calită
ț
ii în fiecare itera
ț
ie.
●
Rolurile Scrum includ:
○
Echipa(Dev+QA);
○
SM;
○
PO, Etc..
●
SAFe împarte cronologia de dezvoltare într-un set de itera
ț
ii în cadrul unui PI (Program
Increment);
●
Durata PI este cuprinsă între 8-12 săptămâni;
●
Echipa va folosi Story-uri pentru a oferi valoarea. PO-ul va avea autoritatea asupra creării
ș
i
acceptării Story-urilor;
●
Story-urile con
ț
in cerin
ț
ele Clientului;
●
Backlog-ul include user story-uri care sunt identificate în timpul planificării PI.
●
Identificarea, elaborarea, prioritizarea, programarea, implementarea, testarea
ș
i acceptarea
story-urilor sunt cerin
ț
ele principale ale activită
ț
ii de management la nivel de echipă.
●
Fiecare itera
ț
ie oferă:
27
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
○
O cre
ș
tere valoroasă a noilor func
ț
ionalită
ț
i;
○
Realizarea prin model repetat constant;
○
Planificarea itera
ț
iei;
○
Angajarea unor func
ț
ionalită
ț
i;
○
Executarea iteratiilor construind
ș
i testând Story-uri;
○
Demo către UAT a noilor func
ț
ionalită
ț
i;
○
Retrospectiva;
○
Repeta
ț
i următoarea itera
ț
ie;
●
Echipele sprijină, de asemenea, Demo-ul de sistem la sfâr
ș
itul fiecărei itera
ț
ii. care este punctul
de integrare critic pentru ART;
●
Fluxurile cu valoare mai mare vor avea mai multe ART-euri;
●
Itera
ț
iile de
inova re
ș
i planificare
[37]
(IP)
valorifică echip ele cu o oportunitate de inovare
ș
i
explorare.
3.3.2 Nivel de program
La nivel de program, Valoarea SAFe este livrată de Agile Release Train (ART). Iterarea este
pentru echipă, iar Train este pentru program:
●
Agile Release Train (ART) este vehiculul principal pentru livrarea valorii la nivelul
programului. Oferă un flux de valoare organiza
ț
iei;
●
Durata Program Increment (PI) este de 8 până la 12 săptămâni;
●
ART este format din 5 – 12 echipe Agile (~ 50 – 125+ persoane), care includ toate rolurile
ș
i
infrastructura necesară pentru a furniza software complet testat, func
ț
ional, la nivel de sistem;
●
Fiecare PI este o casetă de timp cu mai multe itera
ț
ii. În timpul căruia este dezvoltată
ș
i livrată
o incrementare valoroasa;
●
În fiecare PI, se vor întâmpla sesiuni „demo”
ș
i „Inspectare
ș
i adaptare”;
●
La nivel de program, SAFe pune accent pe principiul alinierii. Acest lucru se datorează faptului
că eforturile multiple ale echipei sunt integrate pentru a crea valoare clien
ț
ilor;
●
Ierarhia artefactului SAFe este Epics-> Func
ț
ii-> Story-uri de utilizator(User Story);
●
La nivel de program, PM / Manager de programe are autoritate pe con
ț
inut. El define
ș
te
ș
i
acordă prioritate datei de întârziere a programului;
●
Documentul de rezervă al programului este o listă prioritară de func
ț
ii;
●
La nivel de program, caracteristicile pot fi create sau pot proveni din Epice-uri definite la nivel
de portofoliu;
●
Func
ț
iile se desco mpun în Povesti de Utilizator
ș
i se transferă în documentele de la nivel de
echipă;
28
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
●
Rolul Managerului de Produs sau al Release Train Engineer ar putea fi gestionat de Managerul
de program / Manager de proiect senior;
●
Rolul arhitectului de sistem la nivelul programului este de a colabora zilnic cu echipele. Se
asigură că sunt îndeplinite cerin
ț
ele nefunc
ț
ionale. De asemenea, lucrează cu arhitectul
întreprinderii la nivel de portofoliu pentru a se asigura că există o pistă arhitecturală suficientă
pentru a sus
ț
ine n evoile viitoare ale utilizatorilor
ș
i ale afacerii;
●
Proiectarea interfe
ț
ei, ghidul experien
ț
ei utilizatorului
ș
i elementele de design pentru echipe
sunt furnizate de UX Designers;
●
Chief-Scrum Master rolul este jucat de „Release Train Engineer”;
●
O echipă diversă (de la marketing, dezvoltare, calitate, opera
ț
iuni
ș
i desfă
ș
urare) formează
„Echipa de gestionare a eliberării”. Ace
ș
tia vor aproba comunicările de rutină ale solu
ț
iilor de
calitate pentru clien
ț
i;
●
Implementarea software-ului în mediile clien
ț
ilor
ș
i livrarea cu succes este efectuata de echipa
DevOps.
3.3.3 Nivelul portofoliului
Cel mai înalt nivel de interes / îngrijorare / implicare / în SAFe este SAFe Portfolio:
●
Portofoliul oferă blocurile de bază pentru organizarea fluxului de valoare pentru Lean-Agile
prin unul sau mai multe fluxuri de valori;
●
Portofoliul ajută la dezvoltarea de sisteme
ș
i solu
ț
ii descrise în teme strategice (leagă un
portofoliu SAFe la schimbarea strategiei de afaceri a unei companii);
●
Pentru îndeplinirea obiectivelor strategice, nivelul portofoliului încapsulează aceste elemente.
Acesta oferă bugetele de bază
ș
i alte mecanisme de guvernare. În acest fel, se asigură că
investi
ț
ia în fluxu rile de valori oferă randamentele necesare companii;
●
Un portofoliu este conectat bidirec
ț
ional pentru afaceri:
○
Pentru a ghida portofoliul către obiectivele mai mari ale afacerii în schimbare, oferă
teme strategice;
○
O altă direc
ț
ie indică fluxul constant al valorilor portofoliului.
●
Nivelul portofoliului SAFe con
ț
ine oameni, procese
ș
i sisteme de solu
ț
ie necesare
ș
i solu
ț
ii de
care o companie trebuie să î
ș
i îndeplinească obiectivele strategice;
●
Fluxurile de valoare sunt obiectivele principale în Portofoliu, cu ajutorul cărora se pot finan
ț
a
persoane
ș
i alte re surse necesare pentru construirea solu
ț
iilor;
●
Conceptele cheie utilizate aici sunt:
○
Conexiune la Enterprise,
○
Managementul portofoliului de programe,
29
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
○
Gestionarea Epice-lor fluxului de portofoliu.
3.3.4 Nivelul fluxului valoric
Nivelul fluxului valoric este op
ț
ional în SAFe:
●
Nivelul fluxului valoric este destinat / proiectat pentru companiile / organiza
ț
iile care sunt:
1.
De dimensiuni mari;
2.
Independente;
3.
Avand solu
ț
ii complexe;
4.
Solu
ț
iile lo r necesită de obicei mai multe ART-uri;
5.
Au contribu
ț
ia furnizorilor;
6.
Se confruntă cu cele mai mari provocări ale sistemelor;
7.
Pentru sisteme cyber-fizice;
8.
Pentru software, hardware, electricitate
ș
i electronică, optică, mecanică, fluidică
ș
i
multe altele.
●
Construirea acestui tip de sisteme necesită adesea sute, chiar mii de practicieni, furnizori
externi
ș
i interni.
●
Dacă sistemele sunt cruciale pentru misiune. E
ș
ecul solu
ț
iei, sau chiar un subsistem, are
consecin
ț
e econom ice
ș
i sociale inacceptabile.
●
Dacă companiile pot fi construite cu câteva sute de practicieni, este posibil să nu aibă nevoie de
construc
ț
iile acest ui nivel.
●
Construirea solu
ț
iilor de flux de valori într-un model Lean-Agile necesită artefacte
suplimentare, coordonare
ș
i construc
ț
ii. Deci, acest nivel c on
ț
ine un cadru economic care să
ofere limite financiare pentru fluxul valoric.
●
Suporta caden
ț
a
ș
i sincronizarea pentru mai multe ART-u ri
ș
i furnizori. Include reuniuni de
planificare pre
ș
i post PI
ș
i solu
ț
ie demonstrativă.
●
Oferă roluri suplimentare care sunt: Engineer Stream Value, Architect Solution / Engineering
ș
i Management So lution.
30
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
4. Testarea
ș
i calitatea în cadrul SAFe
[38]
4.1 Calitate la nivel de echipă
Una dintre valorile de bază ale SAFe este calitatea cu care este construită în interior. Practicile de
calitate încorporate se asigură că fiecare element din solu
ț
ie, la fiecare cre
ș
tere, respectă standardele de
calitate adecvate pe toată durata dezvoltării. SAFe recomandă construirea de teste înainte de scrierea
codului. O altă practică recomandată de SAFe este munca în pereche. La nivel de echipă, testerii pot,
de exemplu, să se asocieze atât cu utilizatorii cât
ș
i cu dezvoltatorii pentru a co-crea teste. Testerii care
nu pot scrie cod, pot încă să se asocieze cu membrii echipei lor
ș
i să examineze testele automate
ș
i să
discute frecven
ț
a cu care trebuie efectuate testele. Testerii pot juca un rol principal pentru a se asigura
că to
ț
i membrii echipei în va
ț
ă
ș
i folosesc metode de testare Agile. De exemplu. prin facilitarea
discu
ț
iilor cu echipa desp re modul de introducere a metodelor precum ATDD
ș
i BDD. Când utiliza
ț
i
ATDD
ș
i / sau BDD, test erii pot sus
ț
ine PO-ul
ș
i pot încuraja ca în timpul perfec
ț
ionării să se partajeze
cele mai comune exemple
ș
i să se asigure că sunt discutate excep
ț
iile. Această practică oferă echipei
de dezvoltare o bună în
ț
elegere a problemelor care trebuie rezolvate. Pe tot parcursul dezvoltării de
Story-uri
ș
i caracteristici, testerii se pot asocia cu membrii echipei pentru a defini
ș
i testa
constrângerile. Acela
ș
i lucru este valabil
ș
i pentru testarea nefunc
ț
ională. Împerechează cu PO-ului sau
31
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
cu BA pentru a lua în considerare aspecte nefunc
ț
ionale. Dacă testerii au abilită
ț
i de securitate sau
performan
ț
ă, pot contribu i
ș
i la testarea nefunc
ț
ională în echipele Agile.
La un nivel mai practic, testerii ar putea revizui
Definition of Done
[39]
(DOD) pentru a ajuta echipele
să definească măsuri de calitate pentru subiecte precum integrarea end-to-end
ș
i testarea
nonfunctionala. DOD este un instrument excelent pentru integrarea calită
ț
ii în proces. În timp ce
discută membrii echipei este posibil să identifice teste valoroase care nu sunt făcute sau făcute în afara
sprintului. Compara
ț
ia de fini
ț
iei efectuate de o echipă cu cea a ce lorlalte echipe permite alinierea între
echipe.
În practică, adesea, vedem că executarea testelor se face încă manual
ș
i dacă unele teste sunt rulate
automat, acestea au fost de obicei create după ce codul a fost făcută scris, în loc de a folosi o abordare
de
test-first
. Testele automatizate (dacă există) sunt adesea rulate de pe o platformă separată care nu
este integrată în procesul de compilare, iar procesul de eliberare este adesea doar par
ț
ial automatizat
ș
i
un proces vulnerabil. SAFe afirmă că organiza
ț
iile ar trebui să urmărească un proces de construire
repetitiv
ș
i îndemânatic c are să permită implementarea rapidă în diverse medii. Testerii pot contribui
subliniind necesitatea acestui lucru
ș
i asigurând că sunt incluse teste automate de regresie func
ț
ională
ș
i non-func
ț
ională. De
ș
i multe dintre măsurile men
ț
ionate nu sunt noi pentru dezvoltatori, având un
fundal de
Continuous Integration/Continuous Deployment
[40]
(CI / CD), multe organiza
ț
ii continuă
să implementeze aceste practici. Din păcate, SAFe nu abordează în mod explicit necesitatea unei
strategii de calitate eficiente pentru a sprijini echipele Agile. Credem că testerii, managerii de testare
ș
i
al
ț
i profesioni
ș
ti de testare pot contribui la nivel de echipă prin at ragerea aten
ț
iei asupra practicilor de
calitate
ș
i necesitatea une i strategii de calitate. Oferim valoare ajutând la implementarea practicilor
relevante de asigurare a calită
ț
ii
ș
i testare.
4.2 Calitate la nivel de program
Testerii profesioni
ș
ti pot adăuga valoare prin promovarea unui mod de lucru de calitate
ș
i prin
definirea
ș
i implementare a unei strategii de calitate buna. Strategia de calitate va fi definită cel mai
probabil la nivelul Programului. Întrucât define
ș
te ceea ce este necesar pentru ca o solu
ț
ie integrată
ș
i
testată să fie livrată clien
ț
ilor. Implementarea acesteia va avea, de asemenea, un impact asupra
nivelului echipei. O strategie de calitate asigură că este clar ceea ce este esen
ț
ial din diverse
perspective, atât de afaceri, tehnologice
ș
i opera
ț
ionale. Prezintă ce trebuie testat
ș
i cum se face acest
lucru. Poate fi eficient să includă punctele de vedere
ș
i interesele furnizorilor externi
ș
i ale păr
ț
ilor
interesate, cum ar fi ofi
ț
erul de conformitate. SAFe folose
ș
te framework-ul de testare Agile al lui
Brian Marick
[41]
ca ghid pentru a determina diferitele abordări pe care le poate adopta. Dar credem că o
strategie de calitate ar trebui să definească
ș
i modul în care se adună feedback-ul privind calitatea
ș
i
progresul produsului. Este important ca obiectivele PI să fie utilizate pentru a direc
ț
iona colec
ț
ia de
feedback
ș
i informa
ț
ii. Strategia de calitate poate schi
ț
a cum se întâmplă acest lucru în practică. O
strategie de calitate ar trebui, de asemenea, să abordeze calitatea testelor. Lucrările de testare au nevoie
32
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
de audit
ș
i cum sunt antre nate echipele la testarea lor? În unele organiza
ț
ii, managerii de testarea ajută
echipa prin efectuarea scanărilor de îmbunătă
ț
ire a testelor
ș
i facilitarea echipei cu adoptarea de
practici de automatizare a testelor
ș
i CI / CD. Un alt element de abordat în strategia calită
ț
ii este
organizarea testelor care nu se încadrează într-un sprint. În practică, vedem prea des organiza
ț
ii care
nu au o privire de ansamblu
ș
i concentrare. O strategie clară de calitate, care aliniază echipele
ș
i
munca lor
ș
i oferă o persp ectivă comună asupra activită
ț
ii care trebuie realizată. Acest lucru nu duce
numai la solu
ț
ii de calitat e mai bună, ci reduce
ș
i surprizele întârziate
ș
i permite echipelor să discute
despre progres, impedimente
ș
i să-
ș
i planifice foaia de parcurs, da că este necesar. Se asigură că
echipele
ș
tiu ce se a
ș
teaptă de la ei, testarea nu este uitată
ș
i oferă loc antrenării
ș
i predării echipelor.
Aceasta din urmă este o problemă cheie. Odată cu adoptarea de Agile, testarea este o responsabilitate a
echipei
ș
i, cel mai adesea , testarea este făcută de dezvoltatori
ș
i utilizatori care au o expertiză limitată
în testare. Se simt incerti în ceea ce prive
ș
te modul în care testează sau le lipse
ș
te entuziasmul,
deoarece nu în
ț
eleg ce să facă. Considerăm că pot face o treabă
ș
i mai bună atunci când primesc
instruire relevantă
ș
i sunt ajuta
ț
i de testeri cu experien
ț
ă să îmbunătă
ț
ească proiectarea, execu
ț
ia,
asisten
ț
a instrumentelor, înregistrarea
ș
i raportarea. Dezvoltatorii
ș
i utilizatorii vor permite
organiza
ț
iilor să aibă o pr ivire multidisciplinară asupra calită
ț
ii
ș
i vor cre
ș
te flexibilitatea echipei. În
unele organiza
ț
ii, vedem că persoanele cu rol de conducere de calitate se alătură comunită
ț
ii de
practică
ș
i ini
ț
iază evenimente de îmbunătă
ț
ire, instruire
ș
i cuno
ș
tin
ț
e.
În SAFe ultimul sprint din PI este rezervat pentru planificarea PI-ului
ș
i, dacă este nevoie, integrarea
diferitelor active ale sistemului sau solu
ț
iei. Testerii pot contribui în mod obi
ș
nuit la acest sprint cu
facilitarea analizei riscurilor
ș
i a analizei cauzelor rădăcină (Root cause analysis – RCA). Identificarea
riscurilor de afaceri
ș
i tehnice înainte sau în timpul planificării PI poate duce la criterii suplimentare de
acceptare sau chiar la noi Story-uri pentru a acoperi riscurile specifice care trebuie să fie disponibile în
timp ce planifică următorul PI. Multe organiza
ț
ii nu efectuează în mod regulat RCA. De aceea, ei nu
reu
ș
esc să în
ț
eleagă rela
ț
ia dintre incidente
ș
i testare. Prin configurarea unei bucle de feedback, testerii
pot ajuta organiza
ț
ia să cr eeze solu
ț
ii potrivite
ș
i să se asigure că echipele Agile
ș
tiu ce teste contează
cel mai mult. În timpul planificării PI de obicei managerul de dezvoltare senior explica practicile de
dezvoltare. Ar fi firesc ca managerii de teste să discute cu managerul de dezvoltare senior cum să
îmbunătă
ț
ească automatiz area testelor
ș
i să asigure linii directoar e clare pentru echipa Agile. Al
ț
i
parteneri cheie pentru testeri
ș
i manageri de testare sunt persoanele din diversele roluri de arhitect
SAFe care sunt responsabile pentru viziunea arhitecturii, construind pista arhitecturală
ș
i ajutând
echipele Agile să-
ș
i îmbu nătă
ț
ească continuu excelen
ț
a tehnică. Construirea caracteristicilor
ș
i
func
ț
ionalită
ț
ii testabile care cre
ș
te testabilitatea este vitală pentru a men
ț
ine ritmul
ș
i a oferi valoare.
Testarea integrării
ș
i integ rarea este o provocare cheie pentru organiza
ț
iile la scară largă, deoarece este
greu de organizat activită
ț
i în echipă din interiorul echipelor. Nivelul programului SAFe este conceput
pentru a ajuta la ameliorarea provocărilor tipice de integrare. Testerii
ș
i managerii de testarea ar trebui
33
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
să sublinieze importan
ț
a testării , astfel încât testarea integrării să fie luată în considerare la PI
Planning.
O altă provocare tipică la nivelul Programului este de a ne asigura că sunt disponibile medii adecvate
de testare. Testele de integrare, a
ș
a cum am men
ț
ionat anterior, ar trebui să fie executate în fiecare
itera
ț
ie, dar unele teste ar putea fi mai bune de efectuat în ultimul sprint al PI.
Pentru a ob
ț
ine feedback
ș
i a afla cum este folosit sistemul, este i mportant ca solu
ț
iile software să fie
implementate
ș
i oferite ut ilizatorilor săi frecvent
ș
i cu cât mai pu
ț
ine întârzieri posibil. Testarea
modelului de opera
ț
iune p entru a asigura pregătirea opera
ț
ională ar trebui să fie un subiect în timp ce
se definesc obiectivele PI.
O altă provocare în cadrul SAFe este guvernarea. Am observat că progresul
ș
i calitatea sunt adesea
discutate într-o
ș
edin
ț
ă
Scrum-of-Scrums
[42]
, dar indica
ț
iile de progres sunt adesea subiective
ș
i
incomplete. Testarea ajută la o informa
ț
ie transparentă
ș
i obiectivă a software-ului de lucru disponibil.
Asigura
ț
i-vă că sunt dispo nibile date
ș
i medii adecvate pentru a e valua progresul lansării.
Pentru a rezuma multe dintre măsurile descrise ca se încadrează bine în CI / CD, unde identificăm
continuu nevoile pie
ț
ei
ș
i ne propunem să ob
ț
inem solu
ț
ia integrată testată în produc
ț
ie cât mai curând
ș
i des. SAFe nu descrie a ceste practici în detaliu. Prin urmare, integrarea componentelor
ș
i sistemelor
în mod regulat provoacă cea mai mare parte a ART-urilor în Agile. Profesioni
ș
tii în testare pot
contribui prin sus
ț
inerea u nui mod de gândire de calitate, descris într-o strategie de calitate,
coordonând
ș
i planificând practicile de calitate cu persoane relevante atât înainte cât
ș
i în timpul
planificării PI, cât
ș
i oferi nd contribu
ț
ii ale testarii în discu
ț
iile din jurul progresului
ș
i în evaluarea
software-ului de lucru.
4.3 Calitate la nivel de portofoliu
La nivel de portofoliu, temele strategice sunt transpuse în fluxuri de valoare
ș
i Epice-uri. Acest nivel
este pinul de legătură între obiectivele organiza
ț
ionale
ș
i activitatea de dezvoltare care se realizează.
Acest lucru con
ț
ine
„ce”
ș
i
„cum”,
atât aspecte tehnice, cât
ș
i culturale. Da că dorim să încorporam
calitatea în organiza
ț
ie, ac easta ar trebui realizată la acest nivel. SAFe nu define
ș
te un ambasador de
calitate, dar considerăm că ar putea exista un rol important pentru cineva la acest nivel.
Dacă ne uităm la procesele SAFe, el / ea ar putea contribui prin:
4.3.1 Definirea temelor strategice cu un accent pe calitate
Asigura
ț
i-vă că, atunci câ nd sunt definite temele strategice, acestea nu se concentrează numai pe
„func
ț
ionalitatea de aface ri nouă”. Reducerea datoriei tehnice, arhitectura testelor, sus
ț
inerea
ș
i
dezvoltarea unor bune practici de evaluare a calită
ț
ii trebuie, de asemenea, să fie prioritare, deoarece
acestea permit o rată de livrare durabilă. În timp ce echipele IT încearcă să ob
ț
ină timp
ș
i bani pentru a
34
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
optimiza peisajul IT, rămâne o luptă pentru a aborda aceste elemente datorită faptului că calitatea este
insuficient acceptată.
4.3.2 Prioritizează conformitatea Epice-lor
Conformitatea ar trebui planificată
ș
i păzită. La nivel de portofoliu, asigura
ț
i-vă că sunt definite
Epice-urile de conformitate
ș
i func
ț
ionalitatea necesară cu privire la securitatea, trasabilitatea
ș
i
asigurarea veniturilor este implementată. Un accent de calitate va asigura că dovada corectă
(înregistrarea, testarea controalelor
ș
i a documenta
ț
iei) este disponibilă. Acest lucru va ie
ș
i în eviden
ț
ă
în timpul auditurilor
ș
i va reduce alinierea ratelor între ceea ce este necesar de către autorită
ț
i
ș
i ceea
ce este pus în aplicare. SAFe descrie Sistemul de Management al Calită
ț
ii –
Quality Management
System
(QMS) ca un set de practici, politici
ș
i proceduri aprobate. QMS se asigură că activită
ț
ile de
dezvoltare
ș
i rezultatele r espectă toate reglementările relevante
ș
i furnizează documenta
ț
ia necesară
pentru a dovedi acest lucru. QMS ar putea fi în portofoliul ofi
ț
erului de conformitate, dar ambasadorul
calită
ț
ii ar trebui să includ ă
ș
i QMS în strategia de calitate.
4.4 Un rol pentru testeri, manageri de testare
ș
i al
ț
i profesioni
ș
ti de calitate
În sec
ț
iunile anterioare am oferit câteva exemple de considerente de calitate care pot fi făcute în
diferite niveluri ale SAFe. Comunicarea
ș
i gestionarea dependen
ț
elor sunt provocări tipice ale scalării.
Măsurile discutate se concentrează pe a avea o strategie, luând în considerare calitatea în timpul
sesiunilor de planificare
ș
i să se asigure că lucrările legate de calitate au prioritate suficientă.
Constatăm că este nevoie de o concentrare de calitate la toate nivelurile.
Oamenii care sunt în prezent în roluri testare
ș
i alte roluri de calitate au multe cuno
ș
tin
ț
e
ș
i pot lua un
rol de ambasador
ș
i să se asigure că calitatea este încorporată. Pentru profesioni
ș
tii de testare, acest
lucru ar putea necesita o anumită abilitate. Automatizarea testelor
ș
i implementarea CI / CD necesită
cuno
ș
tin
ț
e tehnice la nivelul echipei. Pentru a fi eficient la nivel d e program
ș
i de portofoliu, va trebui
să dobânde
ș
ti abilită
ț
i de afaceri. Pentru a face SAFe, profesioni
ș
tii de testare eficientă îi pot ajuta pe
ceilal
ț
i să creeze calitate
ș
i să faciliteze colaborarea largă. Acest l ucru înseamnă că profesioni
ș
tii care
nu testează se vor focusa asupra practicilor de calitate
ș
i testare. Îi putem ajuta prin coaching, predare
ș
i arătându-le avantajele s trategice pe care le poate avea un profesionist de calitate. Scalificarea
necesită munca în echipă a tuturor oamenilor pentru ca aceasta să func
ț
ioneze. Testerii ar putea foarte
bine să conducă pentru a crea con
ș
tien
ț
a că adevărata agilitate a a facerii necesită o calitate integrată.
Ș
i
faptul că punerea în aplicare a cadrului Agile la scară cu ghidul său actual privind practicile de calitate
nu este suficientă. Necesită aten
ț
ie la toate nivelurile, disciplina
ș
i ambasadorii de calitate, care sunt
gata să ajute la construirea de solu
ț
ii de calitate.
35
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
5. Crearea unui Framework de testare automat
ă
Testarea automată este procesul de scriere a codului care testează automat aplica
ț
ia fără a
necesita nicio interven
ț
ie umană, iar rezultatele produse pot fi analizate pentru testare sau raportare
ulterioară, ceea ce reduce în continuare eforturile de testare
ș
i ajută la furnizarea de software de
calitate mai rapid
ș
i mai a ccesibil. Ini
ț
ial necesită un cost pentru d ezvoltarea suitei de teste de
automatizare, dar ajută la furnizarea de software de calitate mai bună, cu mai pu
ț
in efort într-o
perioadă de timp, deoarece va fi necesară mai pu
ț
ină for
ț
ă de muncă pentru a efectua sarcini repetitive.
De
ș
i numeroase o rganiza
ț
ii folosesc testarea automatizata într-o mare măsură, totu
ș
i încă
depind enorm de testarea manuală. Acest lucru se datorează lipsei de cuno
ș
tin
ț
e despre avantajele
testării automate în procesul de dezvoltare a software-ului. Există un set de cazuri de test predefinite
care sunt executate în mod deliberat manual. Rezultatul fiecărui caz de test este apoi comparat cu
comportamentul scontat
ș
i raportarea rezultatelor sau a discrepan
ț
elor, dacă este găsit.
Testarea repetitivă sau repetarea unui set de executare a cazurilor de testare este foarte
obi
ș
nuită în modelele de dezvoltare de tip Agile. Testarea poate deveni o sarcină obositoare atunci
când vine vorba de testarea pe multiple platforme sau de browserere. Efectuarea unui lucru de mai
multe ori pentru diferite sisteme de operare nu numai că consumă mult timp, dar, de asemenea, mută
accentul de la func
ț
ionali tatea reală care urmează să fie livrată; mai ales când termenele sunt stricte.
Prin urmare, este esen
ț
ial ca testarea automată să fie făcută în aproape fiecare organiza
ț
ie pentru a
economisi timp
ș
i pentru a furniza un software de calitate.
Există multe instrumente disponibile pe pia
ț
ă în acest scop, dar
„Selenium
” se remarcă din
toate acestea atunci când vine vorba de testarea automată a aplica
ț
iilor web. Acum, când avem un
instrument atât de puternic, care este open source
ș
i are un suport comunitar mare, care se întinde pe
mai multe sisteme de operare, browsere
ș
i limbaje de programare; atunci apare întrebarea: Cu ce
limbaj de programare ar trebui folosită? După cum am men
ț
ionat deja, Seleniul este compatibil cu
numeroase limbaje de programare
ș
i anume:
Perl
,
Ruby
,
C #
,
Java
,
Python
ș
i a
ș
a mai departe.
5.1 Alegerea unui limbaj de programare
Seleniul
este instrumentul cel mai proeminent în domeniul testării automatizării, în timp
ce
Java
, pe de altă parte, este cel mai utilizat limbaj de programare pe pia
ț
a de astăzi. Ambele
tehnologii fac împreună o combina
ț
ie perfectă pentru testarea automată.
Motive pentru utilizarea Selenium împreuna cu Java pentru testarea automată:
36
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
●
Deoarece Java este un limbaj utilizat pe scară largă în industria IT, există o comunitate
uria
ș
ă care o sus
ț
ine împreună cu depozitul masiv de libră rii;
●
Aproape 77% dintre testerii Selenium folosesc Java, ceea ce face schimbul de cuno
ș
tin
ț
e
foarte u
ș
or
ș
i rapid;
●
Java este un limbaj matur,
ș
i din acest motiv deja exista o mul
ț
ime de cadre, plugin-uri,
API-uri
ș
i bibliote ci care sunt u
ș
or disponibile, care accep tă Java pentru automatizarea
testelor.
●
Java folose
ș
te JVM ceea ce îl face un limbaj independent de platformă. Cu alte cuvinte, îl
pute
ț
i folosi în ori ce mediu de operare unde este instalat JVM.
●
Deoarece Java este scris tipic, IDE-urile Java oferă o mul
ț
ime de feedback cu privire la
erorile cu care s-ar putea confrunta în timpul codării.
5.2 Alegerea unui Unit Test framework
Acum am selectat cel mai potrivit limbaj de programare, acum trebuie să alegem un
cadru de testare unitar pe care să ne bazăm. Întrucât am ales deja limbajul Java pentru a scrie
testele, o sa folosesc
TestNG
pentru a scrie testele unitare, deoarece oferă câteva avantaje
importante, cum ar fi:
●
TestNG
este similar cu
JUnit
, dar este mult mai puternic decât JUnit – mai ales în ceea
ce prive
ș
te testare a claselor integrate.
Ș
i mai bine, TestNG mo
ș
tene
ș
te toate avantajele pe
care JUnit le are de oferit.
●
TestNG
elimină majoritatea limitărilor cadrelor mai vechi
ș
i vă oferă posibilitatea de a
scrie teste mai flexibile
ș
i mai puternice. Unele dintre caracteristicile marcante sunt:
adnotări u
ș
oare, grupare, secven
ț
iere
ș
i parametrizare.
Codul de mai jos arată un exemplu de TestNG. Aici toate teste din framework folosesc acelea
ș
i
metode
setupDriver()
ș
i
quitDriver()
datorită adnotărilor
@BeforeTest
ș
i
@AfterTest
:
public
class
BaseTest
{
protected
WebDriver driver;
@BeforeTest
public
void
setupDriver
(ITestContext ctx)
throws
MalformedURLException {
String host =
"localhost"
;
DesiredCapabilities dc;
37
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
if
(System.getProperty(
"BROWSER"
) !=
null
&&
System.getProperty(
"BROWSER"
).equalsIgnoreCase(
"firefox"
)){
dc = DesiredCapabilities.firefox();
}
else
{
dc = DesiredCapabilities.chrome();
}
if
(System.getProperty(
"HUB_HOST"
) !=
null
){
host = System.getProperty(
"HUB_HOST"
);
}
String testName = ctx.getCurrentXmlTest().getName();
String completeUrl =
"http://"
+ host +
":4444/wd/hub"
;
dc.setCapability(
"name"
, testName);
this
.driver =
new
RemoteWebDriver(
new
URL(completeUrl), dc);
}
@AfterTest
public
void
quitDriver
(){
this
.driver.quit();
this
.driver =
null
;
}
}
Vă pute
ț
i gândi la o clasă de testare ca o grupare logică a unor cazuri de testare automate care au
acelea
ș
i obiective sau cel pu
ț
in aceea
ș
i zonă de focalizare.
De exemplu, se pot grupa cazuri de testare automate care se concentrează pe verificarea dacă
aplica
ț
ia calculează pre
ț
ul total al co
ș
ului de cumpărături într-o clasă de testare numită
TotalPriceCalculation
. Aceste teste împărtă
ș
esc probabil aceea
ș
i configura
ț
ie ini
ț
ială de navigare
pe site-ul de comer
ț
elect ronic testat
ș
i pa
ș
ii de eliminare a articolelor din co
ș
.
Cu
TestNG
, pute
ț
i grupa , de asemenea, testele din cadrul unei clase de test în subgrupuri
folosind adnotările
@Test
a
ș
a cum este demonstrat în următorul fragmentul de cod:
public
class
SearchTest
extends
BaseTest
{
@Test
@Parameters
({
"keyword"
})
public
void
search
(String keyword){
SearchPage searchPage =
new
SearchPage(driver);
searchPage.goTo();
38
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
searchPage.doSearch(keyword);
searchPage.goToVideos();
int
size = searchPage.getResult();
Assert.assertTrue(size >
0
);
}
}
5.3 Arhitectura framework-ului: Page Object Model
ș
i Page Factory
Page Object Mode
(POM) este un model de design, utilizat în mod automat în testarea
automată care creează Depozitul de obiecte(
Object Repository
) pentru elemente UI web.
Avantajul modelului este că reduce duplicarea codului
ș
i îmbunătă
ț
e
ș
te men
ț
inerea testelor.
Sub acest model, pentru fiecare pagină web din aplica
ț
ie, ar trebui să existe o clasă de pagină
(
Page Class
) corespunzătoare. Această clasă de pagină va identifica elementele Web ale acelei
pagini web
ș
i con
ț
ine, de asemenea, metode de pagină care efectu ează opera
ț
iuni pe acele
elemente Elemente Web. Numele acestor metode ar trebui să fie dat în func
ț
ie de sarcina pe care
o îndeplinesc, adică, dacă se a
ș
teaptă
să apară gateway-ul de plată, numele
metodei POM poate fi
waitForPaymentScreenDisplay()
.
39
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Page Object Model este un model de design de obiect în Selenium, unde paginile web sunt
reprezentate ca
ș
i clase, ia r diversele elemente de pe pagină sunt definite ca variabile din clasă. Toate
interac
ț
iunile utilizatorilo r posibile pot fi apoi implementate ca metode în clasă:
clickLoginButton();
setCredentials(user_name, user_password);
Deoarece metodele bine numite din clase sunt u
ș
or de citit, aceasta func
ț
ionează ca o modalitate
elegantă de a implementa rutine de test care sunt atât lizibile, cât
ș
i mai u
ș
or de între
ț
inut sau de
actualizat în viitor. De exemplu:
Pentru a sprijini modelul Page Object, folosim Page Factory.
Page Factory
din Selenium este
o extensie la Page Object
ș
i poate fi utilizată în diverse moduri. În acest caz, vom folosi Page Factory
pentru a ini
ț
ializa elemen te web definite în clase de pagini web sau Obiecte de pagină.
Clasele de pagini web sau obiectele de pagină care con
ț
in elemente web trebuie ini
ț
ializate
folosind Page Factory înainte de a putea fi utilizate variabilele elementului web. Acest lucru se poate
face doar prin utilizarea func
ț
iei
initElements
pe PageFactory:
SearchPage page =
new
SearchPage(driver);
PageFactory.initElements(driver, page);
Sau, chiar mai simplu:
SearchPage page = PageFactory.intElements(driver, SearchPage.class)
Sau, în interiorul constructorului clasei:
public
SearchPage
(WebDriver driver){
this
.driver = driver;
PageFactory.initElements(driver,
this
);
}
Page Factory
va ini
ț
ializa fiecare variabilă WebElement cu o referin
ț
ă la un element corespunzător de
pe pagina de web reală bazată pe configurate „locatoare“. Acest lucru se realizează prin utilizarea
adnotărilor
@FindBy
. Cu această adnotare, putem defini o strategie pentru căutarea în sus a
elementului, împreună cu informa
ț
iile necesare pentru identificarea acestuia:
40
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
@FindBy
(how=How.ID, using=
"SubmitLogin"
)
private
WebElement loginButton;
De fiecare dată când o metodă este apelată la această variabilă de tipul
WebElement
, driverul o va găsi
mai întâi pe pagina curentă
ș
i apoi va simula interac
ț
iunea. În cazul în care lucrăm cu o pagină simplă,
ș
tim că vom găsi element ul din pagină de fiecare dată când îl căutăm
ș
i, de asemenea,
ș
tim că în cele
din urmă vom naviga la alta pagină
ș
i nu ne vom mai întoarce la ea, putem cache-ui câmpul căutat
folosind o altă adnotare simplă(
@CacheLookup
):
@FindBy
(how=How.ID, using=
"SubmitLogin"
)
@CacheLookup
private
WebElement loginButton;
Această întreagă defini
ț
ie a variabilei WebElement poate fi înlocuită cu forma ei mult mai concisă:
@FindBy
(id =
"SubmitLogin"
)
private
WebElement loginButton;
Adnotarea @FindBy acceptă o serie de alte strategii care fac lucrurile un pic mai u
ș
oare:
id, name, className, css, tagName, linkText, partialLinkText, xpath
@FindBy
(id=
"username"
)
private
WebElement user_name;
@FindBy
(name=
"passsword"
)
private
WebElement user_password;
@FindBy
(className=
"h3"
)
private
WebElement label;
@FindBy
(css=
"#content"
)
private
WebElement text;
41
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Odată ini
ț
ializate, aceste variabile WebElement pot fi apoi folosite pentru a interac
ț
iona cu elementele
corespunzătoare din pagină, de exemplu:
user_password.sendKeys(password);
…trimite respectiva secven
ț
a de caractere la câmpul de parolă din pagină
ș
i este echivalent cu:
driver.findElement(By.name(
"user_password"
)).sendKeys(password);
Trecând mai departe, dacă suntem în situa
ț
ia în care trebuie să găsim o listă de elemente într-o pagină
ș
i atunci
@FindBys
este v arianta corecta de folosire:
@FindBys
(
@FindBy
(css=
"div[class='yt-lockup-tile yt-lockup-video']"
)))
private
List<WebElement> videoElements;
Codul de mai sus va găsi toate elementele
div
care au două nume de clasă „yt-lockup-tile”
ș
i
„yt-lockup-video”. Putem simplifica acest lucru
ș
i mai mult înlocuind-o cu următoarea comanda:
@FindBy
(how=How.CSS,using=
"div[class='yt-lockup-tile
yt-lockup-video']"
)
private
List<WebElement> videoElements;
În plus, pute
ț
i utiliza
@FindAll
cu mai multe adnotări
@FindBy
pentru a căuta elemente care se
potrivesc cu oricare dintre localizatoarele date:
@FindAll
({
@FindBy
(how=How.ID, using=
"username"
),
@FindBy
(className=
"username-field"
)})
private
WebElement user_name;
5.4
Exemplu proiect: Page Object Model
ș
i Page Factory
Proiectul este scris în Java + Selenium folosind IDE-ul IntelliJ Ultimate.
Este un proiect de tip Maven.
În fi
ș
ierul POM.xml avem următoarele configura
ț
ii:
<?xml version=
"1.0"
encoding=
"UTF-8"
?>
<project xmlns=
"http://maven.apache.org/POM/4.0.0"
42
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd"
>
<modelVersion>
4.0
.0</modelVersion>
<groupId>ro.utm.informatica</groupId>
<artifactId>LucrareLicenta</artifactId>
<version>
1.0
-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>
3.14
.0</version>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>
6.14
.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>
6.14
.3</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>
2.13
.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>
2.13
.2</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
43
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
<artifactId>slf4j-simple</artifactId>
<version>
1.7
.30</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.qameta.allure</groupId>
<artifactId>allure-testng</artifactId>
<version>
2.13
.2</version>
</dependency>
</dependencies>
<build>
<finalName>selenium-docker</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>
3.7
.0</version>
<configuration>
<compilerVersion>
1.8
</compilerVersion>
<source>
1.8
</source>
<target>
1.8
</target>
<testSource>
1.8
</testSource>
<testTarget>
1.8
</testTarget>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>prepare-
package
</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>
${project.build.directory}/libs
44
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>
3.2
.0</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>
3.0
.0-M4</version>
<configuration>
<suiteXmlFiles>
<suiteXmlFile>tests-suite.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>
</plugins>
</build>
</project>
Am creat Page Object “
SearchPage”
, care are urmatoarea structura:
package
com.searchmodule.pages;
import
org.apache.logging.log4j.LogManager;
import
org.apache.logging.log4j.Logger;
45
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
import
org.openqa.selenium.By;
import
org.openqa.selenium.Keys;
import
org.openqa.selenium.WebDriver;
import
org.openqa.selenium.WebElement;
import
org.openqa.selenium.support.FindBy;
import
org.openqa.selenium.support.PageFactory;
import
org.openqa.selenium.support.ui.ExpectedConditions;
import
org.openqa.selenium.support.ui.WebDriverWait;
import
java.util.List;
public
class
SearchPage
{
//aici este introdus logger-ul Log4j
private
static
final
Logger logger =
LogManager.getLogger(SearchPage.class);
private
WebDriver driver;
private
WebDriverWait wait;
//aici localizam elementul campului de cautare
@FindBy
(name =
"q"
)
private
WebElement searchTxt;
//aici localizam elementul butonul "Video"
@FindBy
(linkText =
"Videoclipuri"
)
private
WebElement videosLink;
//aici localizam toate clipurile de pe pagina
@FindBy
(className =
"g"
)
private
List<WebElement> allVideos;
public
SearchPage
(WebDriver driver){
this
.driver = driver;
this
.wait =
new
WebDriverWait(driver,
30
);
PageFactory.initElements(driver,
this
);
logger.debug(
"driver-ul este initializat"
);
//aici este
folosit logger-ul
}
46
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
//Metode:
//aici deschidem website-ul
public
void
goTo
(){
this
.driver.get(
"https://google.com"
);
}
//aici efectuam o cautare
public
void
doSearch
(String keyword){
this
.wait.until(ExpectedConditions.visibilityOf(searchTxt));
this
.searchTxt.sendKeys(keyword);
this
.searchTxt.sendKeys(Keys.ENTER);
logger.debug(
"pagina google este deschisa"
);
}
//aici suntem pe pagina cu rezultate
ș
i apasam pe butonul "Video"
public
void
goToVideos
(){
this
.wait.until(ExpectedConditions.visibilityOf(videosLink));
this
.videosLink.click();
logger.debug(
"butonul 'video' este ap
ă
sat"
);
}
//aici printam cate clipuri sunt diponibile pe pagina
public
int
getResult
(){
By by = By.className(
"g"
);
this
.wait.until(ExpectedConditions.numberOfElementsToBeMoreThan(by,
0
));
System.out.println(
this
.allVideos.size());
logger.debug(
"este afi
ș
at num
ă
rul total de clipuri diponibile
pe pagina"
);
return
this
.allVideos.size();
}
}
În Clasa
SearchPage
efectuam o căutare pe Google folosind anumit cuvant cheie, după ce
căutarea a fost făcută navigam pe tab-ul “video” după care numărăm cate video-uri sunt afi
ș
ate
pe pagina.
Cu clasele de obiecte de pagină care reprezintă paginile noastre
ș
i interac
ț
iunile utilizatorilor ca
metode ale acestora, putem acum să scriem rutina noastră de testare simplă ca o serie de apeluri
ș
i afirma
ț
ii de metode simple folosind clasa
“SearchTest”
din fol derul
Test
:
47
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
package
com.searchmodule.tests;
import
com.searchmodule.pages.SearchPage;
import
org.testng.Assert;
import
org.testng.annotations.Parameters;
import
org.testng.annotations.Test;
import
tests.BaseTest;
public
class
SearchTest
extends
BaseTest
{
//aici efectuam testul
@Test
@Parameters
({
"keyword"
})
//parametrul este setat din fisierul
.xml TestNG
public
void
search
(String keyword){
SearchPage searchPage =
new
SearchPage(driver);
searchPage.goTo();
searchPage.doSearch(keyword);
searchPage.goToVideos();
int
size = searchPage.getResult();
//aici stocam numarul de
videouri în variabila "size"
Assert.assertTrue(size >
0
);
//aici verificam ca numarul
total de video-uri este mai mare ca 0
}
}
Structura proiectului
arată în felul următor
(cuprinzând mai
multe teste):
48
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Concluzie
: Page Object
ș
i Page Factory fac u
ș
oară modelarea pa ginilor web în Selenium
ș
i fac via
ț
a
atât a dezvoltatorilor, cât
ș
i a testerilor mult mai simplă. Când sunt făcute corecte, aceste clase de
obiecte de pagină pot fi reutilizate pe întreaga suită de teste
ș
i pentru a vă oferi posibilitatea de a
implementa teste Selenium automatizate pentru proiectele dvs. din timp, fără a compromite
dezvoltarea Agile. Prin abstractizarea interac
ț
iunilor utilizatorilor din modelele de obiecte de pagină
ș
i
men
ț
inerea rutinelor de te stare u
ș
oare
ș
i simple, pute
ț
i adapta setul de teste la cerin
ț
ele schimbătoare,
cu pu
ț
in efort.
5.5 Alegerea unui mecanism de raportare
Generarea de rapoarte este foarte importantă atunci când efectua
ț
i testare automată, precum
ș
i pentru
testarea manuală. Analizând rezultatul, pute
ț
i identifica cu u
ș
urin
ț
ă câte cazuri de testare sunt trecute,
e
ș
uate
ș
i omise. Analizând raportul, ve
ț
i afla care este starea proiectului.
Selenium webdriver este utilizat pentru automatizarea aplica
ț
iei web, dar nu va genera
rapoarte. TestNG va genera raportul implicit. După ce sunt rulate testele apare folderul “
target
” în care
apare folderul “
surefire-reports
” de aici putem deschide fi
ș
ierul “
index.html
” pentru a vizualiza
raportul TestNG. Face
ț
i clic dreapta pe
index.html
ș
i deschide
ț
i cu browserul web.
Suplimentar am introdus
ș
i bibliotecile de la ter
ț
i, cum ar fi Allure Reports, care ne pot ajuta să
generam rapoarte cu rezultatele testelor care sunt mult mai bine explicate
ș
i prezentate. Pentru a
introduce acest raport în proiectul meu m-am folosit de Maven pentru a descărca dependintele:
<dependency>
<groupId>io.qameta.allure</groupId>
<artifactId>allure-testng</artifactId>
<version>
2.13
.2</version>
</dependency>
După ce testele sunt rulate în folderul sursa al proiectului apare folderul “
allure-reports
”, pentru a fi
afi
ș
at acest raport trebuie să rulăm următoarea comanda in terminal “
allure serve <folder_path>
”,
49
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
exemplu cu raportul Allure generat:
5.6 Implementarea Docker
Pentru a rula testele folosind un container Docker trebuie să construim un fi
ș
ier numit
“
Dockerfile
” în interiorul proiectului în care sa con
ț
ină următoarele comenzi:
#Imaginea de baz
ă
este urm
ă
toarea:
FROM openjdk:
8
u191-jre-alpine3.8
#Instalam
"curl"
ș
i
"jq"
în imaginea de mai sus
RUN apk add curl jq
#Spa
ț
iul de lucru de din Docker, este creat automat
WORKDIR /usr/share/proiectlicenta
#Adaugam fi
ș
ierele de tip .jar
ADD target/selenium-docker.jar selenium-docker.jar
ADD target/selenium-docker-tests.jar selenium-docker-tests.jar
ADD target/libs libs
#putem adauga mai multe tipuri de
fi
ș
iere
(.csv / .json etc), în
func
ț
ie de nevoile proiectului nostru !
#Adaugam fi
ș
ierele TestNG pentru a rula testele
50
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
ADD
module
-book-flight.xml
module
-book-flight.xml
ADD
module
-search.xml
module
-search.xml
ADD
module
-online-order.xml
module
-online-order.xml
ADD tests-suite.xml tests-suite.xml
#Aici descarc un script pentru a verifica dac
ă
nodurile de Selenium
Grid sunt up and running înainte ca testele sa fie pornite
RUN wget
https:
//s3.amazonaws.com/selenium-docker/healthcheck/healthcheck.sh
#Trebuiesc introduse 3 variabile dup
ă
compilare:
#
Browser
(like: chrome or firefox),
Host
(like: localhost) and
Module
(like: book-flight-
module
or search-
module
)
ENTRYPOINT sh healthcheck.sh
#Comanda pentru pornirea testelor este apelata din scriptul
"healthcheck.sh" de mai sus
#java -cp selenium-docker.jar:selenium-docker-tests.jar:libs
/*
-DBROWSER=$BROWSER -DHUB_HOST=$HUB_HOST org.testng.TestNG $MODULE
Acest fi
ș
ier ne des carca un container Docker pentru a fi folosit ca imagine de baza pentru
imaginea noastra, dupa care sunt instalate utilitarele “curl”
ș
i “jq”, după care este setat spa
ț
iul de lucru
din interiorul containerului, după care adaugam fi
ș
ierele proiectului nostru de tipul
.jar
în interiorul
containerului, după care adaugam fi
ș
ierele TestNG pentru a rula testele noastre, după care este
descarcat un script care în timpul rularii testelor se asigura ca Selenium Grid sa fie 100% func
ț
ional
înainte ca testele sa fie pornite.
Ș
i la final este setat punctul de pornire pentru containerul nostru, tot
aici este setata si comanda java pentru a construi containerul nostru.
Următorul pas este sa construim un fi
ș
ier Jenkinsfile tot în interiorul proiectului nostru si care
sa contina următorul script:
pipeline {
// Jenkins master executor trebuie sa fie setat pe "0"
agent any
stages {
stage(
'Build Jar'
) {
steps {
bat
"mvn clean package -DskipTests"
51
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
}
}
stage(
'Build Image'
) {
steps {
bat
"docker build -t=danpopa86/selenium-docker ."
}
}
stage(
'Push Image'
) {
steps {
withCredentials([usernamePassword(credentialsId:
'dockerhub2'
, passwordVariable:
'pass'
, usernameVariable:
'user'
)]) {
bat
"docker push
danpopa86/selenium-docker:latest"
}
}
}
}
}
Acest fi
ș
ier este împăr
ț
it în trei pa
ș
i:
–
primul pas numit “
Build Jar
” ne compilează proiectul ;
–
pasul doi numit “
Build Image
” ne construie
ș
te imagine Docker folosindu-se de cerin
ț
ele
specificate în fi
ș
ierul “
Dockerfile
”;
–
si pasul trei numit “
Push Image
” trimite imaginea nou creata in hub-ul docker
“
https://hub.docker.com/
”
Ulterior imaginea urcata în Hub-ul Docker o sa fie folosită în testele noastre.
5.7 Implementarea Selenium Grid
Pentru a implementa Selenium Grid în proiectul nostru folosim func
ț
iile Docker-ului si ale
Jenkins-ului. Detaliem în continuare pa
ș
ii pentru a implementa Selenium Grid:
a)
Facem un fi
ș
ier nu mit “
docker-compose.yaml
” în care adăugăm următorul script:
version:
"3"
services:
hub:
image: selenium/hub:
3.14
chrome:
52
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
image: selenium/node-chrome:
3.14
depends_on:
– hub
environment:
– HUB_HOST=hub
firefox:
image: selenium/node-firefox:
3.14
shm_size:
'1gb'
depends_on:
– hub
environment:
– HUB_HOST=hub
tests-suite:
image: danpopa86/selenium-docker
depends_on:
– chrome
– firefox
environment:
– HUB_HOST=hub
– BROWSER=firefox
– MODULE=tests-suite.xml
volumes:
–
/d/docker/jenkins/arctest/test-suite:/usr/share/proiectlicenta/test-o
utput
În care specificam ce versiuni de Selenium Grid + versiunile pentru nodurile de Chrome
ș
i Firefox să
folosească,
ș
i după care s pecifică numele imaginii noastre create precedent (în acest caz se nume
ș
te
“danpopa86/selenium-docker”), specificam ce fi
ș
ier TestNG sa fie rulat pentru teste (în acest caz este
folosit fi
ș
ierul “
test-suite. xml
”)
ș
i în plus tot aici îi trimitem
ș
i ce variabilile de environment ce o sa fie
folosite in teste.
b)
Facem un fi
ș
ier nu mit “
Jenkinsfile
” în care adăugăm următorul scrip:
pipeline{
agent any
stages{
stage(
"Start Grid"
){
steps{
53
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
bat
"docker-compose up -d hub chrome firefox"
}
}
stage(
"Run Test"
){
steps{
bat
"docker-compose up –no-color tests-suite"
}
}
}
post{
always(
"Bring everything down"
){
//archiveArtifacts
'/d/docker/jenkins/arctest/test-suite'
bat
"docker-compose down"
}
}
}
În acest fi
ș
ier sunt aplica
ț
i următorii pa
ș
i:
–
în primul pas numit “
Start Grid
” folosind comanda “
docker-compose up
-hub chrome firefox”
pornim toată infrastructura Selenium Grid;
–
în pasul doi, numit “
Run Test
” rulam comanda “
docker-compose up –no-color tests-suite
” in
care pornim imaginea docker creata anterior cu toate testele noastre;
–
în pasul trei numit “
Bring everything down
” rulam comanda “
docker-compose down
” pentru a
opri toate toate containerele Docker.
5.8 Implementarea cu GitHub pentru controlul versiunilor
În acest capitol implementam sistemul de versionare + “
WebHook-ul
” GitHub pentru a
versiona aplicatia noastra si pentru a construi automat imaginea Docker imediat ce orice commit-uri au
fost urcate în GitHub.
În acest fel a fost creat un “
Repository
” in GitHub la urmatoarea adresa:
“
https://github.com/DanValentin/ProiectLicenta
” aici a fost implementat un “
webhook
” pentru ca în
momentul cand sunt încărcate modificări ale codului automat se trimite o comanda pentru Jenkins ca
54
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
imaginea Docker sa fie actualizată pe https://hub.docker.com cu ultimele modificări:
În Jenkins proiectul trebui sa fie setat sa accepte webhook-uri:
55
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
5.9 Implementarea CI / CD
Pentru a integra complet tot proiectul folosim Jenkins ca CI/CD tool. Pentru aceasta folosim
următoarea comanda Docker pentru a crea un server Jenkins:
docker run -p
8080
:
8080
-p
50000
:
50000
-v
d:/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts
Aici serverul Jenkins asculta pe portul “
8080
”
ș
i are o mapare cu folderul “
d:/docker/jenkins
”.
În Jenkins facem un proiect nou numit “
Pipeline Project_Build_Github_WebHooks
” pentru a compila
proiectul nostru
ș
i pentru a crea imaginea Docker cu toate dependintele deja făcute, tot aici trebuie sa
setam
ș
i GitHub_webhoo k-ul setat anterior, în acest proiect trebuie sa folosim “
Repo-ul
”
“
https://github.com/DanValentin/ProiectLicenta
”:
In imaginea de mai jos este confirmarea ca imaginea noastra a fost creata si incarcata cu succes in
hub.docker.com:
56
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Acum orice modificare adusă în codul sursa este automat pornit un build in Jenkins care la randul lui
creează nouă imagine
ș
i o încarcă în
https://hub.docker.com
.
Pentru a rula testele din Jenkins a mai fost creat un “
Repository
” in GitHub
“
https://github.com/DanValentin/selenium_docker-runner
” acesta contine cele doua fisiere
“
docker-compose.yaml
si
Jenkinsfile
” create anterior care descarca imaginea noastra de pe
hub.docker.com
si porneste testele folosindu-se de fisierul Jenkinsfile. În Jenkins facem un al doilea
proiect numit “
Test_Runner
” în care este folosit “
Repo-ul
” de mai sus. În momentul cand este pornit
acest proiect din Jenkins sunt descărcate automat imaginile pentru Selenium Grid + Imaginea noastra
personalizata, este creata automat o retea interna si sunt rulate testele specificate în fi
ș
ierul
“
docker-compose.yaml
”:
57
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
După ce teste sunt finalizate în consola putem vedea logurile în felul următor:
58
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
Concluzii
:
Seleniul este un instrument puternic pentru a efectua teste func
ț
ionale
ș
i de
regresie. Pentru a ob
ț
ine cele mai multe avantaje din aceasta, ar trebui să avem o
arhitectură bună pentru framework chiar de la început. Odată ce cimenta
ț
i o funda
ț
ie
puternică, ulterior se pot dezvolta nenumărate teste.
Un framework este utilizat practic pentru a automatiza lucrările de testare. Aceste
teste includ metode de testare precum smoke testing
ș
i/sau regresie
ș
i altele. Testarea se
poate face pe aplica
ț
ii web, aplica
ț
ii mobile
ș
i chiar pe desktop.
Pentru nivelul următor, folosind Selenium Framework, putem sa ne indreptam
atentia catre
Testarea de Securitate a Aplica
ț
iilor Web folosind Selenium,
dar acest
subiect o să-l dezvolt în lucrarea de dizerta
ț
ie.
Bibliografie
:
1 – https://ro.wikipedia.org/wiki/Testare_software
2 – https://www.techopedia.com/definition/24864/software-bug-
3 – https://ro.wikipedia.org/wiki/Testare_software
4 – https://www.softwaretestingmaterial.com/sdlc-vs-stlc/
5 – https://www.softwaretestingmaterial.com/sdlc-vs-stlc/
6 – https://www.atlassian.com/agile/scrum/sprints
7 – https://www.stateofagile.com/#ufh-c-473508-state-of-agile-report
8 – Acronim pentru Business Analyst (Analist de Afaceri) shorturl.at/ajuG8
9 – https://en.wikipedia.org/wiki/Behavior-driven_development
10 – https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven_development
11 – https://en.wikipedia.org/wiki/Scrum_(software_development)
12 – User Story https://en.wikipedia.org/wiki/User_story
13 – https://en.wikipedia.org/wiki/Scrum_(software_development)
14 – Product Owner https://www.scaledagileframework.com/product-owner/
15 – https://www.atlassian.com/agile/kanban/boards
59
Îmbunătă
ț
irea Procesului de Testare folosind Tehnologiile Agile Popa Dan-Valentin
16 – https://www.atlassian.com/agile/kanban
17 – Testare unitara shorturl.at/bgxIR | https://en.wikipedia.org/wiki/Unit_testing
18 – Proprietari de Afacere (Business Owner) shorturl.at/jrDJ5
19 – Utilizatori Comerciali(Business Users) shorturl.at/ackmt
20 – Manager de Proiect (Project Manager ) shorturl.at/fBI23
21 – Three Amigos https://www.agilealliance.org/glossary/three-amigos/
22 – https://en.wikipedia.org/wiki/Cucumber_(software)
23 – https://cucumber.io/docs/gherkin/
24 – https://www.guru99.com/exploratory-testing.html
25 – https://en.wikipedia.org/wiki/Mind_map
26 – https://en.wikipedia.org/wiki/Session-based_testing
27 – https://en.wikipedia.org/wiki/Continuous_integration
28 – https://www.scaledagileframework.com/
29 – https://dzone.com/articles/what-is-scaled-agile-framework-9-principles
30 – https://www.scaledagileframework.com/safe-lean-agile-principles/
31 – https://en.wikipedia.org/wiki/Work_in_process
32 – https://www.scaledagileframework.com/program-increment/
33 – https://www.scaledagileframework.com/lean-agile-mindset/
34 – https://ppt-online.org/106164
35 – https://www.scaledagileframework.com/agile-release-train/
36 – https://en.wikipedia.org/wiki/Acceptance_testing
37 – https://www.scaledagileframework.com/innovation-and-planning-iteration/
38 – https://www.scaledagileframework.com/
39 – https://www.leadingagile.com/2017/02/definition-of-done/
40 – shorturl.at/CGSX3
41 – https://www.scaledagileframework.com/agile-testing/
42 – https://www.atlassian.com/agile/scrum/scrum-of-scrums
43 – https://devqa.io/agile/continuous-testing-agile
44 – https://www.infosys.com/insights/ai-automation/quality-assurance.html
60
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: irea Procesului de Testare folosind Tehnologiile Agile COORDONATOR ȘTIINȚIFIC: ABSOLVENT: Conf. Univ. Dr. Viorel Ionescu Popa Dan-Valentin SESIUNEA… [611968] (ID: 611968)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.