How to Write a Bug Report with Examples

Ce este Bug Report? De ce aveți nevoie de un raport bun de eroare?

Raportul de eroare este un document important în STLC care oferă diverse avantaje echipei de testare. Acesta menține track din toate defectele, erorile multiple, erorile și alte discrepanțe găsite în timpul testării software-ului și le raportează.

Scopul acestei documentații post-testare este de a oferi informații echipei de profesioniști în cauză despre nivelul erorilor întâlnite în timpul procesului de testare.

Ta inginer de dezvoltare software can be made aware of all the defects and issues present in the software using this type of report. It also lets you figure out what is wrong with a bug, so you can use the best method to fix it. It also helps you to save your time and money by helping prinzi erori și probleme.

De ce ar trebui să vă pese de explicațiile bune pentru erori?

Iată punctul pe care trebuie să îl luați în considerare pentru a scrie un raport de eroare software bun și detaliat:

• Acționează ca un ghid pentru a ajuta la evitarea aceleiași erori în versiunile viitoare.
• Economisiți timp pentru comunicare (e-mailuri, apeluri).
• Less lucrează pentru dezvoltatori (vor face exact ce vrei tu).
• Veți avea mai puține blocaje în proiect; erorile vor fi remediate mai rapid și mai eficient.
• Modern teams using Jira, Linear, or Azure DevOps can also link bug reports to sprint tickets and release pipelines, ensuring traceability across QA and DevOps workflows.

Cum se scrie un raport de eroare (Șablon de raport de eroare)

Nu există un șablon exact de raportare a erorilor, deoarece depinde de tipul de eroare pe care o utilizați.tracsistem rege. Șablonul dvs. ar putea fi diferit.

Cu toate acestea, următoarele câmpuri comune sunt întotdeauna necesare atunci când doriți să scrieți un raport de eroare:

• Id-ul erorii/Titlu.
• Severitate și prioritate.
• Descriere
• Mediu inconjurator
• Pasi pentru reproducere.
• Rezultat asteptat.
• Rezultat actual.
• Atașamente (capturi de ecran, videoclipuri, text)

Let us look at all these bug-tracking components one by one:

1) Titlu/ID eroare:

Fiecare bug ar trebui să primească un număr unic de identificare. Instrumentele de raportare a erorilor ar trebui să fie numere unice pentru erorile nou apărute, astfel încât să putem identifica cu ușurință eroarea.

Exemple:

❌ Rău: „Nu pot vedea produsul când din nou, tyrp nu îl vede.”

• Vag
• Agresiv
• Prea pronunțat

solicită implementarea unei soluții.

✅ Bine: „CART – Articole noi adăugate în coș care nu apar”.

• Acest tip de titlu localizează instantaneu problema (CART)
• Se concentrează pe problema tehnică reală.

2) Severitatea erorii:

Severitatea erorilor este un factor foarte important în raportul de erori. Descrie efectul defectului asupra performanței aplicației.

• Blocante: Această eroare face ca aplicația să eșueze.
• majore: O eroare critică indică o schimbare majoră în logica afacerii.
• Minor: O problemă care nu afectează funcționalitatea aplicației, dar afectează rezultatele așteptate.
• Banal: Nu afectează funcționalitatea sau funcționarea aplicației. Ar putea fi o greșeală de tipar.

3) Prioritatea erorilor:

Următoarea este gradația generală pentru a decide prioritatea erorilor:

• Mare: Acoperă orice afectează fluxul sau blochează utilizarea aplicației.
• Mediu: Afectează negativ experiența utilizatorului.
• Minor: Toate celelalte erori, cum ar fi (greșeli de scriere, pictograme lipsă, probleme de aspect etc.).

4) Mediu:

Un bug poate apărea într-un anumit mediu și nu în alții. De exemplu, uneori apare o eroare când rulați site-ul web Firefox, sau o defecțiune a aplicației numai atunci când rulează pe un Android dispozitiv și funcționează bine pe iPhone.

Aceste rapoarte de eroare pot fi identificate numai prin testare între browsere sau între dispozitive. Deci, atunci când raportează eroarea, QA-urile ar trebui să poată specifica dacă eroarea trebuie observată într-unul sau mai multe medii specifice.

5) Rezumat:

However, adding only the Title in the bug report does not serve the purpose. So, if your Title is not enough, you can add a short report summary.

Rezumatul dvs. în cât mai puține cuvinte posibil, inclusiv când și cum a apărut eroarea. Titlul și descrierea erorii ar trebui să fie, de asemenea, folosite în căutări, așa că trebuie să vă asigurați că ați acoperit cuvinte cheie importante.

Exemple:

• Rău: „Încercam să adaug lucruri la test și nu a apărut nimic când am făcut asta sau când am făcut clic pe buton.”
• Bun: „Când am încercat să adaug [PRODUS] în magazinping coș, dar nu s-a întâmplat nimic când am dat clic pe butonul „adăugați” de pe pagina web cu prezentarea generală a produsului specific.”

6) Pași pentru reproducere:

When reporting a bug, it is important to specify the steps to reproduce it. You should also include actions that may cause the bug. Here, do not make any generic statements.

Fii specific cu privire la pașii de urmat:

Iată un exemplu de procedură bine scrisă:

Pași:

1. Selectați produsul X1.
2. Faceți clic pe Adaugă în coș.
3. Faceți clic pe Eliminare pentru a elimina produsul din coș.

7) Rezultatul așteptat:

În rapoartele de erori, este importantă descrierea rezultatului așteptat în funcție de sarcina tehnică, proiectarea rezultatelor cazului de testare sau în funcție de opinia testatorului. Toate acestea îi ajută pe dezvoltatori să se concentreze pe găsirea rapidă a informațiilor necesare.

De exemplu:

Câmpurile obligatorii trebuie evidențiate cu roșu după ce faceți clic pe butonul „Trimite”.

8) Rezultatul real:

După cum sugerează și numele, acest câmp descrie efectul real al bug-ului. Este foarte important să scrieți o descriere clară a rezultatului real.

De exemplu:

Câmpurile obligatorii sunt evidențiate cu culoarea verde după ce faceți clic pe butonul „Trimite”.

9) Atașamente (capturi de ecran și videoclipuri):

În rapoartele de erori, cea mai bună practică este să atașați fișiere la rapoartele de erori, ceea ce face mai ușor să percepeți informațiile atunci când trebuie să le afișați vizual:

De exemplu:

• Captură: Capturile de ecran pot elabora cu ușurință greșeli în program; este convenabil când bug-ul este evidențiat cu o anumită adnotare, cerc sau imagine cu săgeată).
• Video: Sometimes, it is difficult to describe the bug in words, so it is better to create a video so that developer can rectify the defect in the program).

10) Versiunea afectată:

Este versiunea de software afectată în care este raportată eroarea.

11) Versiune corectă:

Este versiunea de software în care eroarea este rezolvată. Deci, atunci când QA care a raportat eroarea, verifică dacă este remediată, el folosește versiunea corectă a software-ului.

12) Target versiune:

Versiunea țintă în care ar trebui să fie vizată o eroare pentru a fi remediată. Deci, atunci când echipa de dezvoltare lucrează la remedierea unei erori, ei vizează în mare parte o anumită versiune a aplicației.

13) Data închiderii:

Este data la care eroarea este închisă de echipa de testare a software-ului. Închiderea unei erori este o parte vitală și integrantă a testării software-ului.

14) Stare:

Când se creează o nouă eroare, starea acestuia ar trebui să fie deschisă. După aceea, trece prin etape precum În desfășurare, Fixat, Running, Redeschidere etc.

Sfaturi pentru scrierea rapoartelor de eroare

Iată câteva sfaturi importante pe care ar trebui să le rețineți când scrieți un raport eficient de eroare:

• Be specific when creating bug reports. Make sure you do not include any useless or irrelevant facts.
• Trebuie să raportați imediat eroarea imediat ce este detectată.
• Pregătiți raportul în detaliu pentru a permite dezvoltatorului să folosească faptele și informațiile pentru a depana problema.
• Ar trebui să testați aceeași apariție a erorilor pe alte module similare pentru validare.
• Revvizualizați raportul de eroare cel puțin o dată înainte de a-l trimite.
• Trebuie să vă asigurați că raportul de eroare conține descrierea unei singure erori.
• În cele din urmă, nu ar trebui să vă fie teamă să cereți ajutor managerului de proiect dacă vă simțiți neclar în legătură cu ceva.
• Use AI-assisted triage features in Jira or Linear to auto-classify severity, suggest duplicates, and route the report to the right component owner.

Instrumente de raportare a erorilor

Procesul de raportare a erorilor, efectuat manual, este acum realizat cu diverse instrumente de raportare a erorilor disponibile pe piață.

• JIRA
• Liniar
• Azure DevOps
• Zoho Bug Tracker
• Bugzilla

Puteți verifica recenzia noastră detaliată a cel mai bun instrument de raportare a erorilor.

Problemă comună și soluție în timpul scrierii unui raport de eroare:

Iată câteva probleme comune și soluțiile lor în timpul scrierii unui raport de eroare:

Exemplu de raportare erori	Problemă
Când înmulțiți 2 cu 3, răspunsul va fi pozitiv.	Raportați modelul, nu un exemplu.
Lista va fi ordonată alfabetic atunci când adăugați un articol nou pentru a evita acest lucru.	Do not only describe what is wrong
De exemplu: Pentru a fi acolo, va trebui să deschideți browserul și să introduceți adresa site-ului URL. You will find the first field, ‘username,’ misspelled.	Întotdeauna direct la obiect (Nu spune niciodată povestea!).
Numele clientului din raport este scris greșit. Prioritate: mare, severitate: mare	Nu amestecați niciodată prioritatea și severitatea.
Formula de calcul a taxei este INCORECTA !!??	Nu folosește CAPS, litere roșii, cercuri roșii, „!”,
I do not think that the home page Ul design is good.	Do not use your judgment.
Exemplu de descriere neclară: Despre discuția noastră de astăzi, vă rugăm să faceți acțiunea necesară pentru această pagină.	Faceți descrierea dvs. ușor de înțeles pentru toată lumea.
Fundalul paginii ar trebui să fie albastru, portocaliu sau verde, sau îl puteți face alb sau negru. Acest lucru nu este bun, deoarece nu este clar ce este necesar din partea echipei de dezvoltare și design web	Minimizați opțiunile
Formula de calcul a taxelor nu funcționează uneori conform așteptărilor.	The golden rule: Do not use the word ‘Sometimes’.

Exemplu de raportare erori

Iată un mic exemplu de raport de eroare:

[CONTUL MEU] Sublinierea este afișată la trecerea mouse-ului pe butonul Actualizare.

Description: Trebuie să eliminăm sublinierea când trecem mouse-ul pe butonul Actualizare din secțiunea Contul meu.

Legătură: http://test.com/mv-account/

Browser/OS: Chrome 25. OSX Yosemite 10.10.2

Pasi pentru reproducere:

1. Accesați www.test.com

2. Conectați-vă prin datele de conectare

3. Navigați la Contul meu

4. Treceți cu mouse-ul pe butonul Actualizare

Rezultat actual: există o subliniere.

Rezultat asteptat: fara subliniere.

Date de conectare: test@test.com / mysecretpass12

Trebuie să evite greșelile în scrierea raportului de eroare

Iată câteva greșeli importante pe care ar trebui să le evitați când scrieți un raport de eroare:

• Do not write about your dissatisfaction, and never include your personal feelings.
• Îi enervează pe cei care doresc să se concentreze asupra sarcinii atunci când supraîncărcați postarea cu multe emoticoane.
• Nu supraîncărcați niciodată postarea cu semne de exclamare; nu grăbește munca.
• Nimeni nu vrea să se simtă ofensat. Distruge motivația și încetinește realizarea problemei.

Întrebări frecvente