Probabil mulți dintre noi am testat aplicații de-lungul timpului cu sau fără intenția noastră. De multe ori, testăm o aplicație recent lansată sau nu doar, și avem șansa să găsim de la erori micuțe (numite bug-uri) la unele mai mari. Erori precum timp îndelungat de așteptare, poate erori de network sau pur și simplu un comportament deficitar al aplicației.
Aceste bug-uri apar din greșeli sau erori în faza de proiectare a unui proiect complex sau chiar a unei aplicații mobile. Este sunt localizate fie în codul sursă, fie în componente sau chiar în sistemele de operare folosite.
Un studiu din 2002, comandat de către Departamentul de Comerț din SUA, al Institutului Național de Standarde și Tehnologie, au concluzionat că bug-urile sunt extrem de răspândite și dăunătoare. Acestea afec tează costurile economiei SUA, la o sumă estimată de 59 de miliarde de dolari anual, adică aproximativ 0,6 % din produsul intern brut.
Tipuri de bug-uri în dezvoltarea software
-
Bug-uri de funcționalitate
Funcționalitatea unei aplicații este modul în care aplicația este concepută să funcționeze. Bug-urile de funcționalitate sunt acele erori care intervin neprevăzute și interferează cu interacțiunea utilizatorului. Experiența acestuia poate deveni confuză, derutantă sau chiar imposibilă. Un exemplu simplu, este butonul de ieșire (Cancel) din cadrul oricărei aplicații. În momentul În care apăsam butonul de Cancel și această acțiune nu are niciun efect, experiența devine confuză pentru utilizatori.
-
Bug-uri de comunicare
Acestea sunt erorile comune care apar în momentul comunicării software-ului cu end-user-ul. Mai exact, toate informațiile de care are nevoie utilizatorul pentru a putea naviga prin aplicație, ar trebui să fie disponibile.
Câteva exemple de erori de comunicare sunt: lipsa unor instrucțiuni de utilizare sau a unui meniu “Help” din cadrul oricărei aplicații, funcționalitățile noi apărute, dar fără documentație în meniul de ajutor. Chiar și un buton simplu de ‘Salvare’ care în loc să salveze acțiunea, șterge un fișier, reprezintă un bug de comunicare.
-
Lipsa erorilor de comenzi
Acest tip de erori, apar atunci când așteptăm o comandă, dar aceasta lipsește cu desăvârșire. Să luăm exemplul creării unui proiect nou. Fereastra oferă posibilitatea utilizatorului să își creeze proiectul nou. Cu toate acestea, lipsește opțiunea de ieșire în cazul în care utilizatorul renunță la crearea noului proiect. Atâta timp cât butonul de ‘Cancel’ lipsește și această eroare persistă, se numește o eroare de lipsă de comandă.
-
Bug-uri de sintaxă
Una din cele mai comune erori în aplicații sunt bug-urile de sintaxă. În majoritatea cazurilor, acestea sunt cuvinte scrise greșit gramatic, propoziții incorecte, lipsa unor cuvinte din cadrul unui text. Aceste erori sunt destul de evidente în cadrul testării software-ului GUI. Bineînțeles, nu ne referim la erorile de sintaxă din codul sursă. Compilatorul va avertiza programatorul legat de orice eroare de sintaxă care apare în codul sursă.
-
Bug-uri de gestionare a erorilor
Orice erori care pot apărea în momentul în care utilizatorul interacționează cu soft-ul, trebuie gestionate cu cât mai multă claritate și sens. În cazul în care se omite acest lucru, noi le denumim ‘Bug-uri de gestionare a erorilor’.
Observați imaginea atașată mai jos. Această eroare nu oferă nicio indicație despre ce fel de eroare a apărut în sistem. Să fie oare o eroare din cauza lipsei de completare a unor câmpuri, eroare de salvare, eroare de încărcare a paginii, sau o eroare a sistemului? Indiferent de răspuns, această eroare intră în categoria de “Bug-uri de gestionare a erorilor’.
Pentru a elimina orice confuzii, dacă este posibil, ar trebui urmați niște pași sau un ghid de funcționare a aplicației dedicat pentru utilizatori.
Dacă aplicația cere ca anumite câmpuri să fie completate cu strictețe, înainte ca utilizatorul să salveze conținutul dintr-un chestionar, mesajele de validări ar trebui să fie respectate. Este important ca aceste mesaje să fie cat mai clare, concise și intuitive, astfel încât, orice persoană să poată folosi aplicația.
-
Bug-uri de calcule
Aceste erori de calcule pot surveni din mai multe cauze:
- Logică precară
- Formulare incorectă
- Nepotrivire de tipuri de date
- Erori de codare
- Probleme de apelări a unor funcții
La data de 23 septembrie 1999, NASA și-a pierdut sonda spațială Mars Climate Orbiter, dezvoltată pentru studiul climatului, atmosferei marțiene și schimbările de suprafață. Această pierdere s-a datorat comunicării precare dintre nava spațială și soft-ul folosit. Nava spațială s-a întâlnit cu Marte pe o traiectorie greșită, care a adus-o prea aproape de planetă și a fost distrusă în atmosferă.
Acest incident s-a întâmplat din cauza unui angajat subcontractor al NASA, care a folosit unități englezești, în loc de sistemul metric, iar software-ul nu a mai putut funcționa în parametrii normali.
-
Bug-uri de control al fluidității aplicației
Controlul fluidității aplicației descrie care sunt următorii pași precedați de anumite condiții.
De exemplu, să considerăm un sistem unde utilizatorul trebuie să completeze un formular. Opțiunile disponibile sunt: Salvează, Salvează și Închide și Renunță. Dacă utilizatorul apasă pe butonul ‘Salvează și Închide’, informațiile completate de utilizator ar trebui salvate și formularul închis. Dacă apăsând acest buton, formularul nu se închide, atunci avem o problemă de control al fluidității aplicației.
Cum să identifici și să previi bug-urile într-o aplicație?
-
Atenție la cerințele (requirements) aplicației
Un Project Manager ar fi foarte de folos în acest caz. Acesta înțelege exact necesitățile clientului și e la curent cu așteptările lui, de la produsul inițial la cel final, inclusiv la pașii principali în dezvoltarea aplicației. Aici intervine bineînțeles și echipa de dezvoltare. Există de obicei o înțelegere mutuală între Project Manager și echipa de dezvoltare, iar colaborarea între aceste părți este drumul către un succes cât mai rapid. Împreună vor da forma produsului final, exact pe gustul clientului.
Nota: Nu este necesară intervenția unui Project Manager, dar acest lucru ușurează munca programatorilor.
-
Code reviews
Indiferent cât de sigur ești de succesul aplicației tale, este recomandată revizuirea codului de către autor și un alt membru al echipei, pentru obiectivitate. Poți folosi și sugestiile noastre:
- Continuă să formatezi codul. Codul tău trebuie să fie ușor citibil și fără blocaje
- Codul trebuie să urmărească arhitectura aleasă
- Asigură-te că acel cod pe care îl scrii, este în concordanță cu următoarele:
- – Mentenanță (citibil, testabil, depanabil, configurabil)
- – Refolosibil
- – Stabil
- – Extensibil
- – Securizat
- – Performant
- – Scalabil
- – Ușor de folosit (din perspectiva clientului)
- Aplică best practices (proceduri standard utilizate pentru bunul mers), cum ar fi folosirea valorilor cât mai configurabile, scrierea de comentarii, funcționalitățile framework-ului pe cât posibil.
- Implementează principiile OOAD (Object Oriented Analysis and Design)
-
Testează, testează și iar testează
Există două modele de testare folosite în general de programatorii moderni, cum ar fi Agile și Waterfall. Aceste două modele sunt fundamental diferite, cu toate că se aplică aproape similar. Să vedem specificațiile acestora:
3.1. Structura
Agile: Testare Nestructurată cu o planificare minimală
Waterfall: Structură determinată și descriere detaliată
3.2 Potrivit aplicării pentru:
Agile: Proiecte mici
Waterfall: Orice tip de proiecte
3.3 Momentul aplicării acestor modele:
Agile: Mereu când o funcționalitate nouă este lansată, așa încât erorile pot fi fixate oricând
Waterfall: După faza de dezvoltare a codului, așa încât orice modificare să fie implementată înainte de finalizare. În caz contrar, duce la începerea proiectării inițiale.
3.4 Documentație
Agile: Puțină
Waterfall: Documentație voluminoasă disponibilă fiecărui pas
3.5 Livrarea funcționalităților
Agile: Funcționalitățile sunt livrate clienților la sfârșitul fiecărei iterații
Waterfall: Clientul trebuie să aștepte până la sfârșitul întregului proces de dezvoltare
3.6 Munca de echipă
Agile: Comunicare apropiată și constantă despre analiza requirementurilor și planificarea task-urilor, între membrii echipei (developeri și testeri)
Waterfall: Muncă independentă pentru echipe, în acest timp participarea developerilor este exclusă din procesul analizării produsului, fiind dar și niște simplii executanți
Testarea folosind metodologia Agile este un proces continuu, începând de la faza inițială a proiectului. Este implicată îndeaproape și echipa de dezvoltare, lucru care este extrem de benefic unui proiect. Cu ajutorul acestora, se poate munci pentru găsirea celei mai optime, eficiente și calitative soluții pentru implementarea întregului proces.
Varianta Waterfall în schimb, asigură o testare mai formală, respectiv o testare mai lenta și costisitoare a unui produs, foarte folositoare pentru proiectele îndelungate și complexe.
Concluzie
Identificările defectelor, categorizarea acestora, raportarea și eventual eliminarea acestor erori, sunt toate activități de control a calității. Aceste erori sunt lucruri firești și normale, precedate de erori umane, inevitabile. Testarea amănunțită este de obicei făcută de către echipa de testare (QA), pentru a stabili monitorizarea și inspectarea proceselor în fiecare stadiu/ciclu al dezvoltării software-ului.
Scopul este detectarea acestor erori, cât mai incipientă. Dacă acest lucru se efectuează de la bun început, costurile pentru găsirea și fixarea erorilor vor scădea dramatic. Acest lucru însă, este dificil pe măsură ce proiectul evoluează progresiv. Fixarea erorilor este un lucru destul de ușor de realizat în pragul stadiului de analiză, și devine tot mai costisitoare pe măsură ce fiecare stadiu este finalizat.
