În acest tutorial, voi explica:
- Ce este un bug?
- De ce să raportezi un bug?
- Cum poți raporta în mod eficient un bug?
Pe scurt, un bug este o eroare de software, defecțiune sau greșeală de proiectare, în dezvoltarea sau funcționarea software-ului de calculator care îl face să producă un rezultat incorect sau neașteptat sau să se comporte în moduri neintenționate.
Fie că folosești un software în interes personal, sau vrei să participi la o campanie Beta a unui produs sau chiar te angajezi ca tester este important să raportezi erorile descoperite către dezvoltator pentru ca acesta să poată să le corecteze.
Raportarea erorilor demonstrează o problemă de dezvoltare și oferă dezvoltatorilor un punct de plecare în procesul de remediere. Scrierea unui raport de 10 pagini despre ceea ce descoperiți poate fi tentant, dar cu cât raportul dumneavoastră de eroare este mai simplu și mai succint, cu atât va fi mai bine pe termen lung.
De-a lungul timpului am participat la mai multe campanii Beta, din pură pasiune, printre care pot enumera BitDefender Internet Security, Microsoft Windows 10 sau Xbox OS. De asemenea, am avut ocazia să lucrez în cadrul a două companii ca tester, unde am învățat cel mai eficient mod de a raporta un bug.
Structura unui Bug report
Un raport trebuie să fie scris în engleză și să aibă o structură similară cu cea de mai jos:
- [Feature Name] Title
- Environment
- Steps to reproduce
- Expected Result
- Actual Result
- Visual Proof (screenshots, videos, text)
- Severity/Priority
- Workaround
[Feature Name] Title
Titlul ar trebui să servească ca un rezumat concis al erorii. Titlurile rapoartelor încep cu problema principală a caracteristicilor dintre paranteze chiar la începutul titlului.
Sfat: Vă recomand să revizuiți din nou titlul după completarea raportului pentru a vă asigura că este concis și reflectă problema.
Environment
Mediul pentru fiecare aplicație poate varia foarte mult, dar fiți cât se poate de specific. Testerii ar trebui să urmeze întotdeauna șablonul de raport de eroare dat, dacă nu se specifică altfel – ajută la reducerea informațiilor inutile.
- Device: Ce tip de hardware folosesti? Ce model anume?
- OS: Pe ce versiune de sistem de operare s-a produs eroarea?
- Account Used: Acest lucru contează dacă testerii primesc conturi de test de către client. Când dezvoltatorii primesc eroarea, știu ce cont a fost folosit pentru a descoperi problema.
- Testing App Version: Ce versiune a aplicației testați? Nu va fi suficient să scrieți „cea mai recentă versiune”.
- Connection type (dacă este cazul): Dacă aplicația pe care o testați se bazează pe conexiunea la internet, specificați dacă sunteți pe WiFi, Ethernet sau date celulare? Care este viteza conexiunii?
- Reproducibility Rate: De câte ori ați reușit să reproduceți eroarea, folosind exact pașii pe care i-ați făcut pentru a activa eroarea? De asemenea, este util să raportați cât de des a fost reprodusă eroarea față de numărul de încercări efectuate pentru a reproduce problema, în cazul unei apariții intermitente.
Steps to Reproduce
Este important să descrii pas cu pas fiecare lucru pe care l-ați făcut pentru a produce eroarea, astfel încât dezvoltatorul să poată cu ușurință să reproducă eroarea.
Expected Result
După ce ați enumerat pașii pentru reproducerea erorii, specificați ceea ce ar fi trebuit să se întâmple după parcurgerea acestor pași.
Actual Result
Acum descrieți Bug-ul:
- Aplicația se blochează?
- Nu se întâmplă absolut nimic?
- Este afișată o eroare?
Este important să oferiți câteva informații pentru a ”izola” problema pentru a face raportul de eroare mai ușor de remediat. – „Butonul nu funcționează așa cum era de așteptat” nu este de ajutor, întrucât „Butonul închide aplicația pe diferite platforme, diferite versiuni de sistem de operare sau diferite dimensiuni de ecran” oferă dezvoltatorilor o perspectivă mult mai bună asupra problemei. De asemenea, le oferă detalii suplimentare pentru a ajuta la începerea investigației.
Visual Proof
Orice captură de ecran, videoclipuri sau fișiere jurnal pertinente ar trebui să fie atașate. Rapoartele de erori necesită de obicei atât un videoclip, cât și o captură de ecran, în funcție de natura problemei. Dacă problema necesită pași pentru a declanșa eroarea, atunci este necesar un videoclip. Dacă eroarea este, să zicem, o problemă minoră a UI care este întotdeauna prezentă, atunci o captură de ecran va fi suficientă. Jurnalele sunt, de asemenea, necesare indiferent de problemă.
Pentru blocările aplicațiilor, avem nevoie atât de jurnalele de sistem, cât și de jurnal de blocare, în caz contrar, dezvoltatorii rămân în căutarea unui ac într-un car de fân, iar acest lucru le economisește timp prețios.
Severity/Priority
Partajarea severității oferă un grad de impact pe care bug-ul îl are asupra funcționalității sistemului și ajută echipa de dezvoltare să-și prioritizeze munca. Este recomandat să utilizați una dintre cele trei categorii de severitate în raportul dumneavoastră de eroare:
- High/Critical: orice afectează fluxul normal de utilizare sau blochează folosirea software-ului
- Medium: orice afectează negativ experiența utilizatorului
- Minor: restul (de exemplu, greșeli de scriere, pictograme lipsă, probleme de aspect etc.)
Workaround
În cazul în care există o altă cale prin care se poate evita problema semnalată, este bine să o menționați, astfel încât dezvoltatorul să își facă o idee despre motivele care ar declanșa bug-ul.
În plus, această informație coroborată cu gradul de severitate al bug-ului ajută la prioritizarea rezolvării erorii precum și la evaluarea costurilor de remediere a bug-ului.