Testare

Acest articol este în curs de editare de către dragos.iorgulescu. Dacă doriți să interveniţi în procesul de editare, cereți mai înainte permisiunea autorului pe pagina sa de discuţii.

Kudos to you! I hadn't tohuhgt of that!

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