VII Testarea aplicatiilor web

Aplicatiile web s-au dezvoltat într-o platforma de comunicare de baza pentru

multe companii. Aplicatiile web sunt cruciale pentru comert, schimbul de informatii si
pentru gazduirea activitatilor sociale. Din acest motiv, aplicatiile web trebuie sa ofere
o înalta performanta, fiabilitate si o mare usurinta în folosire. Furnizarea unor aplicatii
web de calitate pentru utilizatorii existenti si cei viitori reprezinta o provocare majora
pentru asigurarea calitatii. Testarea este una dintre cele mai importante masuri de
asigurare a calitatii. Metodele si tehnicile de testare traditionale se concentreaza în
principal pe testarea cerintelor functionale. Din pacate, acestea nu se concentreaza
suficient pe o cerintele de calitate importante pentru utilizatorii de aplicatii Web, cum
ar fi performanta, usurinta în folosire, fiabilitatea si securitatea. O provocare majora în
testarea aplicatiilor web este dominanta schimbarii. Cerintele utilizatorilor si
asteptarile, platformele si configuratiile, modelele de afaceri, dezvoltarea si testarea
bugetelor sunt subiecte supuse unor modificari frecvente pe tot parcursul ciclului de
viata al aplicatiilor web. Prin urmare, este necesara dezvoltarea unui sistem eficient
de testare care sa acopere o gama larga de caracteristici de calitate ale aplicatiilor
web, care sa faca fata la schimbari si care sa ajute la implementarea si buna întelegere
a unei testari sistematice, complete si lipsita de riscuri. O astfel de schema de test
formeaza baza pentru construirea unei metode model si a instrumentelor aferente.
Experienta practica a demonstrat ca testarea metodica si sistematica fundamentata
pe o astfel de schema este realizabila si utila pe tot parcursul dezvoltarii si evolutiei
aplicatiilor web.

Aplicatiile web sunt expuse unor noi provocari privind asigurarea calitatii si
testarea. Aplicatiile web sunt compuse din diverse componente software oferite în
anumite cazuri de anumiti producatori. Calitatea aplicatiilor web este în principal
determinata de calitatea fiecarei componente software implicate si de calitatea
legaturilor dintre acestea. Testarea este una din cele mai importante instrumente
folosite în dezvoltarea aplicatiilor web pentru realizarea produselor de înalta calitate,
care îndeplinesc asteptarile utilizatorilor.

Testarea aplicatiilor web merge dincolo de testarea software-ului din sistemele

traditionale. Desi se aplica cerinte similare la corectitudinea tehnica a unei aplicatii,
utilizarea unei aplicatii Web de catre grupuri eterogene de utilizatori, pe un numar
mare de platforme, duce la cerinte speciale de testare. Deseori este greu de anticipat
numarul viitor de utilizatori pentru o aplicatie web. Timpul de raspuns este unul din
factorii de succes decisivi pe Internet si trebuie sa fie avut în vedere din timp, chiar
daca platforma hardware finala este, în general, disponibila mult mai târziu. Alti factori
importanti pentru succesul aplicatiilor web sunt usurinta în folosire, disponibilitatea,
compatibilitatea browserelor, securitatea, actualitatea si eficienta.

7.1 Fundamentele testarii

7.2.1 Terminologie

Testarea este o activitate efectuata pentru a evalua calitatea unui produs si

pentru a îmbunatati-o prin identificarea problemelor si defectelor. Daca vom rula un
program cu intentia de a gasi erori, atunci putem vorbi de testare. Figura 7-1 arata ca
testarea este parte a masurilor de asigurare a calitatii analitice. Prin descoperirea
erorilor existente este determinata calitatea programului testat, în vederea
îmbunatatirii calitatii, acest lucru realizându-se de cele mai multe ori doar prin
eliminarea erorilor gasite.

Putem spune ca o eroare este prezenta în cazul în care rezultatul actual dintr-
un test nu este în conformitate cu rezultat asteptat. Rezultatul asteptat este specificat,
de exemplu, în definirea cerintelor. Aceasta înseamna ca fiecare abatere de la
definirea cerintelor este o eroare; în termeni mai generali, o eroare este "diferenta între
valoarea sau conditia calculata, observata sau masurata si valoarea corecta sau
conditia adevarata, specificata sau teoretic corecta" (standard IEEE 610.12-1990).

Aceasta definitie implica faptul ca definirea cerintelor utilizate ca baza pentru

testare este terminata si disponibila înainte de implementare si testare. Un fenomen
comun în dezvoltarea aplicatiilor web este ca cerintele sunt deseori incomplete,
neclare si reprezinta subiectul unor schimbari frecvente. De obicei, exista o viziune
initiala privind functionalitatea de baza, care este implementata în faza initiala de
lansare. Ca urmare, dezvoltarea ciclului initial de viata este urmata de mici cicluri de
functionalitati adaugate. Abordarile Agile (cum ar fi Extreme Programming) se
concentreaza pe natura evolutiva si repetata a dezvoltarii ciclului de viata fara a apela
la o definire extinsa a cerintelor. În consecinta, obiectivele, preocuparile si asteptarile
partilor interesate (mandatari) trebuie sa constituie baza testarii. Aceasta înseamna
ca, de exemplu, fiecare abatere de la valoarea asteptata în mod firesc de catre
utilizatori este, de asemenea, considerata o eroare.

În acest moment, partile interesate au asteptari diferite, iar unele dintre acestea
pot fi concurente si neclare. Din acest motiv, asteptarile partilor interesate nu vor fi un
reper util pentru a decide daca un rezultat este eronat, cu exceptia cazului în care un
set de asteptari au fost atinse si au fost puse la dispozitie în forma testabila. Pentru a
sprijini testerii în a avea o perspectiva a utilizatorilor si de a întelege mai bine
asteptarile utilizatorilor, acestia ar trebui sa fie implicati cât mai devreme posibil în
identificarea si definirea cerintelor.

Când discutam despre un test ne vom referi la un set de cazuri de testare

pentru un anumit obiect testat (de exemplu, o aplicatie web, componentele unei
aplicatii Web sau un sistem care ruleaza o aplicatie Web). Un singur caz de test
descrie un set de intrari, conditiile de executie, precum si rezultatele asteptate, care
sunt utilizate pentru a testa un anumit aspect al obiectului testat (standard IEEE
610.12-1990).

7.2.2 Caracteristici de calitate

Un utilizator nu asteapta doar ca o aplicatie sa se comporte într-un anumit mod;

de asemenea, se asteapta ca anumite functii sa fie disponibile 24 de ore pe zi si 7 zile
pe saptamâna (24x7). Mai mult, utilizatorii se asteapta ca aplicatia sa fie usor de
utilizat, fiabila, rapida si compatibila cu alte sisteme si versiuni viitoare. Pe lânga
comportament, de o deosebita importanta este testarea aplicatiei prin prisma
cerintelor de calitate (de exemplu, tipurile de caracteristici de calitate asteptate de
catre utilizatori).

În contextul aplicatiilor web, trebuie avute în vedere diferite caracteristici de

calitate. O taxonomie generala pentru caracteristicile de calitate ale produselor
software este specificata în standardul ISO/IEC 9126-1. Acest standard mentioneaza
sase categorii de caracteristici principale: functionalitate, fiabilitate, usurinta în folosire,
eficienta, mentenanta si portabilitate si le divide în continuare în mai multe sub-
caracteristici.

Cerintele de calitate joaca un rol esential în testarea aplicatiilor web. Chiar

daca acestea sunt în general similare cu cerintele de calitate pentru sistemele
software traditionale, ele ajung deseori dincolo de ele. Datorita importantei
caracteristicilor de calitate si diferentelor privind modul în care pot fi testate,
majoritatea metodelor de testare pentru aplicatiile Web se concentreaza pe una sau
câteva caracteristici de calitate. Cu toate acestea, toate caracteristicile de calitate sunt
importante pentru calitatea generala a unei aplicatii Web. Testarea trebuie sa se
asigure ca acestea sunt implementate cu succes.

7.2.3 Obiectivele testarii

Testarea nu va duce la îmbunatatirea calitatii cu exceptia cazului în care erorile

sunt detectate si eliminate. Principalul obiectiv al testarii este de a gasi erori și nu de
a arata absenta lor. Testele software sunt inadecvate pentru a dovedi absenta unor
erori. Daca un test nu gasește erori, atunci acest lucru nu înseamna ca testat cererea
nu contine nici un fel. Acestea, pur si simplu nu au fost înca detectate.

Numarul mare de caracteristici de calitate, toate valorile de intrare si

combinatiile de intrare potentiale care trebuie luate în considerare, inclusiv toate
conditiile si procesele potentiale, fac imposibila realizarea unei testari complete. Chiar
si o paleta larga de teste este de obicei imposibila, datorita ciclurilor de dezvoltare
extrem de scurte. Consecintele inevitabile sunt erorile în functiile testate si un risc mai
mare în apariția erorilor nedetectate. Acestea sunt motivele pentru care testarea tinde
spre o abordare bazata pe risc. Aceste parti ale unei aplicații în care erorile sunt
nedetectate si în care au consecințe critice, ar trebui sa fie testate primele,
acordânduli-se o atenție sporita. Explorând sursele de risc putem semnala defectele
mult mai direct decât pe fundamentarea testelor pe baza cerintelor. În consecinta, un
obiectiv important al testarii este de a aduce riscul la lumina.

Un test rulat are succes daca sunt detectate erori și daca sunt obținute
informatii suplimentare despre problemele si starea aplicației. Testele nereusite, cum
ar fi, testele în care nu sunt gasite erori, sunt "o pierdere de timp". Acest lucru este
valabil mai ales în dezvoltarea aplicatiilor web, în care testarea este în mod necesar
limitata la un minim, datorita resurselor limitate si presiunii de timp extreme în care se
dezvolta aplicatiile Web. Aceasta situatie necesita, de asemenea, descoperirea
erorilor grave cât mai devreme posibil pentru a evita investitiile inutile cum ar fi
costurile de gasire si eliminare a erorilor care cresc dramatic în fiecare etapa de
dezvoltare. Erorile care au aparut în fazele timpurii de dezvoltare sunt greu de localizat
în etapele ulterioare, si eliminarea lor cauzeaza, în mod normal, modificari ample si
necesitatea de a rezolva erorile ulterioare. Prin urmare, testare trebuie începuta cât
mai devreme posibil, preferabil la începutul unui proiect.

Pe scurt, putem spune ca ciclurile de testare, în general, si pentru proiectele

Web în particular, trebuie sa detecteze cât mai multe erori posibile, în mod ideal cât
mai multe erori grave, la cel mai mic cost posibil, într-o perioada cât mai scurta de timp
si cât mai devreme posibil.

7.2.4 Nivele de Test

În conformitate cu fazele de dezvoltare în care putem obține rezultate ale

testarii, putem identifica anumite nivele de test pentru facilitarea testarii acestor
rezultate.

. testarea unitaților: testarea celor mai mici unitati testabile (clase, pagini web,
etc), independent una de alta. Unitatea de testare este obținuta de dezvoltator, pe
parcursul implementarii.

. testele de integritate: evaluarea interactiunii între unitațile testate distinct si

separat dupa ce acestea au fost integrate. Testele de integritate sunt de obicei
efectuate de catre un tester, un dezvoltator sau de ambii.

. testele sistem: testarea completa, integrata a sistemului. Teste sistem sunt,

de obicei, efectuate de catre o echipa de test specializata.

. testele de acceptare: evalueaza sistemul în cooperare cu sau sub patronajul

clientului într-un mediu apropiat mediului de productie. Testele de acceptare utilizeza
condițiii și date reale.

. testele beta: permit utilizatorilor sa lucreze cu versiunile timpurii ale unui

produs cu scopul de a oferi feedback-ul din timp. Testele beta sunt informale (fara
planuri de testare si cazuri de test) și se bazeaza pe numarul și creativitatea
potentialilor utilizatori.

Pe masura ce dezvoltarea progreseaza, cineva va realiza o verificare vizavi de

specificatiile tehnice (daca este cazul) - la fel ca în testarea unitaților, testarea
integritații si testarea sistemului - la o validare a asteptarilor utilizatorilor - la fel ca în
testele de acceptare si testele beta.

Un risc inerent care apare atunci când se efectueaza testele secvential în

acord cu fazele proiectului este ca pot apare erori datorita neîntelegerii asteptarilor
utilizatorilor (care pot fi gasite numai într-un stadiu târziu), ceea ce conduce la costuri
mari de eliminare a acestora. Pentru a minimiza acest risc, testarea trebuie sa fie parte
integranta a construirii produsului si ar trebui sa cuprinda întregul proces de
dezvoltare. Prin urmare, masurile de asigurare a calitatii cum sunt recenziile sau
prototipizarea sunt utilizate deseori înainte de a rula testarea unitatilor. Un proces de
dezvoltare iterativ si evolutiv reduce acest risc deoarece partile mai mici ale sistemului
sunt testate frecvent pe toate nivelurile de test (inclusiv cele cu validare pentru
asteptarile utilizatorilor), astfel încât erorile pot fi depistate înainte de a putea avea un
impact asupra altor parti ale sistemului. Aceasta înseamna ca secventa nivelurilor de
test descrise mai sus nu sunt în permanenta dictate de succesiune temporala a testarii
proiectul web, dar pot fi efectuate de mai multe ori (de exemplu, o data pentru fiecare
dezvoltare a functionalitatii).
7.2.5 Rolul tester-ului

Pentru a gasi cât mai multe erori posibile testerii trebuie sa aiba o atitudine
"distructiva" fata de testare. O astfel de atitudine este dificila pentru un dezvoltator
care lucreaza la un modul software. Aceeasi perspectiva de abordare face deseori ca
dezvoltatorii sa realizeze aceleasi greseli si neîntelegeri pe perioada de testare,
greseli care au condus la erori pe perioada implementarii. Din acest motiv, (Myers
1979) sugereaza ca dezvoltatorii sa nu testeze propriile produse.

În proiectele web, se observa o focalizare sporita pe testarea unitatilor care

sunt scrise de dezvoltatori. Desi acest lucru este o încalcare a sugestiilor lui Myers,
testele suplimentare sunt, de obicei, efectuate de persoane diferite de dezvoltatorul
original (de exemplu, de catre testerii recrutati de departamentul de afaceri al
clientului).

Deoarece calitatea este întotdeauna o problema de echipa, o separare stricta

a testarii si dezvoltarii nu este recomandabila si prezinta un risc inerent în împiedicarea
cooperarii între programatori si testeri. În esenta, obiectivul urmarit este de a detecta
erori, erori care vor fi eliminate de catre dezvoltatori. În acest scop, se recomanda o
comunicare si o întelegere reciproca. Acest lucru înseamna pentru tester: "Cel mai
bun tester nu este cel care gaseste cele mai multe bug-uri sau care stânjeneste
majoritatea programatorilor. Cel mai bun tester este cel care depisteaza cele mai
multe bug-uri fixe. ".

Deoarece echipele de proiect web sunt multidisciplinare si cooperarea în

echipa este, de obicei, de scurta durata, este dificil pentru membrii echipei sa
stabileasca un nivel superior de încredere, necesara pentru o colaborare strânsa între
dezvoltatori si testeri.

7.3 Teste specifice ingineriei web

Elementele de baza prezentate anterior se aplica atât la testarea software-ului

traditional cât si în aplicatiile web. Testarea aplicatiilor web este diferita de testarea
produselor software traditionale, lucru datorat caracteristicilor specifice aplicatiilor
web:

. erorile din "continut" pot fi deseori gasite doar prin masuri costisitoare sau
organizationale (de exemplu, prin corectarea greselilor). Formularele simple de
verificare automata (de exemplu, un corector ortografic) sunt foarte valoroase, dar
sunt limitate la o paleta redusa de depistare a potentialelor defecte. Meta-informatiile
despre structurarea si semantica continutului sau despre un sistem de referinta care
furnizeaza valori comparative, sunt deseori o conditie prealabila pentru a putea
efectua testele de profunzime. Daca aceste premise nu sunt disponibile, trebuie gasite
alte abordari. De exemplu, daca apar schimbari frecvente privind modificarea datelor
legate de cantitatea de zapada dintr-un sistem de informare turistica, acestea nu pot
fi testate cu acuratete prin intermediul meta-informatiilor sau valorilor comparative, si,
în consecinta, valabilitate datelor poate fi restrictionata euristic la doua zile pentru a
se asigura actualitatea datelor.
 . când testam structura hipertext, trebuie sa ne asiguram ca paginile sunt legate
în mod corect (de exemplu, fiecare pagina trebuie sa fie accesibile printr-o legatura si,
la rândul sau, ar trebui sa aiba o legatura înapoi la structura hipertext). În plus, toate
legaturile trebuie sa duca la pagini existente, adica, nu trebuie sa fie "întrerupte".
Legaturile nefunctionale sunt erori frecvente atunci când legaturile statice predefinite
devin invalide (de exemplu, atunci când se face referire la o pagina web externa, care
a fost eliminata sau s-a schimbat structura acesteia). O alta sursa de erori este
navigarea prin intermediul functiilor browser-ului web (de exemplu, "Înapoi în Istoric",
în asociere cu starile în care o aplicatie web poate fi). Un exemplu tipic întâlnit este:
daca un utilizator adauga un articol în cosul de cumparaturi virtual în timp ce realizeaza
cumparaturi online, atunci acest articol va ramâne în cosul de cumparaturi, chiar daca
utilizatorul se duce cu un pas înapoi în istoricul browser-ului, afisând pagina anterioara
fara acel articol.

. cerintele soft, subiective de pe nivelul prezentare al aplicatiilor web (de

exemplu, "estetica"), sunt dificil de specificat. Cu toate acestea, ele sunt este o conditie
prealabila esentiala pentru tester pentru a putea distinge în mod clar si obiectiv
comportamentul acceptabil (si de dorit) la defectele de comportament. Mai mult, doar
câteva metode si tehnici traditionale pentru testarea software-ul sunt adecvate pentru
testarea prezentarii. Pentru a testa o prezentare, trebuie sa fie utilizate metode din
alte discipline (de exemplu, publicistica tiparita si masurile organizationale), în aceeasi
masura cu asigurarea calitatii continutului.

. numarul mare de dispozitive si caracteristicile lor diferite de performanta

(distribuirea multi-platforma) reprezinta o alta provocare. Chiar daca un tester dispune
de toate dispozitivele posibile, acesta ar trebui sa ruleze cazurile de test pentru fiecare
dispozitiv. Desi simulatoarele pentru dispozitive pot fi de ajutor daca tester-ul nu
dispune de dispozitivul fizic, ele însele prezinta în majoritatea cazurilor defecte.

. datorita disponibilitatii si utilizarii globale ale aplicatiilor web, exista o serie de

provocari în ceea ce priveste multi-lingvismul si usurinta în folosire în testarea
aplicatiilor web. Provocarea principala este de a recunoaste interdependentele
culturale si le ia în considerare în mod adecvat de test. De exemplu, ordinea de citire
în diferite culturi (de exemplu: araba, chineza) implica folosirea de ajutoare de
navigare laterale în fereastra browser-ului. O alta dificultate provine din lungimea
diferita a mesajelor de tip text în limbi diferite, care poate determina probleme în
afisarea layout-ului.

. "tineretea" si "multi-disciplinaritatea" echipelor sunt adesea legate de slaba

acceptare a metodologiilor si de nepromptitudinea în efectuarea testarii. Deseori,
trebuie acumulate pe parcurs cunostinte despre metodele, tehnologiile si
instrumentele necesare pentru realizarea testarii. De asemenea sunt necesare puncte
de vedere diferite cu privire la testare. Numai o echipa formata din membri cu
experienta vor ajunge la o decizie corecta despre volumul testarii - prea multa testare
poate fi la fel de neproductiva ca cea insuficienta. Testerii sunt deseori tentati sa
testeze tot în întregime, mai ales la început.

. aplicațiile web constau dintr-un numar de diferite componente software (de

exemplu: servere web, baze de date, middleware) si sisteme integrate (de exemplu:
sisteme ERP, sisteme de management al continutului), care sunt oferite de diferiți
furnizori, si implementate cu ajutorul unor tehnologii. Aceste componente formeaza
infrastructura tehnica a aplicatiilor Web. Calitatea unei aplicatii Web este în principal
determinata de calitatea tuturor componentelor software singulare si de calitatea
interfetei dintre ele. Aceasta înseamna ca, pe lânga componentele dezvoltate într-un
proiect, va trebui sa testam componentele software furnizate de parti terte, dar si
integrarea si configurarea acestor componente. Multe erori în aplicatiile web rezulta
din "imaturitatea" unei componente software, "incompatibilitatea" între componentele
software, sau defecte de configurare a componentelor software corecte.

. "imaturitatea" majoritații metodelor și instrumentelor de testare reprezinta

provocari suplimentare pentru testeri. Daca o aplicatie Web este implementata cu o
tehnologie noua, de cele mai multe ori nu exista înca metode si instrumente de testare
adecvate. Daca instrumentele de testare devin disponibile, multe dintre ele sunt
imature, prezinta defecte si dificil de utilizat.

. "dominanta schimbarii" face ca testarea aplicatiilor web sa fie mai complexa

decât testarea software-ului traditional. Cerintele si asteptarile utilizatorilor,
platformele, sistemele de operare, tehnologiile si configuratiile Internet, modelele de
afaceri si de asteptarile clientilor, dezvoltarea si testarea bugetelor sunt subiectul unor
frecvente modificari pe tot parcursul ciclului de viata al unei aplicatii Web. Adaptarea
la cerintele noi sau modificate este dificila pentru ca functionalitatea existenta trebuie
sa fie reanalizata, ori de câte ori se face o schimbare. Aceasta înseamna ca un singur
fragment de functionalitate trebuie sa fie testat de mai multe ori, în ideea realizarii unor
teste automate si repeatable. Acestea pun accentul în special pe teste de regresie,
care verifica daca ceea ce s-a lucrat functioneza dupa o anumita schimbare. Upgrade-
urile si migrarea aplicatiilor web, determinate de schimbarile permanente ale
platformelor, sistemelor de operare sau hardware-ului, trebuie sa ruleze si sa
dovedeasca ca sunt un succes în mediul de test, pentru a ne asigura ca nu vor fi
probleme neasteptate în mediul de productie.

7.4 Abordari privind testarea

Abordarile Agile (cum ar fi Extreme Programming) sunt din ce în ce mai folosite

în proiectele web. În timp ce abordarile Agile se concentreaza pe colaborare,
abordarile traditionale se focalizeaza pe planificarea si managementul proiectului. În
functie de caracteristicile unui proiect web, poate fi necesara realizarea activitatilor de
testare folosind atât abordarile Agile cât si cele traditionale pe parcursul proiectului.
(Boehm si Turner 2003) descriu pe larg modul de a gasi a un echilibru corect
între agilitate si disciplina în proiecte. În continuarea, vom prezenta caracteristicile
abordarilor de testare traditionale si Agile, si vom evidentia modul în care acestea
difera.

7.4.1 Abordarile traditionale

Din perspectiva unei abordari traditionale, activitatile de testare dintr-un proiect

includ planificarea, pregatirea, executarea si raportarea:

. Planificarea: pasii planificarii definesc obiectivele de calitate, strategia

generala de testare, planurile de test pentru toate nivelurile de test, metodele metrice
si de masurare si testarea mediului.
 . Pregatirea: Acest pas implica selectarea tehnicilor si instrumentelor de
testare si specificarea cazurilor de test (inclusiv datele de test).

. Executarea: Acest pas pregateste infrastructura de test, executa cazurile de

test si în final documenteaza si evalueaza rezultatele.

. Raportarea: Acest pas final rezuma rezultatele testelor si genereaza

rapoartele testarii.

Abordarile traditionale definesc rezultatele muncii (de exemplu, planul de

calitate, strategia de testare, planurile de test, cazurile de test, masuratorile testarii,
mediul de testare, rapoartele de testare) si rolurile (de exemplu, managerul testarii,
consultantul testarii, specialistul testarii, specialistul instrumentelor de testare),
precum si pasii detaliati pentru a crea rezultatele (de exemplu, analiza datelor de test
disponibile sau pregatirea/furnizarea datelor de test). Abordarile Agile, definesc
obiectivul de calitate si apoi se bazeaza pe echipa sa se auto-organizeze si sa creeze
un software care îndeplineste (sau depaseste) obiectivul de calitate.

Datorita ciclurilor scurte de a ajunge pe piata în care se dezvolta aplicatiile Web,

este necesar sa selectam doar cele mai importante rezultate ale muncii, rolurile cheie
si sa eliminam pasii de lucru inutili. Activitatile de testare trebuie sa fie începute cât
mai devreme posibil pentru a scurta perioada distribuirii. De exemplu, activitatile de
planificare si de proiectare pot fi finalizate înainte de începerea dezvoltarii, iar
rezultatele muncii pot fi verificate static, de îndata ce acestea devin disponibile. Figura
7-2 demonstreaza ca acest lucru va scurta perioada de livrare, care respecta astfel
ciclurile scurte de dezvoltare ale aplicatiilor web.

Abordarile Agile presupun ca o echipa va gasi solutii la probleme, în comun si

în mod autonom (se bazeaza pe auto-organizare). Acest lucru se aplica, de
asemenea, la teste. Prin urmare, testarea nu este o chestiune de roluri ci de o mai mai
buna colaborare si utilizare a aptitudinilor disponibile în echipa. Aceasta înseamna ca
testarea este o activitate de dezvoltare integrata. Întreaga echipa este responsabila
pentru calitate si pentru testare.

Abordarile Agile omit activitatile care nu par sa promita un beneficiu imediat.

De exemplu, ele documenteaza anumite aspecte sau scriu planuri de test; în schimb,
ele comunica direct, exprimând în mod clar asteptarile. Membrii echipei trebuie sa
coopereze strâns si sa se "înteleaga" reciproc pentru a se asigura ca erorile sunt
depistate si analizate rapid, eliminate în mod eficient.

Într-o abordare Agile, dezvoltatorii efectueaza testarea unitaților, adica ei își

testeaza propria munca. Prin automatizarea acestor teste ale unitaților, acestea pot fi
folosite ca mici "detectoare ale schimbarii". De fiecare data când o mica porțiune din
aplicație nu mai functioneaza adecvat, schimbarea va fi detectata imediat. Întârzierea
între apariția unei erori si detectarea acesteia este redusa în mod semnificativ, ceea
ce face mai usor pentru dezvoltatori sa corecteze eroarea, deoarece activitatile sau
modificarile recente sunt înca proaspete în mintea lor. Pe lânga feedback-ul rapid,
testele automatizate sunt o cerinta prealabila importanta pentru ciclurile scurte de
dezvoltare si pentru refactoring (reproiectarea unui program pastrându-se semanticile
pentru reducerea redundanței si cresterea calitații proiectarii).
 Într-o echipa poate exista un tester dedicat, acceptat de echipa de dezvoltatori
care îsi asuma calitatea de conducator pentru asigurarea calitații, în cadrul echipei.
De asemenea, un tester poate pregati teste functionale (care sunt pe un nivel mai
mare de abstractizare decât testea unitaților dezvoltatorilor) si face scripturile de test
tolerante la modificari. În plus, tester-ul poate sprijini clientul cu teste functionale
scrise.

Urmatoarele practici de Extreme Programming (XP) au o influenta speciala

asupra asigurarii testarii si calitatii:

. programarea în pereche: accelereaza schimbul de cunostinte între

dezvoltatori, între dezvoltatori si testeri si, în general, în cadrul echipei. Similar cu
inspectarea software-ului, ajuta la detectarea din timp a erorilor.

. un client de pe site: este disponibil pentru întrebari privitoare la cerinte, în orice

moment si ia decizii în acest sens. Împreuna cu tester-ul, clientul de pe site pregateste
pentru testele functionale, care pot fi folosite pentru testele de acceptare ulterior.

. integrarea continua: ne asigura ca acești mici pasi contribuie la minimizarea

riscului la modificari, si parcurge toate testele pentru o verificare continua a faptului ca
întregul sistem este infailibil.

. testarea înainte de dezvoltare: se refera la faptul ca testele sunt scrise înainte

de cod, asigurându-se ca "dezvoltatorii", se gândesc la "ce" înainte de a implamenta
"cum". Aceste teste sunt automatizate, astfel încât acestea sa poata fi folosite pentru
o integrare continua.

Abordarea Agile se refera în principal la testarea unitaților si la testele de

acceptare. În contrast, abordarile conventionale sunt folosite pentru integrarea și
testarea sistemului ("testarea în ansamblu").