De ce un raport de bug bun?

Dacă raportul dvs. de bug este eficient, atunci șansele ca acesta să fie rezolvat sunt mai mari. Așadar, rezolvarea unui bug depinde de cât de eficient îl raportați. Raportarea unui bug nu este altceva decât îndemânare și vă voi explica cum să obțineți această îndemânare.

„Scopul scrierii unui raport de probleme (raport de bug) este de a obține remedierea bug-urilor” – De Cem Kaner. Dacă un tester nu raportează corect un bug, cel mai probabil programatorul va respinge acest bug declarându-l ca fiind ireproductibil.

Acest lucru poate afecta moralul testerilor și uneori și ego-ul. (Vă sugerez să nu păstrați nici un fel de ego. Ego-uri de genul „Am raportat corect bug-ul”, „Îl pot reproduce”, „De ce a respins bug-ul?”, „Nu este vina mea” etc.,).

Care sunt calitățile unui bun raport de bug software?

Chiar oricine poate scrie un raport de bug. Dar nu oricine poate scrie un raport de Bug eficient.

Ar trebui să fiți capabil să faceți distincția între un raport de Bug mediu și un raport de Bug bun. Cum să faceți distincția între un raport de Bug bun și unul prost? Este foarte simplu, aplicați următoarele caracteristici și tehnici pentru a raporta un bug.

Caracteristicile și tehnicile includ

#1) Să aveți un număr de bug clar specificat: Atribuiți întotdeauna un număr unic fiecărui raport de eroare. Acesta, la rândul său, vă va ajuta să identificați înregistrarea bug-ului. Dacă utilizați orice instrument automatizat de raportare a bug-urilor, atunci acest număr unic va fi generat automat de fiecare dată în timp ce raportați bug-ul.

Notați numărul și o scurtă descriere a fiecărui bug pe care l-ați raportat.

#2) Să fie reproductibil: Dacă bug-ul dvs. nu este reproductibil, atunci nu va fi rezolvat niciodată.

Ar trebui să menționați clar pașii pentru a reproduce bug-ul. Nu presupuneți și nu săriți niciun pas de reproducere. Un bug care este descris pas cu pas este ușor de reprodus și de rezolvat.

#3) Fiți specific: Nu scrieți un eseu despre problemă.

Fiți specific și la obiect. Încercați să rezumați problema în minimum de cuvinte, 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 Bug eficient comunică bine cu echipa de dezvoltare și evită confuzia sau comunicarea greșită.

Un raport de Bug bun ar trebui să fie clar și concis, fără să lipsească punctele cheie. Orice lipsă de claritate duce la neînțelegeri și încetinește, de asemenea, procesul de dezvoltare. Scrierea și raportarea defectelor este una dintre cele mai importante, dar neglijate zone din ciclul de viață al testării.

O scriere bună este foarte importantă pentru depunerea unui bug. Cel mai important punct pe care un tester trebuie să îl aibă în vedere este să nu folosească un ton poruncitor în raport. Acest lucru strică moralul și creează o relație de muncă nesănătoasă. Folosiți un ton sugestiv.

Nu presupuneți că dezvoltatorul a făcut o greșeală și, prin urmare, puteți folosi cuvinte dure. Înainte de a raporta, este la fel de important să verificați dacă același bug a mai fost raportat sau nu.

Un bug duplicat este o povară în ciclul de testare. Verificați întreaga listă de bug-uri cunoscute. Uneori, este posibil ca dezvoltatorii să fi cunoscut problema și să o fi ignorat pentru o versiune viitoare. Se pot utiliza, de asemenea, instrumente precum Bugzilla, care caută automat bug-uri duplicate. Cu toate acestea, cel mai bine este să căutați manual orice bug duplicat.

Informațiile de import pe care trebuie să le comunice un raport de bug sunt „Cum?” și „Unde?”. Raportul trebuie să răspundă clar la modul în care a fost efectuat testul și unde a apărut exact defectul. Cititorul ar trebui să reproducă cu ușurință defecțiunea și să găsească unde se află.

Rețineți că obiectivul scrierii raportului de eroare este de a permite dezvoltatorului să vizualizeze problema. El/ea ar trebui să înțeleagă clar defectul din raportul de Bug. Nu uitați să oferiți toate informațiile relevante pe care dezvoltatorul le caută.

De asemenea, țineți cont de faptul că un raport de eroare va fi păstrat pentru utilizare viitoare și ar trebui să fie bine scris cu informațiile necesare. Folosiți propoziții semnificative și cuvinte simple pentru a vă descrie bug-urile. Nu folosiți afirmații confuze care irosesc timpul evaluatorului.

Raportați fiecare bug ca o problemă separată. În cazul în care există mai multe probleme într-un singur raport de Bug, nu îl puteți închide decât dacă toate problemele sunt rezolvate.

De aceea, este mai bine să împărțiți problemele în bug-uri separate. Acest lucru asigură faptul că fiecare bug 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 se raportează un bug?

Utilizați următorul model simplu de raport de bug:

Acesta este un format simplu de raport de bug. Acesta poate varia în funcție de instrumentul de raportare a Bug-urilor pe care îl utilizați. Dacă scrieți manual un raport de eroare, atunci unele câmpuri trebuie menționate în mod specific, cum ar fi numărul de eroare, care trebuie atribuit manual.

Reporter: Numele și adresa dvs. de e-mail.

Produs: În ce produs ați găsit acest bug.

Version: Versiunea produsului, dacă există.

Component: Acestea sunt submodulele majore ale produsului.

Platformă: Menționați platforma hardware pe care ați găsit această eroare. Diferite platforme, cum ar fi ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Sistem de operare: Menționați toate sistemele de operare în care ați găsit acest bug. Sisteme de operare precum Windows, Linux, Unix, SunOS, Mac OS. Menționați și diferitele versiuni ale sistemului de operare, cum ar fi Windows NT, Windows 2000, Windows XP etc., dacă este cazul.

Prioritate: Când ar trebui să fie rezolvată o eroare? Prioritatea este stabilită, în general, de la P1 la P5. P1 ca fiind „reparați bug-ul cu cea mai mare prioritate”, iar P5 ca fiind ” Remediați când timpul permite”.

Severitate: Aceasta descrie impactul bug-ului.
Tipuri de gravitate:

• Blocaj: Nu se pot face alte lucrări de testare.
• Critic: Prăbușirea aplicației, pierdere de date.
• Major: Pierdere majoră de funcție.
• Minor: Pierdere minoră de funcție.
• Trivial: Unele îmbunătățiri ale interfeței de utilizare.
• Îmbunătățire: Cerere pentru o nouă funcție sau unele îmbunătățiri ale celei existente.

Status: Atunci când înregistrați bug-ul în orice sistem de urmărire a bug-urilor, atunci, în mod implicit, statutul bug-ului va fi „Nou”.
Ulterior, bug-ul trece prin diferite etape, cum ar fi Fixed, Verified, Reopen, Won’t Fix, etc.

=> Faceți clic aici pentru a citi mai multe despre Ciclul de viață detaliat al bug-urilor.

Assign To: Dacă știți ce dezvoltator este responsabil pentru modulul respectiv în care a apărut bug-ul, atunci puteți specifica adresa de e-mail a acelui dezvoltator. În caz contrar, păstrați-l necompletat, deoarece astfel bug-ul va fi atribuit proprietarului modulului, în caz contrar Managerul va atribui bug-ul dezvoltatorului. Eventual, adăugați adresa de e-mail a managerului în lista CC.

URL: URL-ul paginii pe care a apărut bug-ul.

Summary: Un scurt rezumat al bug-ului, de cele mai multe ori în 60 de cuvinte sau mai puțin. Asigurați-vă că rezumatul dvs. reflectă care este problema și unde se află.

Descriere: O descriere detaliată a bug-ului.

Utilizați următoarele câmpuri pentru câmpul de descriere:

• Reproduceți pașii: În mod clar, menționați pașii de reproducere a erorii.
• Rezultat așteptat: Cum ar trebui să se comporte aplicația la pașii menționați mai sus.
• Rezultat real: Care este rezultatul real al rulării pașilor de mai sus, adică comportamentul bug-ului.

Aceștia sunt pașii importanți în raportul de bug. De asemenea, puteți adăuga „Report type” (Tipul raportului) ca încă un câmp care va descrie tipul de eroare.

Tipurile de raport includ:

1) Eroare de codare
2) Eroare de proiectare
3) Sugestie nouă
4) Problemă de documentație
5) Problemă hardware

Caracteristici importante în raportul dvs. de eroare

Datele de mai jos sunt caracteristicile importante în raportul de eroare:

#1) Numărul/identificarea bug-ului

Un număr de bug sau un număr de identificare (cum ar fi swb001) facilitează foarte mult raportarea și referirea la un bug. Dezvoltatorul poate verifica cu ușurință dacă un anumit bug a fost rezolvat sau nu. Acesta face ca întregul proces de testare și retestare să fie mai ușor și mai lin și mai ușor.

#2) Titlul bug-ului

Un titlu al bug-ului este citit mai des decât orice altă parte a raportului de bug. Acesta ar trebui să spună totul despre ceea ce vine în bug.

Titlul bug-ului ar trebui să fie suficient de sugestiv pentru ca cititorul să îl poată înțelege. Un titlu clar al bug-ului îl face ușor de înțeles și cititorul poate ști dacă bug-ul a fost raportat anterior sau a fost rezolvat.

#3) Prioritate

În funcție de gravitatea bug-ului, se poate stabili o prioritate pentru acesta. Un bug poate fi un Blocker, Critical, Major, Minor, Trivial sau o sugestie. Se poate da o prioritate a bug-urilor de la P1 la P5, astfel încât cele importante să fie vizualizate mai întâi.

#4) Platformă/Mediu

Configurarea sistemului de operare și a browser-ului este necesară pentru o raportare clară a bug-urilor. Este cel mai bun mod de a comunica modul în care poate fi reprodus bug-ul.

Fără platforma sau mediul exact, aplicația se poate comporta diferit și este posibil ca bug-ul de la partea testerului să nu se reproducă la partea dezvoltatorului. Așadar, cel mai bine este să menționați clar mediul în care a fost detectat bug-ul.

#5) Descriere

Descrierea bug-ului îl ajută pe dezvoltator să înțeleagă bug-ul. Ea descrie problema întâlnită. Descrierea necorespunzătoare va crea confuzie și va face să se piardă timpul dezvoltatorilor, dar și al testerilor.

Este necesar să se comunice clar despre efectul descrierii. Este întotdeauna util să folosiți propoziții complete. Este o bună practică să descrieți fiecare problemă în parte, în loc să le fărâmițați împreună. Nu folosiți termeni de genul „cred” sau „cred”.

#6) Pași de reproducere

Un raport de eroare bun trebuie să menționeze clar pașii de reproducere. Pașii ar trebui să includă acțiunile care cauzează bug-ul. 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.
• Click pe Add to cart.
• Clic pe Remove pentru a elimina produsul din coș.

#7) Rezultatul așteptat și cel real

Descrierea unui bug este incompletă fără rezultatele așteptate și cele reale. Este necesar să se sublinieze care este rezultatul testului și la ce trebuie să se aștepte utilizatorul. Cititorul trebuie să știe care este rezultatul corect al testului. Menționați în mod clar ce s-a întâmplat în timpul testului și care a fost rezultatul.

#8) Captură de ecran

O imagine face cât o mie de cuvinte. Faceți o captură de ecran a instanței de eșec cu legendele corespunzătoare pentru a evidenția defectul. Evidențiați mesajele de eroare neașteptate cu culoarea roșu deschis. Acest lucru atrage atenția asupra zonei necesare.

Câteva sfaturi suplimentare pentru a scrie un raport de eroare bun

Date mai jos sunt câteva sfaturi suplimentare pentru a scrie un raport de eroare bun:

#1) Raportați problema imediat

Dacă găsiți orice eroare în timpul testării, atunci nu trebuie să așteptați să scrieți un raport de eroare detaliat mai târziu. În schimb, scrieți imediat raportul de eroare. Acest lucru va asigura un raport de eroare bun și reproductibil. Dacă vă decideți să scrieți raportul de Bug mai târziu, atunci sunt șanse mari să omiteți pașii importanți din raportul dumneavoastră.

#2) Reproduceți bug-ul de trei ori înainte de a scrie un raport de Bug

Bug-ul dumneavoastră trebuie să fie reproductibil. Asigură-te că pașii tăi sunt suficient de solizi pentru a reproduce bug-ul fără nicio ambiguitate. Dacă bug-ul dvs. nu este reproductibil de fiecare dată, puteți totuși să depuneți un bug menționând natura periodică a bug-ului.

#3) Testați apariția aceluiași bug pe alte module similare

Câteodată dezvoltatorul folosește același cod pentru diferite module similare. Astfel, există șanse mai mari ca bug-ul dintr-un modul să apară și în alte module similare. Puteți chiar să încercați să găsiți versiunea mai severă a bug-ului pe care l-ați găsit.

#4) Scrieți un rezumat bun al bug-ului

Rezumatul bug-ului îi va ajuta pe dezvoltatori să analizeze rapid natura bug-ului. Un raport de slabă calitate va crește inutil timpul de dezvoltare și testare. Comunicați bine cu rezumatul raportului de eroare. Rețineți că rezumatul bug-ului este folosit ca referință pentru a căuta bug-ul în inventarul de bug-uri.

#5) Citiți raportul de eroare înainte de a apăsa butonul Submit

Citiți toate propozițiile, formulările și pașii care sunt utilizați în raportul de eroare. Vedeți dacă vreo propoziție creează o ambiguitate care poate duce la interpretări greșite. Cuvintele sau propozițiile înșelătoare trebuie evitate pentru a avea un raport de eroare clar.

#6) Nu folosiți un limbaj abuziv

Este frumos că ați făcut o 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ă.

Concluzie

Nu există niciun dubiu că raportul dvs. de eroare ar trebui să fie un document de înaltă calitate.

Concentrează-te pe scrierea unor rapoarte de eroare bune și dedică ceva timp acestei sarcini, deoarece acesta este principalul punct de comunicare între tester, dezvoltator și manager. Managerii ar trebui să conștientizeze echipa lor că scrierea unui raport de bug bun este principala responsabilitate a oricărui tester.

.