Erori, defecte si esecuri in testarea software
Asa cum aminteam si in introducerea articolului meu precedent, testarea software este o componenta esentiala si obligatorie in orice echipa de dezvoltare in IT. Scopul principal este acela de a preintampina si de a raporta greselile de orice natura descoperite in cadrul aplicatiilor, indiferent de tipul acestora (web, mobile, desktop etc.).
Totusi, termenii de „greseala” sau „bug” sunt destul de generici, existand o terminologie specifica pentru aceste scapari ce pot fi depistate in cadrul procesului de dezvoltare software. In principal, conform teoriei generale de testare software sustinuta de catre ISTQB, sunt 3 termeni specifici: eroare, defect si esec. In continuare ii vom explica pe rand.
Erorile
Prin termenul de „eroare” se intelege conform manualului ISTQB „o actiune umana care produce un rezultat incorect”. Definitia fiind destul de simpla si generala, ea face referire la orice greseala pe care un om o poate face in dezvoltarea unui produs software, nu doar la partea de programare efectiva, ci chiar in fazele incipiente, cand se elaboreaza cerintele proiectului (requirements) sau cand se gandeste design-ul aplicatiei. Eroare (Error) este sinonim cu mistake (greseala). Printre cauzele care stau la baza producerii erorilor se regasesc:
- Presiunea timpului (mai ales daca deadline-urile sunt foarte stranse)
- Lipsa de experienta sau a anumitor competente ale participantilor la proiect
- Natura fiintei umane care este mereu supusa greselii („A gresi e omeneste”)
- Lipsa de comunicare intre participantii la proiect, intre cei care elaboreaza cerintele si cei care fac design-ul
- Complexitatea prea mare a proiectului si a cerintelor tehnice poate prea complicate
- Tehnologiile noi, necunoscute inca suficient de bine.
Un exemplu de eroare ar fi cand unul dintre membrii echipei uita sa treaca in specificatiile tehnice ale unui magazin online optiunea de Forgot password?, aceasta eroare nu este depistata si se ajunge la etapa de scriere a codului, unde niciun programator nu sesizeaza (ipotetic spus) acest lucru. Astfel, ajungem la urmatoarea categorie, defectele.
Defectele
Un defect reprezinta o imperfectiune sau o deficienta a unui produs in lucru care nu indeplineste cerintele sau specificatiile acestuia, stabilite anterior. Ca sinonime, defectul (defect) este echivalent cu greseala (bug sau fault). Practic, diferenta dintre eroare si defect este data de momentul in care apar fiecare: eroarea se strecoara de regula in fazele incipiente ale proiectului, cand se scriu cerintele, pe cand defectele apar in faza de dezvoltare efectiva a acestuia, cand se scrie cod pe baza specificatiilor tehnice si a design-ului stabilite anterior.
Astfel, un defect poate fi perpetuarea unei erori din requirements, fie poate aparea direct cand se scrie cod, chiar daca documentatia si partea de design sunt corecte.
Exemplele de defecte pot fi multiple. Mergand in continuarea exemplului dat la erori, daca in specificatiile din documentatie scrie ca magazinul nostru online trebuie sa aiba un buton pentru Forgot password? iar programatorul nu il introduce in codul proiectului, acesta e un defect care afecteaza direct utilizatorul, nu isi mai poate recupera accesul la cont. Sau daca in documentatie scrie ca fundalul magazinului trebuie sa aiba o anumita nuanta de rosu, si acesta apare albastru, e tot un defect, pentru ca nu respecta cerintele, chiar daca nu il afecteaza direct pe utilizator.
Mai exista desigur si cazul cand o eroare este strecurata si la faza de dezvoltare, devenind un defect. Daca in cerinte nu apare optiunea de recuperare parola, si nici programatorul nu sesizeaza aceasta lipsa si construieste magazinul online fara recuperare parola, atunci acesta va fi un defect major, aparut dintr-o eroare initiala la crearea documentatiei. Cu cat sunt depistate mai rapid aceste scapari, cu atat creste mai mult calitatea finala si se reduc costurile de timp si bani. Insa ce se intampla daca erorile si defectele nu sunt depistate nici in faza de elaborare a cerintelor, nici in cea de codare?
Esecurile
Raspunsul e simplu: apar esecurile. Fiind echivalent in limba engleza cu failure ce se traduce ca atare, un esec este definit ca fiind „un eveniment in care o componenta sau un sistem nu executa o anumita functie ceruta in limitele specificate”. Dupa cum se poate observa, esecul este o greseala intr-un proiect care a ajuns deja in faza sa finala, cand e deja lansat iar aceasta scapare este deja intalnita de catre utilizatori, dand nastere unor efecte neplacute ca experienta de utilizare (User Experience), ce necesita costuri imense de remediere, unele consecinte putand fi chiar tragice.
conform ISTQB
Esecul este deci un defect sau o serie de defecte ale unui proiect ce a fost deja lansat. Trebuie zis si ca nu toate defectele conduc automat la esecuri / defectiuni; unele defecte raman nedescoperite in codul proiectului, iar daca nu sunt accesate aproape niciodata, fiind functii mai putin folosite, nu vor da nastere unor situatii neplacute de utilizare. In istorie au existat mai multe esecuri celebre in industria software, unele dintre ele au cauzat panica printre oameni, neincredere, pierderi financiare semnificative si chiar de vieti omenesti.
Un bug celebru care a facut valuri printre toti pasionatii de calculatoare si nu numai a fost asa-zisul „bug al mileniului” Y2K (de la anul 2000). Acest bug presupunea ca majoritatea calculatoarelor din lume nu vor fi capabile sa isi actualizeze anul din calendarul lor, deoarece acestea afisau ultimele 2 cifre, de la 1999 apare „99”, si exista problema ca la anul 2000 nu va aparea „00”. Desigur, lucrurile s-au rezolvat in mare fara prea multe probleme, lumea nu s-a prabusit, dar acest bug a creat panica printre oameni, iar multe companii au fost nevoite sa cheltuiasca milioane de dolari pentru mentenanta softurilor.
Un alt bug din istoria recenta care a avut consecinte majore este cel al avionului Airbus A400M care din cauza unei erori din sistemul sau software, s-a prabusit in Spania, langa Sevilla. Acesta era un avion militar de transport care executa la acel moment un zbor de antrenament, si se pare ca din cauza unei erori a softului de la bord, aceasta a cauzat un esec in executia manevrelor sale si s-a prabusit. Aceasta catastrofa a dus la moartea a 4 membri ai echipajului iar alti 2 au fost raniti. Chiar si compania Microsoft a avut foarte multe rateuri de-a lungul timpului din cauza unor erori nedepistate la timp, lucru ce demonstreaza ca testarea este necesara oriunde, chiar si la companiile mari si importante.
Concluzii
In incheiere, este important sa retinem cateva idei esentiale. Bug-urile in testarea produselor software sunt de mai multe tipuri, putand fi clasificate in erori, defecte si esecuri in functie de momentul cand sunt depistate. Ideal este ca acestea sa fie descoperite cat mai din timp, chiar din faza de requirements sau dezvoltare, ca sa fie corectate fara alte daune pentru utilizatori. Defectele care ajung la oameni pot avea implicatii medii sau grave, pot cauza pierderi financiare si in cele mai tragice situatii, chiar de vieti omenesti. Tocmai de aceea testarea nu trebuie subestimata niciodata in calitatea sa de etapa obligatorie pentru dezvoltarea unui produs software.
Surse de citit
Site-ul ISTQB, cu mai multe resurse pentru testare
Despre erori, defecte si esecuri
Despre esecuri software celebre gasesti informatii 👉 aici, 👉 aici, 👉 aici si nu numai.
