Introducere in IT

Idei elementare
1. Eroarea este un defect la nivelul codului programatorului.
2. Documentul care adevereste testerului ca aplicatia create indeplineste criteriile de calitate este
cel cu specificatiile functionale si non-functionale.
3. Bug sau defect reprezinta o greseala, eroare sau problema care face software-ul sa se comporte
intr-un mod diferit decat cel intentionat.
4. Eroarea care este trimisa de un server atunci cand un link nu este functional, se numeste
EROAREA 404.
5. FAILURE inseamna Inabilitatea sistemului sau a unei componente sa produca rezultatul correct.
6. Specificatiile ambigue afectează calitatea unui produs informatic.
7. Criteriul de start în asigurarea calității unei aplicații este : Correctness: Aplicatia este in
accord cu specificatiile clientului.
8. Planificarea este prima fază în care testerii ar trebui să fie implicaţi.
9. Testerul poate alerta colegii cu privire la potentialele pericole ascunse in documentul cu
specificatii inainte ca orice linie de cod sa fie scrisa de catre acestia.

Cum functioneaza un website?

1. Unui produs informatic I se mai spune si Aplicatie
2. Un browser ne ajuta sa vizualizam paginile web ale website-urilor.
3. Un website este o colectie de pagini web.
4. Ce face un Server şi ce face un Client?
R: Clientul face cereri Serverului.
5. Un REQUEST este Un mesaj care contine o cerere de pagina web
6. Un RESPONSE este Un raspuns trimis de un server cu privire la cererea de pagina
web facuta.
7. Download-ul inseamna pachete cu informatii care au fost trimise de server ca urmare
a unei cereri facute de client.
8. Upload -ul este Un request trimis de client unui server
9. Credentialele sunt informatii trimise unui server si verificate daca corespun cu cele
din baza de date.
10. O pagina web este compusa din butoane.
11. In spatele unui text se gasesc link-uri.
12. Functionalitatea este un modul care contine mai multe caracteristici prin intermediul
carora userul poate interactiona cu aplicatia si obtine rezultatele de care are nevoie.
 Nivele de testare

Primul nivel de testare se numeste UNIT TESTING, este facut de catre programator,
acesta izoleaza o componenta de restul componentelor pentru a observa daca
functioneaza.
Exemplu: Atunci când un programator scrie un test care verifică funcționalitatea
modulului de logare al unei aplicatii

Al doilea nivel este INTEGRATION TESTING : evaluarea diferitelor componente

pentru a se observa daca functioneaza impreuna. ( elimina defectele care pot aparea
din cauza aceasta)
Exemplu: Verificam cum functioneaza pagina de log in cu pagina “ Contul meu”

Al treilea nivel este SYSTEM TESTING: Toate componentele se testeaza ca un intreg

pentru a observa daca aplicatia functioneaza dupa cerintele functionale specificate.
Exemplu: Se verifică dacă un cumpărător poate parcurge un întreg flow de
cumpărături.

Ultimul nivel este ACCEPTANCE TESTING: se evalueaza daca sistemul indeplineste

cerintele clientului si daca este pregatit de lansare. ( se verifica toate test case-urile).
Exemplu: Atunci când verific dacă aspectul website -ului corespunde cu cerinţele
clientului

TIPURI DE TESTARE

Testarea STATICA(Testare de verificare. ) este tipul de testare in care codul nu este

executat, se verifica codul sau documentul cu specificificatii si pune comentarii de
revizuire. Testare de verificare.
Se poate face pe documente de lucru:
- Specificatiile cerintelor
- Documente de proiectare
- Codul sursa
- Panuri de testare
- Scripturi de testare
- Continutul paginii web
 Revizuirea tehnica: echipa examineaza spec tehnice si verifica daca este potrivita
pentru proiect. Doc tehnice: strategia de testare, planul de testare si documentele
cu specificatiile,
Walkthrough- autorul explica documentul echipei sale de lucru.
Inspectia – intalnire formala condusa de un operator instruit, idenficarea
defectelor.
Revizuirea statica a codului – codul sursa este analizat systematic fara a il
executa, se verifica sintaxa codului.

Testarea dinamica(testare de validare) executa codul si valideaza rezultatul

obtinut cu cel asteptat.

Testarea functionala valideaza faptul ca fiecare functionalitate se comporta in

modul specificat in documentatie.
Ex: Site ecomm cu plati online, tranzactii cu card sau cec, validam ca se pot
efectua.

TEstarea non functionala verifica cat de bine se comporta aplicatia cand se

executa anumite actiuni ,
ex: cat de bine se comporta aplicatia la un anumit nr de actiune concurente.
Ex: 100 tranzactii pe secunda , tranzactia 5 secunde maxim.

Testari functionala:
-pozitiva si negative
- End to end
- Linkurilor
- Formularelor
- Smoke
- Sanity
- De tip regression

Testare non functionala:

- De compatibilitate
- Designului
- De performanta

Testarea pozitiva - testarea care foloseste doar date de intrare valide. Ex: text
box: doar cu cifre, introducem doar cifre
Testarea negative – cum se comporta aplicatia in cazul introducerii datelor
invalide. Ex: text box doar cu cifre, introducem litere
 In ambele tipuri de testare se pot folosi tehnicile de testare: Boundary Value
Analysis si Equivalence Partitioning.

Testarea end to end se realizeaza de la inceput pana la sfarsit a unei aplicatii:

Cum comunica aplicatia cu hardware, cu baza de date, cu alte aplicatii.
Daca oricare esueaza, se afla in pericol intreg sistemul.
Consta in 3 parti:
1. Indentificarea functionalitatilor oferite utilizatorilor:
- Lista cu functionalitati
- Lista cu date de intrare , actiuni si date de iesire
- Legaturile dintre functionalitati
-
2. Identificarea conditiilor pentru fiecare functionalitate:
- Indentificarea setului de conditii per functionalitate.
-
3. Crearea scenariilor de test pentru fiecare functionalitate
- Crearea de scenarii de test per funnctionalitate identificata

Testarea continutului: testarea care valideaza continutul unui website: usor de

inteles, transmite correct ceea ce se doreste. (non functionala).

Testarea linkurilor: urmareste ca toate linkurile sa functioneze corespunzator.

4 tipuri de linkuri:
- Link-uri externe: redirectionaza catre un site nou
- Link-uri interne: redirectioneaza catre alta pagina al aceluiasi site
- Link-uri ancora: redirectioneaza catre aceeasi pagina, acelasi site
- Link-uri email: posibilitatea de a trimite email catre tinta

Testarea formularelor: verificarea formularelor din pagina web: campuri text,

butoane radio, check box, liste, butoane submit sau reset.

Testarea utilizabilitatii se concentreaza pe usurinta cu care utilizatorul final va

putea folosi aplicatia.
Eficacitatea: usurinta navigarii, rapiditatea navigarii, coerenta stilului, frumusetea
estetica, usurinta invatarii, adecvat utilizatorilor finali, usurinta cautarii in site.
Acuratetea : actualitatea continutului, verificarea linkurilor stricate, verificarea
linkurilor moarte
Utilitatea: meniu inteligibil, iconite intuitive, utilitatea meniului HELP

Faze: planificarea(stabilirea obiectivelor), recrutare(identificarea resurselor),

testarea efectiva, analiza a datelor, raportare.
Testarea de tip Ad-hoc are scop de gasirea de defecte prin verificare aleatorie.

Testarea exploratory (descoperire, investigare, invatare) idei de testare, directii

de testare, documentare, gasire erori, retestare – atunci cand documentatia nu
este disponibila.

Testarea designului – daca designul este conform documentatiei, - testare web

responsive ( sa vedem daca se afiseaza correct pe mai multe dispositive si
platforme) se pot folosi emulatoare(simulator de dispozitiv)

Testarea de compatibilitate verifica daca aplicatia este capabila sa ruleze pe

diferite browsere, configuratii hardware, sisteme de operare, medii de retea,
dispositive mobile.
Testarea de accesibilitate: aplicatia testata este utilizabila de catre persoanele cu
diverse probleme. Ex: speech recognition software converteste cuvintele rostite in
text iar screen reader software citeste textul de pe monitor.

TEstare de performanta este procesul prin care se determina performanta unui

produs: aflam care sunt limitele produsului.

Testarea Smoke se efectueaza dupa lansarea unei noi versiuni a aplicatiei,

verifica daca dup ace aplicatia a fost updatata, a ramas stabila.
Ex: ecomm: user se logheaza, cauta produs, verifica cosul, plateste produsul, log
out.
Testarea sanity se efectueaza dupa crearea unei noi functionalitati a
produsului, se verifica daca noua functie se comporta in mod specific asa cum se
doreste.

Testare de tip regression confirma ca o modificiare a codului nu a

afectat caracteristicile existente.
Cazuri de testare: defecte frecvent gasite, valideaza functionalitatile folosite
frecvent, valideaza functionalitati de baza, valideaza functionalitati schimbate
recent, teste de integrare, teste complexe, boundary value analisys, valideaza
flowurile negative si cele positive.

Retestare vs regression
Retestare = retestarea unui bug pentru a vedea daca s-a rezolvat.
Regression= retestarea functionalitatilor pentru a observa daca
functioneaza correct dupa modificarile aduse.
 Raportarea unui bug

Inaintea scrierii unui bug: verifica ultima versiune, reprodu actiunile, verifica sa nu
fie duplicat, verifica radacina bug-ului, fa raportari separate

Pasii raportarii unui bug:

1. Titlul sau sumar
2. Descrierea bug-ului
3. Pasii reproducerii bug-ului
4. Rezultate asteptate
5. Rezultate actuale
6. Detalii legate de mediul testarii
7. Severitatea bug-ului
8. Prioritatea bug-ului
9. Capturarea ecranului

Un sumar bun = indentificare rapida, identificare unica, eplixca problema, nu

sugereaza soultii, nu ofera detalii in plus.

Locul din aplicatie, denumirea uzuala a problemei

Ex: Textul depaseste chenarul care trebuia sa il contina.

Text on homepage overlaps the margins of the field.

Descrierea unui bug!

Specific, descrie la obiect, foloseste un numar minim de cuvinte, foloseste

efficient cuvinte, scrie cate un bug intr-un raport, foloseste keywords.

Scrierea pasilor de reproducere a uni bug. !!!!

EX: 1. Deschide intr-un tab nou pagina de logare a site-ului

2. selecteaza campul email si introdu adresa de email

3. selecteaza campul password si parola

4. apasa butonul login

5. userul este redirectionat spre pagina my account.

Rezultate actuale vs REzultate asteptate

REzultate asteptate conform documentatiei cu cerinte si specificatiei

Ex: Utilizatorul ar trebui sa poata face comanda produsului chiar daca nu a

completat campul optional “telefon”

Rezultate actuale unde trecem exact rezultatul obtinut in urma testarii

Ex: Utilizatorul nu reuseste sa finalizez comanda desi a completat toti pasii

obligatorii.

Alte detalii pe care le putem include in raport: sistemul de operare, browser,

device, putem trece url-ul unde este bug-ul, versiunea aplicatiei,

Severitatea vs prioritatea unui bug.

Severitatea= critical (blocker) – ingheata aplicatia, inchide aplicatia, datele nu se

salveaza, flow-ul nu se poate executa. Ex; butonul cumpara nu functioneaza.

Major- ingheata aplicatia, inchide aplicatia, datele nu se salveaza, flow-ul nu se

poate executa. Ex: se poate folosi enter in loc de click pe cumpara si functioneaza.

Moderate(normal)= aplicatia produce un rezultat incorrect, incomplete sau

inconsistent fata de ce ar trebui sa se intample. (majoritatea sunt aici)

Minor = bug-ul nu are effect asupra sistemului, rezultatele dorite se pot obtine.

Ex: greseli de design, text, aliniere.

Enhancement (wishlist)= nu are de a face cu un bug, este o ocazia de a

imbunatati aplicatia.

Prioritatea unui bug se refera la ordinea in care se vor repara defectele gasite.

Niveluri: High – defect critical pe o functionalitate importanta sau enhancement

cu functionalitate permanenta ( greseala in logo sau in textul principal).

Medium-

Low- critical pe functionalitate adiacenta (link extern publicitar)

Capturarea ecranului(screenshot)

Trebuie captat intreg browser-ul, bara de url , fara bara de meniu a sistemului de
operare., incluzand chenar si sageti indicatoare catre comentarii

Viata unui bug

New ->reject, postponed sau duplicate ->in progress -> fixed -> retest ->
close.
 Test cases
Scenariul de test este reprezentat de o serie de actiuni prin care se verifica o
functionalitate a unei aplicatii. Testerul trb sa se puna in locul clientului final.

1 scenariu de test = o functionalitate

Ex: testarea functionalitatii de log in, log out, cautare produs

Fiecare scenario de test are unul sau mai multe cazuri de testare

Cazuri de utilizare

Set de actiuni pe care un utilizator al aplicatie le poate inteprinde

Cazul de utilizare= legatura dintre un system, utilizator si scopul actiunii

Elemente ale unui caz de utilizare:

Definirea scopului functionalitatii( ce este in corcondanta cu scopul si ce nu este)

ex: functionalitatea login, accesul in aplicaite este scopul, iar recuperarea parolei
pierdute nu este scopul.

Definirea pasilor efectuati de utilizator ( preconditii care trebuie indeplinite)

Ex: create account: are drept doar daca e logat in aplicatie, daca nu e logat, nu
poate crea useri noi.

Scenarii principale si secundare :

Ex: login – principal : user si parola corecta

Secundar: user si parola incorecte sau lipsesc.

Post conditii: ajunge pe pagina home , nu pe contact.

Descrierea se face din perspectiva utilizatorului

Cazuri de testare

Aplicatie bancara in functie de valoarea contului, calculeaza dobanda aferenta:

1-100 lei = 1%

100-1000 lei = 5%

>1000 = 10%

Prin tehnica EQUIVALENCE PARTITIONING putem identifica 3 partitii valide:

 0-100= 1% , 101-1000= 5%, .1001 = 10%

Poate exista partitie invalida daca in cont suma este <0 = 0%

Prin tehnica BOUNDRY VALUE ANALYSIS, putem rafina maim ult cazurile de
testare = cazuri de testare cu valorile de la limitele partitiilor : -25; 1,100;
101,1000; 1001 adica 6 cazuri de testare iar pentru a fi rigurosi putem adauga
inca 4 partitii, si ajungem la 10 cazuri de testare : -25,-1 ; 1, 50, 100 ; 101, 500,
1000 ; 1001, 5000 .

Implementarea si executarea cazurilor de testare folosind GOOGLE

SPREADSHEETS.

Spreadsheet-ul include:

- ID
- Descrierea
- Conditii preliminare
- Dependinte
- Pasi de executie
- Date de test
- Rezultate actuale
- Rezultate asteptate
- Data executiei
- Executantul cazului de testare

Se foloseste des deoarce simplifica foarte mult procesele de import, export ale
documentelor si se pot vizualiza modificarile in timp real.
Se pot creea template-uri care pot fi folosite ulterior de catre persoanele care au
nevoie de ele

Test management tools sunt folosite pentru a planifica activitatea de testare, a

intretine testarea manuala, a executa teste automate, a obtine informatii despre
rularea testelor, a pastra informatia despre cum este facuta testarea, a gestiona
defectele, a raporta progresul activitatii de testare.

Testing Techniques

TEstarea de tip black box

 Black boxing se foloseste atunci cand nu ai cunostinta despre structura codului,
detalii de implementare sau flow-uri interne.
Se bazeaza in intregime pe cerintele si specificatiile din documentatie.
Black box cuprinde testarea functionala, non functionala si regression.
Cele mai dese strategii folosite sunt Equivalence Partitioning si Boundry
Value Analysis, pentru a reduce cazurile de testare.

Pasii: Examinarea cerintelor si a specificatiilor -> Testarea pozitiva si negative

->Construirea cazurilor de testare pentur fiecare input -> toate cazurile sunt
testate iar rezultatele obtinute se compara cu cele asteptate.

EX: Aplicatia permite date de intrare de la -100 la 100 , datelor de intrare de la

-100 la 0 li se aplica o regula de procesare, iar celor de la 0 la 100 o alta regula de
procesare

Equivalence Partitioning

Este o tehnica de testare prin care datele de intrare pentru aplicatie se impart in
partitii egale cu date echivalente, din care se pot creea cazuri de testare.

Ex: pentru a testa campul in care se trec lunile din an, se fac 3 partitii:
- Partitie invalida <1 = 0
- Partitie valida 1-12= 1,2,3,4,….,12
- Partitie invalida >12= 13,14,15,…99

Boundary Value Analysis

Tehnica de testare in care cazurile de testare sunt scrise folosing datele de intrare
valorile de la limitele partitiilor.

EX: Parola : se accepta intre 6 si 10 caractere. Avem 3 partitii:

-invalida <6= 0,1,2,3,4,5
-valida 6-10 = 6,7,8,9,10
-invalida >10=11,12
Apoi identificam limitele pt fiecare partitie
-0,5
-6,10
-11,12 sau maximum care este permis.
Apoi trecem la crearea cazurilor de testare

Test Management & Control

TEST plan

1. Identificatorul test plan-ului : numar unic, versiunea test plan-ului

2. Referintele : documentele de baza, versiunea documentelor (planul de proiect,
cerinte functionale sau non functionalae.)
3. Introducerea : o scurta prezentare a test plan, o vedere de ansamblu a scopului
testarii
4. Obiectele testarii: detalii despre intreaga aplicatie, terte sisteme cu care aplicata
va interactiona
5. Functionalitatile care sunt in scop: ce urmeaza a se testa
6. Functionalitatile care nu intra in scop: de ce nu intra in scop
7. Strategia de testare: detaliem toata activitatea si ce tipuri de testare vom folosi,
8. Criteriile de trecere sau de respingere a punerii aplicatie in productie: numar
maxim de bug-uri admise si severitatea lor, procent minim de test case-uri
trecute.
9. Artefactele activitatii de testare: cazuri de testare, scripturi pentru automate,
rapoarte, alte docuemnte pe car ele vor clientii.
10. Dependitntele activitatii de testare: tool-uri, dispositive, licente, resurse umane,b,
acces la baza de date.
11. Responsabilii activitatii de testare: cine este responsabil
12. Graficul testarii: cat timp va dura un anumit tip de testare, cand se va incepe
testarea
13. Riscurile activitatii de testare: orice risc prevazut
14. Aprobarile necesare realizarii activitatii de testare.