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 trziu. 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 realizndu-se de cele mai multe ori doar prin eliminarea erorilor gasite. Putem spune ca o eroare este prezenta n cazul n care rezultatul actual dintrun 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 ct mai devreme posibil n identificarea si definirea cerintelor. Cnd 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 saptamna (24x7). Mai mult, utilizatorii se asteapta ca aplicatia sa fie usor de utilizat, fiabila, rapida si compatibila cu alte sisteme si versiuni viitoare. Pe lnga 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 cteva 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 gasete 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 apariia erorilor nedetectate. Acestea sunt motivele pentru care testarea tinde spre o abordare bazata pe risc. Aceste parti ale unei aplicaii n care erorile sunt nedetectate si n care au consecine critice, ar trebui sa fie testate primele, acordnduli-se o atenie sporita. Explornd sursele de risc putem semnala defectele mult mai direct dect 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 obinute informatii suplimentare despre problemele si starea aplicaiei. 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 ct 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 ct 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 ct mai multe erori posibile, n mod ideal ct mai multe erori grave, la cel mai mic cost posibil, ntr-o perioada ct mai scurta de timp si ct mai devreme posibil. 7.2.4 Nivele de Test

n conformitate cu fazele de dezvoltare n care putem obine rezultate ale testarii, putem identifica anumite nivele de test pentru facilitarea testarii acestor rezultate. . testarea unitailor: testarea celor mai mici unitati testabile (clase, pagini web, etc), independent una de alta. Unitatea de testare este obinuta de dezvoltator, pe parcursul implementarii. . testele de integritate: evaluarea interactiunii ntre unitaile 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 condiiii 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 unitailor, testarea integritaii 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 cnd se efectueaza testele secvential n acord cu fazele proiectului este ca pot apare erori datorita nentelegerii asteptarilor utilizatorilor (care pot fi gasite numai ntr-un stadiu trziu), 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 nct 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 ct 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 nentelegeri 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 stnjeneste 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 strnsa ntre dezvoltatori si testeri. 7.3 Teste specifice ingineriei web Elementele de baza prezentate anterior se aplica att la testarea software-ului traditional ct 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. . cnd 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 rndul 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 cnd legaturile statice predefinite devin invalide (de exemplu, atunci cnd 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 ntlnit este: daca un utilizator adauga un articol n cosul de cumparaturi virtual n timp ce realizeaza cumparaturi online, atunci acest articol va ramne n cosul de cumparaturi, chiar daca utilizatorul se duce cu un pas napoi n istoricul browser-ului, afisnd 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 cteva 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. . aplicaiile 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 diferii 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 lnga 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" majoritaii 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 dect 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 cte 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 att abordarile Agile ct 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 ct 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, exprimnd n mod clar asteptarile. Membrii echipei trebuie sa coopereze strns 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 unitailor, adica ei i testeaza propria munca. Prin automatizarea acestor teste ale u nitailor, acestea pot fi folosite ca mici "detectoare ale schimbarii". De fiecare data cnd o mica poriune din

aplicaie nu mai functioneaza adecvat, schimbarea va fi detectata imediat. ntrzierea ntre apariia unei erori si detectarea acesteia este re dusa 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 lnga feedback-ul rapid, testele automatizate sunt o cerinta prealabila importanta pentru ciclurile scurte de dezvoltare si pentru refactoring (reproiectarea unui program pastrndu-se semanticile pentru reducerea redundanei si cresterea calitaii proiectarii). ntr-o echipa poate exista un tester dedicat, acceptat de echipa de dezvoltatori care si asuma calitatea de conducator pentru asigurarea calitaii, n cadrul echipei. De asemenea, un tester poate pregati teste functionale (care sunt pe un nivel mai mare de abstractizare dect testea unitailor dezvoltatorilor) si fac e 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 aceti 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, asigurndu-se ca "dezvoltatorii", se gndesc la "ce" nainte de a implamenta "cum". Aceste teste sunt automatizate, astfel nct acestea sa poata fi folosite pentru o integrare continua. Abordarea Agile se refera n principal la testarea unitailor si la testele de acceptare. n contrast, abordarile conventionale sunt folosite pentru integrarea i testarea sistemului ("testarea n ansamblu").