Curs 3 16.11.

2022

Testare static/dinamica

STLC – software testing life cycle

Level soft testing

Testarea se face pe 2 directii – pe orizontala - STLC

-pe vertical – in functie de anumite niveluri

STLC – mai multe faze:

Prima faza:

-requirement analysis. Este faza in care se analizeaza cerintele clientului, se strang sub forma de
documentatie, si se evalueaza testarea ca si process. Avem documente precum RTM ( Requirements
Traceability Matrix) si entry criteria document.

RTM – e ca un table in care vom lua fiecare feature pe care clientul doreste sa fie in aplicatia lui si se
pune in forma de table. Sa acopere anumite scenario de testare. Felul in care putem efectua testarea.

Entry criteria document – se evalueaza ce anume avem de testat.

A doua faza:

**-test planning and control. In aceasta faza se evalueaza cum va fi efectuata testarea si de ce resurse
dispunem. In cadrul acestei faze se poate face high level testing si test plan.

High level testing – reprez tipul de testare care se refera la ceva general. Datele testarii sunt generale si
applicate pt mai multe situatii.

Low level testing – date f specifice, doar pt anumite cazuri.

Ex.:

INSERT ALFABETIC CARACTER IN THE USER FIELD – high level test.

INSERT NUMELE LUI … IN THE USER FIELD – low level test.

Un document in care e prezentata strategia de testare – ce teste folosim, ce categorii, ce pass

percentage etc. Se dezvolta strategia de testare.
A 3-a faza: (???)

**-Test analysis – In aceasta faza se evalueaza cum va fi efectuata testarea si de ce resurse dispunem.
Ce riscuri si ce resurse avem pt testare.

A patra faza:

-test case creation (test case development) – Este faza in care se creaza test caseurile/test scripts.

Test case = un document care evalueaza o singura particularitate a unui system software.

Test caseurile se fac pe baza scenariilor de testare.

Un scenario de testare reprezinta o idee a unui flow (process) din cadrul unui feature. O idee pe care
vreau sa o testez dintr-un feature. (o data sa incarc un video, o data incarc nush ce).

Test script = un test case neinregistrat in test plan. De el ne putem folosi in crearea sau executia altor test
caseuri.

Relatia intre test case si test scenarios este complementara (nu exista una fara cealalta).

Cand avem un feature de testat – cream scenariile de testare. Preluam particularitatile din cadrul
featurului respective si ne tragem niste idei – ce anume vrem sa testam la feature respective (pe baza
scenariilor de testare, sau pe intuitia noastra). Pe baza scenarilor, noi vom crea test caseurile (documente
care certifica ce testam la feature respective – dovada a ce am testat. Se creaza pe baza scenariilor pe
care le identificam.). ?????

Test script – la fel ca un test script, dar nu va fi inregistrat nicaieri (in test plan). E un document care iti
arata pas cu pas cum sa faci o anumita actiune intr-o aplicatie. Ex. Vreau sa testez functionalitatea de pe
Story (FB). Voi avea test caseul mare in care uploadez o poza, dar ma folosesc de un test script pe
partea de login ca sa-l folosesc pt test case. ?????

Test case – ca un tutorial. Test script – ??? cum fac -> Login in to FB app, dar nu explic cum ma loghez.

Test case – nu explic mai multe procese, ci doar unul singur. Pt procesele pe care nu le pot explica – ma
folosesc de test scripturi.

Ex. Sa uploadez o poza pe FB, treb sa fiu intai logat, apoi uploadez.

Nu mai faci test scriptul inca o data, ca l-ai (mai) facut o data inainte. ???

Faza 5:

-test environment setup – faza in care se pregateste environmentul (mediu) de testare (unde testam?)
si/sau datele de testare.

FB – sa incarc fisier audio, video si o poza – treb sa pregatesc cele 3 fisiere pe telefon ca sa le pot
uploada. Pregatirea datelor de testare.
Faza 6:

-test case execution – reprezinta executia test caseurilor create.

Am creat test caseurile, ne am pregatit environmentul, acum executam test caseurile.

Faza 7:

-testing closuring activities – etapa in care se realizeaza documentatia pt release. Documentatia e

realizata de catre manageri si este validate de catre toata lumea (mai putin clientul).

Elemente prioritare in cadrul documentatiei de release sunt urmatoarele:

-release notes – note despre ce s-a implimentat nou in releaseul respective (pt end user, sip t
stakeholder). O sa apara notitele cu ce s-a adus nou in aplicatie (in releaseul respective). Facut de BA
sau testeri.

-evalueting of exit criteria

-number of tickets resolved

-number of bugs or defects opened

-number of bugs/defects fixed

-date of the release

-reprezentatives for each role – semneaza cineva de la testare, dezvoltare, management, toata lumea

-testing pass percentage (%)

Level soft testing – nivelurile testarii – 4 niveluri

1. Unit testing / Module testing / Component testing

2. Integration testing
3. System testing (*system integration testing)
4. Acceptance testing

Unit testing – primul nivel al testarii. Implica testarea la nivel de unitate sau de modul. Acest tip de testare
este efectuata strict de catre dezvoltator. Implica activitati cum ar fi unit testing, si debugging.

Codul se ia sub forma de module (unitati micute), linii de cod samd. Fiecare unitate de cod va fi testate de
dezvoltator dup ace e scrisa. Se face unit testing in care se verifica daca codul respective e complied cu
sistemul si se face si debugging sa se vada daca e correct codul sau e efficient.

Integration testing – al 2 lea nivel. Reprezinta tipul de testare care se face intre module (modulele/unitatile
vor fi testate intre ele).

Avem tehnici de testare cum ar fi: top down, bottom up, big bang approach (sandwich approach).
Pt a efectua aceste tehnici, avem nevoie sa cream anumite mock upuri (machete) care se numesc
Drivers sau Stubs-uri (implica white box testing – deci o sa l faca QA de automation).

Sistem testing – reprez testarea sistemului ca un intreg. Al 3 lea nivel al testarii. (toate modulele vor fi
testate impreuna). Pt anumite cazuri particulare in care o aplicatie este integrate cu o alta aplicatie, putem
avea system integration testing (QA automation + QA manual).

Acceptance testing – ultimul nivel al testarii. Se desprind 2 activitati: prima – alpha testing (OAT), si a 2-a
– beta testing (UAT).

OAT – operational acceptance testing.

UAT – User acceptance testing.

Alpha testing – tipul de testare care se realizeaza in locatia echipei de dezvoltare. Se face atat testare
automata cat si manuala. Este implicate echipa de dezvoltare si managementul. Nu este deschisa
publicului larg.

Beta testing – tip de testare pe care il face end userul. Este deschisa publicului larg (sau unui public). Se
realizeaza in locatia end userului. Acesta raporteaza defectele intalnite prin intermediul unui feedback sau
customer support.

Se aduna toata echipa de dezv impreuna cu Busines Managementul. Se testeaza produsul. Dup ace am
testat produsul si e apt pt release, se da in productie pt o anumita categorie de clienti. Acestia vor
interactiona cu aplicatia si vor raporta anumite nereguli/buguri/pb ori prin intermed unui feedback (buton
sau printr un system automat), sau vor suna la customer support – nu pot sa ma loghez, sa resetez
parola etc.

Customer support va trimite pb mai departe la department de dezvoltare, se face ticket de care se ocupa
echipa de dezvoltare, se face code fixed si se rezolva problema.

Singura particularitate – creatorii de jocuri. Se bazeaza f mult pe testarea beta. Doar anumiti client
testeaza (influenceri, gameri profesionisti etc).

Ex.:

Un nou feature la FB – dai release doar in US – in Arizona sau Texax. 1,2,3 zile primesti feedback de la
acesti client, si apoi vezi daca le dai si mai departe altora.

App de traffic aerian – se raporteaza daca sunt pb. Apasa buton de feedback.
Exemplu

Scenarii de testare – Cum putem testa functionalitatea asta? Buton de login

User name – parte de input – Ce imi accepta?

Password – parte de input

Validare – buton login

Din perspectiva input

User name – caractere special – diacritice, litere specific altor alfabete (chineza ?), caractere numerice,
semne de punctuatie, litere mici, litere mari, cifre, caractere alfabetice, - alphabetic, numeric, character
special

Password – repetam scenariile

Din perspectiva validare

Nu testam crearea unui cont, ci logarea unui cont

Testam o adresa de mail din baza de date cu o parola corecta – care corespunde adresei respective de
email

O adresa de email din BD – cu o parola incorecta

O adresa de email din BD cu o parola din BD care nu coresp contului respective

Invalidez partea de adresa de email:

Adresa de email care nu e efectiv o adresa de email (caractere de email)

Incerc sa stric formatul adresei de email (@extensie.domeniu) – iau din BD o adresa de yahoo, gmail,
Hotmail

Pun o adresa de email fara extensie, alta fara domeniu – dar sa corespunda cu ceva din BD, impreuna cu
parola aferenta contului, si o sa incerc sa ma loghez

Pt nr de telefon – tre sa testez un nr de telefon care tine de contul meu, un nr de telefon invalid (nu exista
in BD), ma leg de regiune (un nr de tel din regiunea respective – Ro), apoi pun nr de telefon de Spania
(dare u sunt de Ro), stric regiunea in care eu sunt (iau nr de telefon romanesc da ii pun prefix de US).

Nu testam ceva ce nu cunoastem. Treb intai sa cunoastem f bn featereul, ca sa poti sa-l testezi. Testarea
tre sa fie lipsita de ambiguitate.

Partea de script – fac un test script despre cum ma loghez in aplicatie. Testez o functionalitate care are
legatura cu login-ul.
Calluri de API

BD request – sub 3 %, mai mult pe automation, sau penetration testing

Tema: Continuam ex nostrum pt alta aplicatie

In lb engleza

Scenarii de testare pt playerul de youtube de pe web

Termen limita: vinery, ora 12:00

Liber de pe 20 dec – (avem curs pe 20 dec). Ultima zi de curs din an. Ne revedem pe 9 ian.

Ultima sesiune – 28 nov

Ne revedem pe 6 dec

Liber 30 nov – 6 dec

Jira si Testlink

Cursul se termina pe 6 feb, publicarea rezultatelor pe 15 feb, pe 16 feb inchidem proiectul – ramane 1 zi
consilierea – imposibil

Ultima zi efectiva de curs 27 ian

Luni 30 ianuarie – primim cerintele, cele 10 subiecte

Pana pe 6 februarie – ultima zi sa trimitem cerintele

Rezolvare, publicare, contestatii, rezultat final

Coaching 15-16 feb