Kako napisati izvješće o pogrešci s primjerima

Što je izvješće o pogrešci? Zašto vam je potrebno dobro izvješće o bugovima?

Izvješće o pogrešci važan je dokument u STLC-u koji nudi razne prednosti timu za testiranje. Prati sve nedostatke, višestruke bugove, pogreške i druga odstupanja pronađena tijekom testiranja softvera i prijavljuje ih.

Svrha ove dokumentacije nakon testiranja je pružiti informacije dotičnom timu stručnjaka o razini grešaka na koje se naišlo tijekom procesa testiranja.

vaš inženjer razvoja softvera može biti svjestan svih nedostataka i problema prisutnih u softveru pomoću ove vrste izvješća. Također vam omogućuje da shvatite što nije u redu s greškom, tako da možete upotrijebiti najbolju metodu da je popravite. Također vam pomaže da uštedite vrijeme i novac tako što vam pomaže da uhvatite greške i probleme.

Zašto biste trebali brinuti o dobrim objašnjenjima grešaka?

Evo što trebate uzeti u obzir za pisanje dobrog, detaljnog izvješća o programskoj pogrešci:

• Služi kao vodič za izbjegavanje iste pogreške u budućim izdanjima.
• Uštedite vrijeme za komunikaciju (e-mailovi, pozivi).
• Less raditi za programere (oni će raditi točno ono što želite).
• Imat ćete manje uskih grla u projektu; greške će biti ispravljene brže i učinkovitije.

Kako napisati izvješće o pogrešci (predložak izvješća o pogrešci)

Ne postoji točan predložak izvješća o bugovima jer ovisi o vašem sustavu za praćenje bugova. Vaš predložak može biti drugačiji.

Međutim, sljedeća uobičajena polja uvijek su potrebna kada želite napisati izvješće o pogrešci:

• Bug ID/Naslov.
• Ozbiljnost i prioritet.
• Description
• okolina
• Koraci za reprodukciju.
• Očekivani rezultat.
• Stvarni rezultat.
• Prilozi (snimke zaslona, ​​videozapisi, tekst)

Pogledajmo jednu po jednu sve te komponente za uklanjanje grešaka:

1) Naslov/ID greške:

Svaki bug treba dobiti jedinstveni identifikacijski broj. Alati za prijavu bugova trebali bi imati jedinstvene brojeve za novonastale bugove kako bismo mogli lako identificirati bug.

Primjeri:

❌ Loše: "Ne mogu vidjeti proizvod kad ponovno, mislim da ga ne vidi."

• nejasan
• Agresivan
• Previše riječi

traži da se provede rješenje.

✅ Dobro: “KOŠARICA – Novi artikli dodani u košaricu koji se ne pojavljuju”.

• Ova vrsta naslova trenutno locira problem (CART)
• Fokusira se na stvarni tehnički problem.

2) Ozbiljnost greške:

Ozbiljnost greške je vrlo važan čimbenik u izvješću o grešci. Opisuje učinak kvara na performanse aplikacije.

• Blokator: Ova pogreška uzrokuje neuspjeh aplikacije.
• Smjer: Kritična pogreška ukazuje na veliku promjenu u poslovnoj logici.
• Manje: Problem koji ne utječe na funkcionalnost aplikacije, ali utječe na očekivane rezultate.
• Trivijalno: Ne utječe na funkcionalnost ili rad aplikacije. To bi mogla biti tiskarska pogreška.

3) Prioritet bugova:

Slijedi opća gradacija za određivanje prioriteta bugova:

• Visoka: Pokriva sve što utječe na tijek ili blokira upotrebu aplikacije.
• Srednji: Nepovoljno utječe na korisničko iskustvo.
• Manje: Sve druge pogreške kao što su (tipske pogreške, ikone koje nedostaju, problemi s izgledom itd.).

4) Okruženje:

Bug se može pojaviti u određenom okruženju, ali ne iu drugim. Na primjer, ponekad se pojavi greška prilikom pokretanja web stranice Firefox, ili kvar aplikacije samo kada radi na Android uređaj i dobro radi na iPhoneu.

Ova izvješća o programskim pogreškama mogu se identificirati samo testiranjem na različitim preglednicima ili uređajima. Dakle, pri izvješćivanju o bugu, QA-i bi trebali moći odrediti treba li se bug promatrati u jednom ili više specifičnih okruženja.

5) Sažetak:

Međutim, dodavanje samo naslova u izvješće o pogrešci ne služi svrsi. Dakle, ako vaš naslov nije dovoljan, možete dodati kratki sažetak izvješća.

Vaš sažetak u što je moguće manje riječi uključujući kada i kako je došlo do greške. Vaš naslov i opis pogreške također bi se trebali koristiti u pretraživanjima, tako da morate biti sigurni da ste pokrili važne ključne riječi.

Primjeri:

• Loše: "Pokušavao sam dodati stvari u test, ali ništa se nije pokazalo kada sam to učinio ili kliknuo na gumb."
• Dobro: "Kada sam pokušao dodati [PROIZVOD] u košaricu za kupnju, ali ništa se nije dogodilo kada sam kliknuo gumb 'dodaj' na određenoj web stranici s pregledom proizvoda."

6) Koraci za reprodukciju:

Kada prijavljujete bug, važno je navesti korake za njegovu reprodukciju. Također biste trebali uključiti radnje koje mogu uzrokovati pogrešku. Ovdje nemojte davati nikakve generičke izjave.

Budite precizni u koracima koje trebate slijediti:

Evo primjera dobro napisane procedure:

Koraci:

1. Odaberite proizvod X1.
2. Kliknite na Dodaj u košaricu.
3. Kliknite Ukloni za uklanjanje proizvoda iz košarice.

7) Očekivani rezultat:

U izvješćima o pogreškama važan je opis očekivanog rezultata prema tehničkom zadatku, dizajnu ishoda testnog slučaja ili prema mišljenju ispitivača. Sve to pomaže programerima da se usredotoče na brzo pronalaženje potrebnih informacija.

Na primjer:

Obavezna polja trebaju biti označena crvenom bojom nakon klika na gumb "Pošalji".

8) Stvarni rezultat:

Kao što naziv sugerira, ovo s polje opisuje stvarni učinak buga. Vrlo je važno napisati jasan opis stvarnog rezultata.

Na primjer:

Obavezna polja označena su zelenom bojom nakon klika na gumb "Pošalji".

9) Prilozi (snimke zaslona i videozapisi):

U izvješćima o pogreškama, najbolja je praksa priložiti datoteke izvješćima o pogreškama što olakšava uočavanje informacija kada ih trebate vizualno prikazati:

Na primjer:

• Screenshot: Snimke zaslona mogu lako razraditi pogreške u programu; zgodno je kada je greška istaknuta određenom napomenom, krugom ili slikom strelice).
• Video: Ponekad je teško riječima opisati grešku, pa je bolje napraviti video kako bi programer mogao ispraviti grešku u programu).

10) Pogođena verzija:

To je zahvaćena verzija softvera u kojoj je prijavljena pogreška.

11) Verzija popravka:

To je verzija softvera u kojoj je pogreška riješena. Dakle, kada QA koji je prijavio grešku, provjeri je li popravljena, on koristi ispravnu verziju softvera.

12) Target verzija:

Ciljna verzija u kojoj bi se trebala ciljano ispraviti greška. Dakle, kada razvojni tim radi na ispravljanju pogreške, uglavnom cilja na određenu verziju aplikacije.

13) Datum zatvaranja:

To je datum kada je tim za testiranje softvera zatvorio bug. Zatvaranje buga vitalan je i sastavni dio testiranja softvera.

14) Status:

Kada se stvori novi bug, njegov status bi trebao biti otvoren. Nakon toga prolazi kroz faze kao što su U tijeku, Popravljeno, U tijeku, Ponovno otvaranje itd.

Savjeti za pisanje izvješća o pogreškama

Evo nekoliko važnih savjeta kojih biste se trebali sjetiti dok pišete učinkovito izvješće o bugovima:

• Budite precizni prilikom izrade izvješća o pogreškama. Pazite da ne uključite beskorisne ili nevažne činjenice.
• Morate odmah prijaviti grešku čim se otkrije.
• Detaljno pripremite izvješće kako biste razvojnom programeru omogućili korištenje činjenica i informacija za otklanjanje pogrešaka.
• Trebali biste testirati pojavu iste pogreške na drugim sličnim modulima radi provjere valjanosti.
• Revtj. pogledajte izvješće o bugu barem jednom prije nego što ga pošaljete.
• Trebate osigurati da izvješće o grešci sadrži opis samo jedne greške.
• Na kraju, ne biste se trebali bojati pitati voditelja projekta za pomoć ako vam nešto nije jasno.

Alati za prijavu grešaka

Proces prijave bugova, koji se izvodi ručno, sada se izvodi s različitim alatima za prijavu bugova koji su dostupni na tržištu.

• TURA
• Zoho Bug Tracker
• Bugzilla

Možete pogledati našu detaljnu recenziju najbolji alat za prijavu grešaka.

Uobičajeni problem i rješenje tijekom pisanja izvješća o pogrešci:

Evo nekih uobičajenih problema i njihovih rješenja tijekom pisanja izvješća o pogrešci:

Primjer izvješća o pogrešci	Problem
Kada se množi 2 sa 3, odgovor će biti pozitivan.	Prijavite uzorak, a ne primjer.
Popis će biti poredan abecednim redom prilikom dodavanja nove stavke kako bi se to izbjeglo.	Nemojte samo opisivati ​​što nije u redu
Na primjer: Da biste to učinili, morat ćete otvoriti preglednik i upisati URL stranice. Naći ćete prvo polje, 'korisničko ime', pogrešno napisano.	Uvijek usmjerite na stvar (Nikada ne pričajte priču!).
Ime klijenta u izvješću je pogrešno napisano. Prioritet: Visok, Ozbiljnost: Visok	Nikad ne miješajte prioritet i ozbiljnost.
Formula za izračun poreza je NEISPRAVNA !!??	Ne koristi VELIKA SLOVA, crvena slova, crvene krugove, '!',
Ne mislim da je Ul dizajn početne stranice dobar.	Ne prosuđuj se.
Primjer nejasnog opisa: U vezi naše današnje rasprave, učinite potrebnu radnju za ovu stranicu.	Neka vaš opis bude razumljiv svima.
Pozadina stranice trebala bi biti plava, narančasta ili zelena, a možete je učiniti crnom ili bijelom. To nije dobro jer nije jasno što je potrebno od tima za web razvoj i dizajn	Smanjite mogućnosti
Formula za izračun poreza ponekad ne funkcionira prema očekivanjima.	Zlatno pravilo: Nemojte koristiti riječ 'Ponekad'.

Primjer izvješća o pogrešci

Evo malog primjera izvješća o pogrešci:

[MOJ RAČUN] Podcrtano se prikazuje kada mišem prijeđete preko gumba Ažuriraj.

Description: Moramo ukloniti podcrtavanje kada mišem prelazimo preko gumba Ažuriraj u odjeljku Moj račun.

Veza: http://test.com/mv-account/

Preglednik/OS: Chrome 25. OSX Yosemite 10.10.2

Koraci za reprodukciju:

1. Idite na www.test.com

2. Prijavite se putem vjerodajnica za prijavu

3. Idite na Moj račun

4. Prijeđite mišem na gumb Ažuriraj

Stvarni rezultat: postoji podcrtano.

Očekivani rezultat: bez podvlačenja.

Podaci za prijavu: test@test.com / mysecretpass12

Mora izbjegavati pogreške u pisanju izvješća o greškama

Evo nekoliko važnih pogrešaka koje biste trebali izbjegavati dok pišete izvješće o bugu:

• Nemojte pisati o svom nezadovoljstvu i nikada nemojte uključivati ​​svoje osobne osjećaje.
• Ljude koji se žele usredotočiti na zadatak ljuti kad svoju objavu pretrpate s mnogo emotikona.
• Nikada nemojte pretrpavati svoju objavu uskličnicima; ne ubrzava rad.
• Nitko se ne želi osjećati uvrijeđenim. Uništava motivaciju i usporava realizaciju problema.