how write good bug report
De ce bun raport de erori?
Dacă raportul Bug este eficient, atunci șansele sale de a fi remediate sunt mai mari. Deci, remedierea unui bug depinde de cât de eficient îl raportați. Raportarea unei erori nu este altceva decât abilitate și vă voi explica cum să obțineți această abilitate.
„Scopul scrierii raportului de problemă (raport de erori) este de a rezolva erorile” - De Cem Kaner. Dacă un tester nu raportează corect un bug, programatorul va respinge cel mai probabil acest bug, declarându-l ca fiind irecuperabil.
Acest lucru poate afecta moralul testerilor și uneori și ego-ul. (Vă sugerez să nu păstrați niciun tip de ego. Ego-ul este de genul „Am raportat corect eroarea”, „Pot să-l reproduc”, „De ce a respins bug-ul?”, „Nu este vina mea” etc. ,).
Ce veți învăța:
- Care sunt calitățile unui bun raport de eroare software?
- Raportarea eficientă a erorilor
- Cum să raportați o eroare?
- Caracteristici importante în raportul dvs. de eroare
- Câteva sfaturi bonus pentru a scrie un raport bun de eroare
- Concluzie
- Lectură recomandată
Care sunt calitățile unui bun raport de eroare software?
Oricine poate scrie un raport Bug. Dar nu toată lumea poate scrie un raport de eroare eficient.
Ar trebui să puteți face distincția între un raport mediu de eroare și un raport bun de eroare. Cum se face distincția între un raport de erori bun și rău? Este foarte simplu, aplicați următoarele caracteristici și tehnici pentru a raporta o eroare.
Caracteristicile și tehnicile includ
# 1) Având un număr de bug clar specificat: Alocați întotdeauna un număr unic fiecărui raport de eroare. La rândul său, acest lucru vă va ajuta să identificați înregistrarea erorilor. Dacă utilizați orice instrument automat de raportare a erorilor, acest număr unic va fi generat automat de fiecare dată când raportați eroarea.
Rețineți numărul și o scurtă descriere a fiecărui bug pe care l-ați raportat.
# 2) Reproductibil: Dacă bug-ul dvs. nu este reproductibil, atunci nu va fi reparat niciodată.
Ar trebui să menționați în mod clar pașii pentru a reproduce eroarea. Nu presupuneți și nu omiteți nicio etapă de reproducere. O eroare descrisă pas cu pas este ușor de reprodus și de remediat.
# 3) Fiți specific: Nu scrieți un eseu despre problemă.
Fii specific și la obiect. Încercați să rezumați problema în cuvinte minime, dar într-un mod eficient. Nu combinați mai multe probleme chiar dacă acestea par a fi similare. Scrieți rapoarte diferite pentru fiecare problemă.
Raportarea eficientă a erorilor
Raportarea erorilor este un aspect important al testării software. Un raport de eroare eficient comunică bine cu echipa de dezvoltare și evită confuzia sau comunicarea greșită.
Un bun raport Bug ar trebui să fie clar și concis fără niciun punct cheie lipsă. Orice lipsă de claritate duce la neînțelegere și încetinește și procesul de dezvoltare. Scrierea și raportarea defectelor este una dintre cele mai importante, dar neglijate domenii din ciclul de viață al testării.
Scrierea bună este foarte importantă pentru depunerea unei erori. Cel mai important punct pe care un tester ar trebui să-l țină cont este să nu folosească un ton comandant în raport. Acest lucru rupe moralul și creează o relație de muncă nesănătoasă. Folosiți un ton sugestiv.
Nu presupune că dezvoltatorul a făcut o greșeală și, prin urmare, puteți folosi cuvinte dure. Înainte de raportare, este la fel de important să verificați dacă aceeași eroare a fost raportată sau nu.
O eroare duplicat este o povară în ciclul de testare. Verificați întreaga listă de erori cunoscute. Uneori, este posibil ca dezvoltatorii să fi cunoscut problema și să fi ignorat pentru o versiune viitoare. Pot fi folosite și instrumente precum Bugzilla care caută automat erori duplicate. Cu toate acestea, cel mai bine este să căutați manual orice eroare duplicat.
Informațiile de import pe care trebuie să le comunice un raport de erori sunt 'Cum?' si unde?' Raportul trebuie să răspundă în mod clar la modul în care a fost efectuat testul și unde a apărut exact defectul. Cititorul ar trebui să reproducă cu ușurință eroarea și să găsească unde este eroarea.
Rețineți că obiectivul scrierii raportului Bug este de a permite dezvoltatorului să vizualizeze problema. El / Ea ar trebui să înțeleagă în mod clar defectul din raportul Bug. Nu uitați să furnizați toate informațiile relevante pe care dezvoltatorul le caută.
comanda cut în unix cu exemple
De asemenea, rețineți că un raport de erori ar fi păstrat pentru o utilizare viitoare și ar trebui să fie bine scris cu informațiile solicitate. Folosiți propoziții semnificative și cuvinte simple pentru a vă descrie bug-urile. Nu utilizați declarații confuze care irosesc timpul examinatorului.
Raportați fiecare eroare ca o problemă separată. În cazul apariției mai multor probleme într-un singur raport de eroare, nu îl puteți închide decât dacă toate problemele sunt rezolvate.
Prin urmare, este mai bine să împărțiți problemele în bug-uri separate . Acest lucru asigură faptul că fiecare eroare poate fi tratată separat. Un raport de eroare bine scris ajută un dezvoltator să reproducă eroarea la terminalul său. Acest lucru îi ajută să diagnosticheze și problema.
Cum să raportați o eroare?
Utilizați următorul șablon de raport de erori simplu:
Acesta este un format simplu de raportare Bug. Poate varia în funcție de instrumentul de raportare a erorilor pe care îl utilizați. Dacă scrieți manual un raport de eroare, unele câmpuri trebuie menționate în mod special, cum ar fi numărul de eroare, care ar trebui să fie atribuit manual.
Reporter: Numele și adresa de e-mail.
Produs: În ce produs ați găsit această eroare.
Versiune: Versiunea produsului, dacă există.
Componenta: Acestea sunt principalele sub-module ale produsului.
Platformă: Menționați platforma hardware unde ați găsit această eroare. Diferitele platforme precum „PC”, „MAC”, „HP”, „Sun” etc.
Sistem de operare: Menționează toate sistemele de operare în care ai găsit eroarea. Sisteme de operare precum Windows, Linux, Unix, SunOS, Mac OS. Menționați diferitele versiuni ale sistemului de operare precum Windows NT, Windows 2000, Windows XP etc., dacă este cazul.
Prioritate: Când trebuie remediată o eroare? Prioritatea este stabilită în general de la P1 la P5. P1 ca „remediați eroarea cu cea mai mare prioritate” și P5 ca „Remediați când timpul permite”.
Severitate: Aceasta descrie impactul bug-ului.
Tipuri de severitate:
diferența dintre serverul client și aplicația bazată pe web
- Blocant: Nu se mai poate face nicio lucrare de testare.
- Critic: Blocarea aplicației, Pierderea datelor.
- Major: Pierderea majoră a funcției.
- Minor: Pierderea minoră a funcției.
- Banal: Unele îmbunătățiri ale UI.
- Sporire: Solicitare pentru o nouă caracteristică sau unele îmbunătățiri în cea existentă.
Stare: Când conectați eroarea la orice sistem de urmărire a erorilor, în mod implicit, starea erorii va fi „Nou”.
Mai târziu, eroarea trece prin diferite etape, cum ar fi Fixed, Verified, Redeschidere, Won’t Fix etc.
=> Click aici pentru a citi mai multe despre ciclul de viață detaliat al erorilor.
Atribuiți la: Dacă știți care dezvoltator este responsabil pentru acel modul în care a apărut eroarea, puteți specifica adresa de e-mail a dezvoltatorului respectiv. Altfel, păstrați-l necompletat, deoarece acest lucru va atribui eroarea proprietarului modulului, dacă nu Managerul va atribui eroarea dezvoltatorului. Este posibil să adăugați adresa de e-mail a managerului în lista CC.
URL: Adresa URL a paginii pe care a apărut eroarea.
Rezumat: Un scurt rezumat al erorii, în special în 60 de cuvinte sau mai jos. Asigurați-vă că rezumatul dvs. reflectă care este problema și unde se află.
Descriere: O descriere detaliată a erorii.
Utilizați următoarele câmpuri pentru câmpul de descriere:
- Reproduceți pașii: În mod clar, menționați pașii pentru a reproduce eroarea.
- Rezultat asteptat: Cum ar trebui să se comporte aplicația la pașii menționați mai sus.
- Rezultat actual: Care este rezultatul real al executării pașilor de mai sus, adică comportamentul bug-ului.
Aceștia sunt pașii importanți din raportul de erori. De asemenea, puteți adăuga „Tip raport” ca încă un câmp care va descrie tipul de eroare.
Tipurile de rapoarte includ:
1) Eroare de codare
2) Eroare de proiectare
3) Sugestie nouă
4) Problemă de documentare
5) Problemă hardware
Caracteristici importante în raportul dvs. de eroare
Mai jos sunt prezentate caracteristicile importante din raportul Bug:
# 1) Număr de eroare / ID
Un număr de eroare sau un număr de identificare (cum ar fi swb001) facilitează mult raportarea erorilor și trimiterea la eroare. Dezvoltatorul poate verifica cu ușurință dacă un anumit bug a fost rezolvat sau nu. Face întregul proces de testare și retestare mai ușor și mai ușor.
# 2) Titlul erorii
Un titlu de eroare este citit mai des decât orice altă parte a raportului de eroare. Ar trebui să spună totul despre ceea ce vine în bug.
Titlul Bug-ului ar trebui să fie suficient de sugestiv încât cititorul să îl poată înțelege. Un titlu clar de eroare îl face ușor de înțeles și cititorul poate ști dacă eroarea a fost raportată mai devreme sau a fost remediată.
# 3) Prioritate
Pe baza severității bug-ului, se poate seta o prioritate pentru acesta. O eroare poate fi un blocant, critic, major, minor, banal sau o sugestie. O prioritate de eroare de la P1 la P5 poate fi dată, astfel încât cele mai importante să fie vizualizate mai întâi.
# 4) Platformă / mediu
Configurarea sistemului de operare și a browserului este necesară pentru un raport de eroare clar. Este cel mai bun mod de a comunica modul în care bug-ul poate fi reprodus.
Fără platforma sau mediul exact, aplicația se poate comporta diferit, iar eroarea de la capătul testerului nu se poate reproduce la capătul dezvoltatorului. Deci, cel mai bine este să menționăm clar mediul în care a fost detectat bug-ul.
# 5) Descriere
Descrierea erorilor îl ajută pe dezvoltator să înțeleagă eroarea. Descrie problema întâmpinată. Descrierea slabă va crea confuzie și va pierde timpul și dezvoltatorilor și testerilor.
Este necesar să comunicați clar despre efectul descrierii. Este întotdeauna util să folosiți propoziții complete. Este o practică bună să descrieți fiecare problemă separat, în loc să le sfărâmați complet. Nu folosiți termeni precum „Cred” sau „Cred”.
# 6) Pași pentru reproducere
Un bun raport Bug trebuie să menționeze în mod clar pașii de reprodus. Pașii ar trebui să includă acțiuni care cauzează eroarea. Nu faceți declarații generice. Fiți specific în pașii de urmat.
Un bun exemplu de procedură bine scrisă este dat mai jos
Pași:
- Selectați produsul Abc01.
- Faceți clic pe Adăugați în coș.
- Faceți clic pe Eliminare pentru a scoate produsul din coș.
# 7) Rezultat așteptat și efectiv
O descriere a erorilor este incompletă fără rezultatele așteptate și reale. Este necesar să se sublinieze care este rezultatul testului și la ce ar trebui să se aștepte utilizatorul. Cititorul ar trebui să știe care este rezultatul corect al testului. În mod clar, menționați ce s-a întâmplat în timpul testului și care a fost rezultatul.
# 8) Captură de ecran
O imagine valorează o mie de cuvinte. Faceți o captură de ecran a cazului de eșec cu subtitrări corespunzătoare pentru a evidenția defectul. Evidențiați mesajele de eroare neașteptate cu culoare roșu deschis. Acest lucru atrage atenția asupra zonei solicitate.
Câteva sfaturi bonus pentru a scrie un raport bun de eroare
Mai jos sunt câteva sfaturi suplimentare pentru a scrie un bun raport de erori:
# 1) Raportați problema imediat
Dacă găsiți vreo eroare în timpul testării, atunci nu trebuie să așteptați să scrieți un raport de erori mai târziu. În schimb, scrieți imediat raportul de erori. Acest lucru va asigura un raport de eroare bun și reproductibil. Dacă decideți să scrieți raportul Bug mai târziu, atunci există șanse mari să ratați pașii importanți din raport.
# 2) Reproduceți eroarea de trei ori înainte de a scrie un raport de eroare
Bug-ul dvs. ar trebui să fie reproductibil. Asigurați-vă că pașii dvs. sunt suficient de solizi pentru a reproduce eroarea fără nicio ambiguitate. Dacă bug-ul dvs. nu este reproductibil de fiecare dată, puteți totuși să înregistrați un bug menționând natura periodică a acestuia.
# 3) Testați aceeași apariție de erori pe alte module similare
Uneori dezvoltatorul folosește același cod pentru diferite module similare. Deci, există șanse mai mari ca bug-ul dintr-un modul să apară și în alte module similare. Puteți încerca chiar să găsiți versiunea mai severă a bug-ului pe care l-ați găsit.
# 4) Scrieți un rezumat bun al erorilor
Rezumatul erorilor îi va ajuta pe dezvoltatori să analizeze rapid natura erorilor. Un raport de calitate slabă va crește inutil timpul de dezvoltare și testare. Comunicați bine cu rezumatul raportului de eroare. Rețineți că rezumatul erorilor este folosit ca referință pentru a căuta eroarea în inventarul erorilor.
# 5) Citiți raportul Bug înainte de a apăsa butonul Trimiteți
Citiți toate propozițiile, formulările și pașii utilizați în raportul de eroare. Vedeți dacă vreo frază creează ambiguitate care poate duce la o interpretare greșită. Cuvintele sau propozițiile înșelătoare ar trebui evitate pentru a avea un raport de eroare clar.
# 6) Nu utilizați limbaj abuziv
Este plăcut că ați făcut treabă bună și ați găsit o eroare, dar nu folosiți acest credit pentru a critica dezvoltatorul sau pentru a ataca orice persoană.
cum se deschid fișiere jar cu java
Concluzie
Fără îndoială că raportul dvs. de erori ar trebui să fie un document de înaltă calitate.
Concentrați-vă pe scrierea unor rapoarte de erori bune și petreceți ceva timp în această sarcină, deoarece acesta este principalul punct de comunicare dintre tester, dezvoltator și manager. Managerii ar trebui să creeze o conștientizare a echipei lor că redactarea unui bun raport Bug este responsabilitatea principală a oricărui tester.
Efortul dvs. de a scrie un raport de eroare bun nu numai că va economisi resursele companiei, ci va crea și o relație bună între dvs. și dezvoltatori.
Pentru o productivitate mai bună, scrieți un raport Bug mai bun.
Sunteți un expert în redactarea unui raport Bug? Simțiți-vă liber să ne împărtășiți gândurile în secțiunea de comentarii de mai jos.
Lectură recomandată
- Exemplu de raport de erori
- Cum să găsiți o eroare în aplicație? Sfaturi și trucuri
- Cum se scrie un raport săptămânal de testare a software-ului
- Ce este ciclul de viață al defectelor / erorilor în testarea software-ului? Tutorial privind ciclul de viață al defectelor
- Cum să vă rezolvați toate erorile fără eticheta „Eroare nevalidă”?
- Exemple de rapoarte de erori pentru aplicații web și produse
- Cum se scrie un raport sumar eficient al testului [Descărcare exemplu de raport]
- De ce raportarea erorilor este o artă care ar trebui învățată de fiecare tester?