Modificare „Testare”

{{in lucru|dragos.iorgulescu}}

==Introducere==
===Cauzele defectelor===
----

'''Defectele''' sunt cauzate de '''erorile''' umane introduse in timpul dezvoltarii unui program. Ele se manifesta fie prin functionarea incorecta a aplicatiei la nivel logic, fie prin nefunctionarea sa sau printr-un comportament, sa ii spunem, deviant (erori, crash-uri, etc.).
Oricare are fi natura unui defect, el poarta numele de '''"BUG"''' (ce NU este un acronim de la "Behaves Usually Good" :) ). 
'''Bug-urile''' apar datorita faptului ca oamenii ce realizeaza aplicatiile sunt, evident, oameni. Indiferent de nivelul de experienta al dezvotlatorilor, design-erilor, arhitectilor si a testerilor, erorile sunt ceva natural. Problema care se ridica este "cum procedam astfel incat produsele software sa contina cat mai putine erori probabile?". Voi incerca prin cele ce urmeaza sa aduc cat mai multe raspunsuri si solutii acestei probleme.

Sa incepem!

===Ce inseamna "Testarea software / QA Engineering?"===
----
Nimic altceva decat suma tuturor procedurilor, operatiilor si actiunilor menite sa asigure buna functionare a programelor. Prin "buna functionare" intelegem: 

* Respectarea specificatiilor / cererilor clientului
* Implementarea corecta a cerintelor de functionare (requirements)
* Absenta erorilor de proiectare logica si algoritmica
* Siguranta datelor folosite in cadrul programului
* Viteza optima de rulare a aplicatiei
* Folosirea eficienta a resurselor disponibile
* Grad ridicat de usability (?)

In acceptiunea generala, testarea se caracterizeaza prin rularea testelor. Aceasta este, in schimb, doar partea vizibila din exterior. Pentru a asigura toate cele de mai sus, este nevoie de mult mai multe etape pana a ajunge in punctul executiei testelor.
Din motive de eficienta, planurile de teste trebuie neaparat sa contina si o perioada de timp alocata planificarii testelor, design-ului test case-urilor, planificarii executiei si, bineinteles, analizei rezultatelor.

Procesul fundamental de testare este alcatuit din urmatoarele activitati principale:

* Planificare si control
** Verificarea misiunii de testare, definirea obiectivelor si specificarea activitatii de testare astfel incat aceasta sa atinga obiectivele si scopul misiunii
** Compararea progresului / evolutiei actual(e) cu planul initial si raportarea starii de fapt, inclusiv deviatiile de la plan. Pentru a controla eficient procesul de testare, acesta trebuie monitorizat pe toata durata proiectului.
* Analiza si Design
** Sectiunea in care obiectivele sunt transformate in test case-uri si conditii de testare tangibile
* Implementare si executie
** Sunt definite proceduri de testare si/sau scripturi prin aranjarea test case-urilor intr-o anumita ordine si includerea de informatii aditionale necesare executiei; se pregateste mediul de test si se executa testele
* Evaluarea rezultatelor si raportarea acestora
** Analiza rezultatelor executiei testelor si compararea acestora cu obiectivele initiale; evident, raportarea situatiei
* Finalizarea procesului de testare
** Adunarea de date stranse pe parcursul proiectului (cifre, numere, impresii ale membrilor echipei, etc.) in vederea analizei workflow-ului

===De ce avem nevoie de testare si cine o poate face?===

===Principii===
===Testarea si calitatea===
===Rolul testarii in cadrul dezvoltarii si a mentenantei===

=="Psihologia" testarii==

Ar trebui sa fie evident pentru toata lumea ca procesul testarii unui produs este privit ca fiind unul distructiv, chiar ofensator catre cei ce l-au dezvoltat. Testerii sunt priviti de multe ori cu un soi de ura de catre dezvoltatori mai ales si, de multe ori, desconsiderati. 

Si asta e bine! Personalul responsabil cu calitatea unui produs trebuie sa fie acel ghimpe-n coasta dezvoltatorilor, acel om care poate spune cu nonsalanta in ziua unui release public ca produsul nu e inca matur si nu trebuie sa iasa pe piata daca nu se doreste falimentul proiectului.

Testarea este o activitate constructiva din punct de vedere managerial si al analizei riscurilor.
Pentru a cauta defecte si potentiale erori intr-un sistem, este nevoie de multa curiozitate, pesimism, mare atentie la detalii, spirit critic si analitic si o fire comunicativa, in special cu dezvoltatorii.

Atat timp cat defectele si erorile sunt comunicate intr-o maniera corespunzatoare, tensiunile dintre tester si dezvoltator pot fi eliminate definitiv. In cele din urma, sa nu uitam ca interesul comun trebuie sa fie intotdeauna calitatea si eficienta produsului oferit, iar sentimentul efortului colectiv trebuie sa se regaseasca in fiecare. Privind aspectul din urma, managerii firmelor au o foarte mare influenta. Ei pot crea si sustine acest sentiment, prin incurajari periodice si obiectivitate.

* Tester-ul nu este ultima linie de aparare a clientului! El nu are rolul de a tine produsul departe de client si nici doar rolul de a gasi bug-uri la nesfarsit! Daca se intampla asta, problema este mult mai adanca.

* Tester-ul trebuie sa raporteze problemele intr-un mod neutru, evitand criticarea persoanei ce a dezvoltat modulul/programul in cauza!

* Intotdeauna, tester-ul trebuie sa inteleaga persoanele din jur si, mai ales, motivele ce le fac sa reactioneze intr-un anumit fel (mai ales in conditii de stres)

* Asigurati-va ca persoana careia va adresati intelege exact ceea ce ati spus! Clarificati orice aspect inainte de a trece la actiune!

==Metode de testare==
===Metoda "White Box"===

Este opusul metodei Black box. In acest caz, se presupune ca tester-ul are acces in sursele programului (structuri, cod, algoritmi). De multe ori, testarea prin aceasta metoda implica scrierea de cod sau cel putin, urmarirea celui existent. Practic, luand la cunostinta constructia programului si modul sau de lucru, se testeaza fiecare metoda in parte initial, cat si interoperarea metodelor.

Aceasta metoda este aproape identica cu testarea unitara.

===Metoda "Gray Box"===

Pe parcursul anilor, aceasta metoda a aparut din nevoie si practicabilitate. Este, dupa cum ii spune si numele, etapa intermediara intre "White box" si "Black box". Ca mod de lucru, avand acces la sursele programului, se construiesc test case-urile. Dupa care, acestea sunt executate in mod Black box ca si user simplu, neaxandu-ne in momentul executarii testului pe structura interna a programului.

===Metoda "Black Box"===

Presupune testarea programului la nivelul user-ului, plecand de la premisa ca nu cunoastem modul in care acesta functioneaza. Practic, nu luam in calcul modul in care programul este construit si metodele sale, ci pur si simplu noi ii cerem ORICE, iar programul trebuie sa ne dea un raspuns. Pentru acest tip de testare, tester-ul trebuie sa cunoasca rezultatele ce se asteapta din partea programului pentru fiecare caz in parte.

==Nivele de testare==
===Testarea componentei / Component testing===

===Testarea integrarii / Integration testing===
===Testarea unui sistem / System testing===
===Teste de acceptanta / Acceptance testing===

==Unelte==
s