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 testarii7.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").