Cum să scrieți un raport de eroare cu exemple

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

Bug Report este un document important în STLC care oferă diverse avantaje echipei de testare. Acesta ține evidența tuturor defectelor, erorilor multiple, erorilor și altor 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 poate fi informat despre toate defectele și problemele prezente în software folosind acest tip de raport. De asemenea, vă permite să vă dați seama ce este în neregulă cu o eroare, astfel încât să puteți utiliza cea mai bună metodă pentru a o remedia. De asemenea, vă ajută să economisiți timp și bani, ajutându-vă să prindeți erori și probleme.

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

Bune explicații 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.

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

Nu există un șablon exact de raportare a erorilor, deoarece depinde de sistemul dvs. de urmărire a erorilor. Șablonul dvs. poate 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)

Să ne uităm la toate aceste componente de eliminare a erorilor una câte una:

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:

Cu toate acestea, adăugarea numai a Titlului în raportul de eroare nu servește scopului. Deci, dacă titlul dvs. nu este suficient, puteți adăuga un scurt rezumat al raportului.

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 coșul de cumpărături, dar nu sa întâmplat nimic când am făcut clic pe butonul „adăugați” de pe pagina web de prezentare generală a produsului.”

6) Pași pentru reproducere:

Când raportați o eroare, este important să specificați pașii de reproducere. De asemenea, ar trebui să includeți acțiuni care pot cauza eroarea. Aici, nu faceți declarații generice.

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: Uneori, este dificil să descrii eroarea în cuvinte, așa că este mai bine să creezi un videoclip, astfel încât dezvoltatorul să poată remedia defectul din 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:

  • Fiți specific atunci când creați rapoarte de eroare. Asigurați-vă că nu includeți fapte inutile sau irelevante.
  • 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.

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ță.

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. Nu descrieți doar ce este în neregulă
De exemplu:
Pentru a fi, va trebui să deschideți browserul și să introduceți adresa URL a site-ului. Veți găsi primul câmp, „nume de utilizator”, scris greșit.
Î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, „!”,
Nu cred că designul paginii de start Ul este bun. Nu-ți folosi judecata.
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. Regula de aur: Nu folosi cuvântul „Uneori”.

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:

  • Nu scrie despre nemulțumirea ta și nu include niciodată sentimentele tale personale.
  • Î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.