Testare

De la Wiki.lug.ro
Versiunea din 25 noiembrie 2015 07:58, autor: 122.96.59.102 (Discuție) (Ce inseamna "Testarea software / QA Engineering?")

Salt la: navigare, căutare

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.

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!

uite mie windows 8 imi baga un ecran altabsru ce nu poate sa scrie pe usb device de fiecare data cand opresc imprimanta. si cere restart. si la restart imi cere repair. nu dureaza mult, dar e super enervant.apoi cand s-a luat curentul, prin minune mi-a disparut partitia aia de 100 de mega care o face. nu am reusit sa o refac cu repairul de win8, pentru ca era tot hdd-ul write protected, si nu am reusit sa scot wp-ul nici cu diskpart, desi el zicea ca imi scoate flagul.am refacut partitia cu win7 repair, ca ala ignora flagul de write protect, si abia dupa aia win 8 repair a putut sa isi repare bootul.astea sunt problemele care le am in win 8 in mai putin 1 luna de la cumparare. pe care nu le-am avut in win 7 de cand era in beta.p.s. microsoft tre sa fie condus de retardati. daca spera sa vanda surface la preturile alea, si care au avut ideea genialasa lanseze rt inainte de x86.pai normal ca lumea nu o cumpara, asteapta versiunea unlocked , nu prostia de rt. 0 0

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

Ei, uite ca eu nu m-am lamurit din exeplmul cu nunta sub copac (si nu ma refer la faptul ca nu sunt de acord cu argumentele oferite de fr. Marius) ci doar ca as vrea, desigur daca dansul are timp si dorinta, sa imi explice exact pe cazul dat ca ex. de mine ca sa inteleg mai bine. Poate pricep eu mai greu. sau poate am doar nevoie de o sinteza a celor spuse aseara.Cand am spus ca este un caz diferit de cel cu nunta sub copac m-am referit la faptul ca o parte din argumentele de aseara se pot demonta usor in acest caz mai ales cele ce tin de comunitate si biserica (cel putin in cazul meu asa a fost). M-am gandit ca un argument de genul Scriptura spune care sa fie foarte clar pt exeplmul meu ar fi de mare ajutor mai ales daca cei cu care vorbesc accepta ca singura autoritate Biblia. De aceea, am insistat pe argumente biblice.

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