24.11.

2022

Structure based testing (white box testing)

Este tipul de testare in care testerul are nevoie sa cunoasca structura interna a codului.

Pe baza codului aplicatiei, se va face test coverage.

White box testing se poate face atat pe front end (tooluri: AccelQ si Katalon Studio), cat sip e backend
(selenium, eclipse, visual studio).

Cel mai utilizat tool pt white box testing este Selenium.

Selenium utilizeaza o gama larga de limbaje de programare, iar majoritatea toolurilor de pe piata au la
baza Selenium.

Tehnici de testare white box (testare automata): 2 pt backend – Statement testing si Branch testing.

Pt Frontend – Web UI testing si Mobile UI testing.

Experience based testing

-Este tipul de testare care se face pe o aplicatie avand ca resurse strict experienta testerului cu aplicatia
respective sau aplicatii similare.

-Asadar, Exp. Based testing va fi efectuat de catre testeri cu experienta (senioritate).

-Exp. Based testing se realizeaza fara practice conventionale de testare. (scenarii, test case-uri,
strategie).

Avem 3 tipuri de exp. Based testing:

-1. Exploratory testing

Testerul isi aloca 1-2 ore inainte de a se face release in production si dupa implementarea
featurerilor (functionalitatilor) in care va explora aplicatia ghidat de experienta sa cu scopul de a descoperi
buguri.

Explicatie: Se face de un tester cu exp. Dup ace se implementeaza fiecare feature, dup ace sunt
interpretate prin intermediul testcaseurilor, inainte de release, vom face o verificare in aplicatia la nivel
general, cu intentia de a descoperi buguri in aplicatie (in mod random, exploratoriu). In aloc 1-2 ore sa
caut buguri, scenario imposibile, corner case, integrarile functionalitatilor intre ele, sau integrari cu alte
aplicatii. Fara vreo tehnica conventionala, ma voi juca cu aplicatia, sa aflu buguri. Dupa se poate da la
release.

Nu e mandatory, e optional, dar e indicat, asigura calitatea releaseului.

-2. Error guessing

Tehnica in care testerul, pe baza experientei sale cu aplicatia respective, va ghici ce zona a
aplicatiei ar putea fi corupta si va cauta buguri in acea zona.

Error guessing se poate face atat inaintea releaseului in production, dar si dupa.
 Explicatie: Nu voi mai testa toata aplicatia, ci o anumita zona care stiu ca e problematica. Voi
incerca sa ghicesc unde anume sunt pb. Am mai interactionat cu o anumita eroare din aplicatie, stiu ca
acolo sunt pb, voi testa doar acolo (tintit). Se poate face inainte de release, sau dupa release.

-3. Ad-hoc testing

Este tipul de testare care se face in alpha-testing.

Testerul va intenta o sedinta in care vor fi invitati si alti testeri, acestia testand o anumita
functionalitate in mod exploratoriu, iar bugurile gasite vor fi raportate intr-un document.

Aceasta sedinta nu ar treb sa dureze mai mult de 1 h.

Explicatie: o sedinta (ca un fel de brain-storming) daca o functionalitate e f complexa. Daca am anumite
frici, temeri ca ar putea sa fie buguri acolo. Nu stapanesc bn aplicatia, am nevoie si de consultanta altor
testeri. Se face dupa ce am testat eu functionalitatea respective. Vor veni testerii care vor. Timp de 1 h va
testa functionalitatea respective, fiecare cu metodele lui. Testerul va treb sa le explice celorlalti despre ce
e vb (scurta introducere 15 min). Cand cineva gaseste un bug, va raporta intr-un document
word/excel/whatever. Dupa 1 h, testerul va investiga bugurile respective.

*!@ RC – release candidate (o versiune a aplicatiei stabile) *!@

*!@ Mediu de testare *!@

*!@ Crowd testing *!@

Manintanance testing

Regresion testing !!!!!!!!!!!!!!!!!!!!!!

-Este tipul de testare care se face pt a verifica daca noua functionalitate adusa sistemului va impacta
negative anumite zone din aplicatie.

Ideal este ca regression testing sa fie automatizat.

In urma unui release, cele mai importante test caseuri vor fi puse intr un repository urmand ca sa fie
reexecutate la fiecare deploy in production.

Explicatie: avem un release. Cele mai importante test caseuri din releaseul respective (cele mai cruciale)
vor fi copiate intr un repository separate (de regression). Ideea ca aceste teste sa fie executate la fiecare
release in parte, inainte sa se faca deploy in production. De asta se doreste ca aceste teste sa fie
automatizate, sa nu le facem de fiecare data. Ele sunt scrise de manual tester, dar ar treb sa fie
automatizate de catre un tester de automation.
Regresion testing: eu sunt clientul, vreau ca o echipa de dezvoltare sa-mi construiasca un scaun, 4
picioare, din piele, stabil, ergonomic etc. Dar la urmatorul release vreau sa adaug niste roti pt fiecare
picior al scaunului. Automat voi modifica functionalitatea de baza a scaunului. Cand fac testarea pt
scaunul respective cu roti, voi testa cele mai importante functionalitati – voi reexecuta primele test
caseuri pt a vedea ca noua modificare nu mi va impacta negative sistemul.

Cand aduc ceva nou in app mea, voi vrea sa reverific functionalitatea deja pusa acolo, ca sa verific ca
noua functionalitatea adusa sistemului nu impacteaza negative sistemul. Ca o reverificare, dar doar
atunci cand s a adus ceva nou in system.

Retesting

-Reprezinta reexecutarea efectiva a unui flow (process) sau reexecutarea pasilor de reproducere a unui
bug. (o reverificare)

Explicatie: am descoperit un bug, vrem sa vedem daca se reproduce din nou bugul respective. O sa
reexecut din nou pasii de reproducere a acelui bug, o sa fac retesting – o sa reproduc din nou acel bug.

Ex. Ai un bug care din 10 cazuri, se reproduce de 2 ori. Voi retesta bugul respective pana cand il gasesc o
data.

Am un bug care se reproduce in production, dar nu in mediul de testare. O sa fac un retesting in

production, dar si in mediul de testare. O sa reverific inca o data bugul.

Sanity check

-e tipul de testare care se face in production dupa un release pt a verifica ca noile implementari
functioneaza in mod corespunzator.

Explicatie: voi face acest tip de testare dup ace am adus noile implementari. Vreau sa verific ca noile
implementari functioneaza la fel in production, la fel ca in mediul de testare. O sa verific doar noile
functionalitati.

End-to-end flow (E2E flow)

-reprezinta un process complex din cadrul aplicatiei care va fi testat cap coada.

Ex. Am o aplicatie care face survey (?!?). E2e flow – ma loghez, fac un anumit tip de survai, un utilizator
sa raspunda la survaiul respectiv.
Ex. Sa luam partea de postare pe fb. Vrem sa facem e2e flow pt posting. Ma loghez in aplicatie, voi avea
un fisier video si un fisier poza, o voi posta in cadrul aplicatiei, iar un alt prieten va treb sa comenteze, sa
reactioneze, sa acceseze poza respective.

Toata partea de postare, cu tot cu interactiunea unui alt user – e2e flow.

Ex. Pt booking – pt a rezerva o locuinta. Ma loghez in app, selectez orasul, perioada, cate pers, efectuez
searchul, selectez cazarea, efectuez plata, confirm cazarea. Asta e un e2e flow.

O app pe care o pot testa de la cap la coada, si are un curs logic.

Smoke testing

-este tipul de testare care se face pt a verifica minimul minimul functional al unei aplicatii.

Ex. Daca testez un fier de calcat, doar il pun in prize sa vad ca nu bubuie, ca nu scoate fum.

Daca testez o anumita aplicatie, ii dau drumul (pornesc serverele) sa vad ca nu crapa la prima accesare
sau la login.

De regula, smoke testing e automatizat.

Test case

Def.

Un test case este un document care evalueaza o singura particularitate a unui system software.

Ce elemente ar treb sa continuta un test-case:

-1. Un ID – care treb sa fie traceable (identificat usor, urmarit) si unic (nu 2 test caseuri cu acelasi ID)

-2. Summary – reprezinta o scurta descriere vis-à-vis de ce vom verifica in test-caseul respective.

(e ca un titlu pt test case)

-3. Description – reprezinta o descriere mai ampla (fata de summary) in care, la fel, va fi detaliat ce
particularitate vom testa.

-4. Priority – poate sa fie de la P 0 (cea mai mare prioritate) pana la P 3.

P 0 – critical

P 1 – high

P 2 – medium

P 3 – low
-4. Test environment – reprezinta environmentul de testare. Ex daca suntem testeri la fb si o sa testam
in production, environmentul va fi www.facebook.com – unde o sa testez test caseul respective.

-5. Created by – cine a creat test caseul.

-6. Assignee – adica cine il va executa

-7. Pre-conditions * - sunt niste setari de care am eu nevoie sa pot executa test caseuri. Ex. Daca fac test
case de login, ca sa fac setari am nevoie de un user ca sa ma pot loga in aplicatie. Le pun in pre-
conditions ca sa se poata loga pe un anumit cont.

Atat pasii, cat si preconditions, sau postconditions, treb sa fie numerotati. (1,2,3,4, etc)

-8. Post-conditions – f rar folosite, de asta nu e mandatory sa le punem intr-un test case. Ele au rolul
unei note de subsol. Ex. Poti sa stabilesti o anumita regula in cadrul executarii test caseului.

-9. Status – statusul general al test caseului. Poate fi: passed, failed, blocked, N/A*

-10. Test steps – pasii efectiv ai test caseului.

-11. Test data – reprezinta de ce date am nevoie ca sa pot executa pasul respective.

Ex. Voi avea test data pt fiecare pas in parte. 5 pasi – 5 test data.

Cu toate astea, test data nu poate fi aplicabil pt fiecare pas. Explicatie. Ex. Scenario de login – vrem sa ne
logam pe fb. Test case – pas 1 – select the user name field

Pas 2 – insert username in precondition and insert it into the username field

In the password field, insert the password mention in preconditions.

Pas 3 – press the login buton. Nu am ce test data sa pun, pt ca treb sa apas un buton de login. Asadar
vom lasa gol.

-12. Expected results – reprezinta la c ear trebui sa ma astept in urma executarii fiecarui pas in parte.

Explicatie: vom avea cate un expected results pt fiecare pas in parte. 5 pasi – 5 expect result.

Pas 1 – insert username field

Pas 2 – insert the password – the password is …

Pas 3 - - user is login …

-13. Status – diferit de cel general. Asta e statusul pt fiecare pas in parte. Poate fi la fel passed, failed,
blocked, n/a*

Ex. Test case - Ganditi va ca create un tutorial pt bunicuta de la tara. Pas 1 – fa aia, pas 2 – fa ailalta, etc.
Tooluri pt test case – jira, pe o foaie de hartie, in word, excel, test link, etc. Cel mai folosit e test rail.

La curs: noi o sa folosit test link.

Cum ar treb sa fie scris un test case?

Un test case bine facut ar treb sa aiba urmatoarele attribute:

-in primul rand, sa fie unic (nu 2 test caseuri care testeaza aceeasi chestier)

-sa fie clar

-concis

-usor de inteles

-organizat

-sa acopere in intregime scopul lui

-obiectiv

-total lipsit de ambiguitate

-timpul verbelor treb sa fie la present (fara cuvinte should, will, if)

-exprimarea treb sa fie imperativa (ca si cum ati da niste porunci)

Un test case binefacut ar treb sa fie atat de simplu astfel incat si daca am lua pe cineva de pe strada care
nu are cunostinte tehnice vizavi de aplicatie, sa poata sa inteleaga sis a execute test caseul.

Ca sic and ai explica de la distanta unei pers mai in varsta ce are de facut pe un calc. Pas cu pas, cat mai
clar, cat mai concis. Ca si cand i am explica bunicutei cum sa scrie un mail, unde sa duca mouseul, ce sa
scrie, unde sa scrie etc.

Ex. Impreuna un test case

Un test case pt loginul de fb – fara functionalitatea de nr de telefon

ID FB-01
Summary [Facebook] Facebook login
Description Verify that a registered user can login successfully into his FB account
Priority P 0 - critical
Test www.facebook.com
environment
Created by Paul Rotariu
Assignee Stingaci Nicolae
Pre-conditions 1. User registered: user1@gmail.com / parola12345
 Status
Test steps Test data Expected results Status
1. In the user1@gmail.com Data is accepted
username field successfully
insert the
username
mentioned in
pre-condition 1
2. In the parola12345 Data is accepted
password field successfully
insert the
password
mentionez in
pre-condition 1
3. Press the login User is successfully
button logged in into his
account

Account homepage is
displayed

Tema pt acasa:

-de testat functionalitatea reginei pe table de sah. Efectuat test scenario + test cases

-ca referinta de aplicatie, va puteti folosi de chess.com

-intrat in tabul de analysis

De testat functionalitatea Reginei pe tabla de sah

De efectuat Test Scenario + TC
Ca referinta de aplicatie, va puteti folosi de Chess.com

https://www.chess.com/analysis

-care e rolul reginei pe table de sah, cum merge, cum captureaza, nr maxim de regine pe table de sah

Pe baza functinalitatii ei – ne facem scenario, test caseuri

Tehnica de use test case scenario + test cases

Positive, negative testing, flowuri normale

Vom testa in detaliu fiecare funtionalitate a reginei – aveti grija la exhausting testing, dar in acelasi timp
sa si acoperim functionalitatea

Tips and tricks – recomand sa ne pozitionam regina in mijlocul tablei – pe pozitia d5 (randurile si col sunt
numerotate)

De acolo – in fct de ce scenario va ganditi, incercati sa va faceti test caseurile.

Ex. Sa spunem ca vrem sa testam mersul reginei (cum merge regina pe table de sah)

Table de sah e goala – regina e pe casuta d5

Move the queen from … position to … position

Test case pt movementul reginei

Negative testing – sa verif ca regina nu poate sari peste piesele ei

In precondition – o pun in mijloc, o inconjor de piesele ei, o pun sa sara peste piesele ei – nu o sa poata

Pt cei care nu stim sah – citim functionalitatea reginei

Ce scenario am putea testa daca ar fi app noastra

Si facem test caseuri pt functionalitati

La munca – de fiecare data, la fiecare item noi, va treb sa ne documentam. O sa implementam fix un
scenario de la munca.

Tips & Trics

D5
Manintanance testing

Test case