Što uključiti u izvještaj o greškama?



Kako napisati dobar izvještaj o greškama

Pisanje dobrog izvještaja o nedostacima ili greškama uvelike pomaže u brzom prepoznavanju i rješavanju problema. U ovom postu navodimo uobičajene elemente koji su obično uključeni u izvještaj o greškama.

Bez posebnog redoslijeda:

Identifikator oštećenja, ID

Identifikator je vrlo važan za mogućnost upućivanja na kvar u izvješćima. Ako se alat za prijavu kvara koristi za bilježenje kvara, ID je obično jedinstveni broj generiran programom koji se uvećava po zapisniku kvara.


Sažetak

Sažetak je ukupni opis kvara i uočenog kvara na visokoj razini. Ovaj kratki sažetak trebao bi biti vrhunac nedostatka jer je to ono što programeri ili recenzenti prvo vide u izvješću o programskoj pogrešci.

Opis

Priroda nedostatka mora biti jasno napisana. Ako programer koji pregledava kvar ne može razumjeti i ne može slijediti detalje kvara, tada će se izvještaj najvjerojatnije vratiti natrag ispitivaču tražeći više objašnjenja i više detalja što uzrokuje kašnjenja u rješavanju problema.


Opis bi trebao tačno objasniti korake za reprodukciju nedostatka, zajedno s očekivanim rezultatima i ishodom koraka ispitivanja. Izvještaj treba reći u kojem je koraku uočen neuspjeh.

Ozbiljnost

Ozbiljnost kvara pokazuje koliko je kvar ozbiljan u smislu oštećenja drugih sustava, poduzeća, okoliša i života ljudi, ovisno o prirodi aplikacijskog sustava. Ozbiljnosti se obično rangiraju i kategoriziraju u 4 ili 5 razina, ovisno o definiciji organizacije.

  • S1 - kritično: To znači da je kvar zaštitni čep s velikim potencijalnim oštećenjima i nema zaobilazno rješenje kako bi se izbjegao kvar. Primjer bi mogao biti da se aplikacija uopće ne pokreće i uzrokuje isključivanje operativnog sustava. To zahtijeva trenutnu pažnju i radnju i popravak.
  • S2 - ozbiljno: To znači da neke glavne funkcionalnosti aplikacija ili nedostaju ili ne rade i nema zaobilaženja. Primjerice, program za pregled slika ne može čitati neke uobičajene formate slika.
  • S3 - normalno: To znači da neke glavne funkcionalnosti ne rade, ali postoji zaobilazno rješenje koje se koristi kao privremeno rješenje.
  • S4 - Kozmetika / poboljšanje: To znači da kvar uzrokuje neugodnosti i smetnje. Primjer može biti iskačuća poruka svakih 15 minuta ili uvijek morate dvaput kliknuti gumb GUI da biste izvršili akciju.
  • S5 - Prijedlog: To obično nije kvar i prijedlog za poboljšanje funkcionalnosti. To mogu biti GUI ili postavke gledanja.

Prioritet

Jednom kada se utvrdi ozbiljnost, slijedi vidjeti kako odrediti prioritete za rješenje. Prioritet određuje koliko brzo treba otkloniti kvar. Prioritet se obično odnosi na poslovnu važnost, poput utjecaja na projekt i vjerojatnog uspjeha proizvoda na tržištu. Poput ozbiljnosti, prioritet je također kategoriziran na 4 ili 5 razina.

  • P1 - Hitno: Znači izuzetno hitno i zahtijeva trenutno rješavanje
  • P2 - visoka: Zahtjev razlučivosti za sljedeće vanjsko izdanje
  • P3 - Srednje: Rezolucija potrebna za prvu implementaciju (umjesto svih implementacija)
  • P4 - niska: Rezolucija željena za prvu implementaciju ili sljedeća buduća izdanja

Pročitajte više o težini nasuprot prioritetu


Važno je napomenuti da kvar koji ima visoku težinu također ima visoki prioritet, tj. Teški kvar zahtijeva visok prioritet da se problem riješi što je brže moguće. Nikada ne može biti greške visoke ozbiljnosti i niskog prioriteta. Međutim, kvar može imati malu težinu, ali imati visok prioritet.

Primjer bi mogao biti naziv tvrtke pogrešno napisan na početnom zaslonu prilikom pokretanja aplikacije. To ne uzrokuje ozbiljnu štetu okolišu ili životima ljudi, ali može imati potencijalnu štetu ugledu tvrtke i naštetiti poslovnoj dobiti.

Datum i vrijeme

Datum i vrijeme nastanka ili prijave kvara također su bitni. To je obično korisno kada želite potražiti nedostatke koji su identificirani za određeno izdanje softvera ili od početka faze testiranja.

Verzija i verzija testiranog softvera

I ovo je vrlo važno. U većini slučajeva postoji mnogo verzija softvera; svaka inačica ima mnogo popravaka i više funkcionalnosti i poboljšanja u odnosu na prethodne verzije. Stoga je neophodno napomenuti koja je inačica softvera pokazala neuspjeh koji prijavljujemo. Uvijek se možemo pozvati na tu verziju softvera kako bismo reproducirali kvar.


Izvijestio

Opet, ovo je važno, jer ako ćemo se možda morati obratiti osobi koja je podigla kvar, moramo znati kome se obratiti.

Srodni zahtjev

U osnovi se sve značajke softverske aplikacije mogu pratiti prema odgovarajućim zahtjevima. Stoga, kad se uoči kvar, možemo vidjeti na koje su zahtjeve utjecali.

To može pomoći u smanjenju dvostrukih izvješća o nedostacima jer ako možemo identificirati izvorni zahtjev, a ako se drugi nedostatak zabilježi s istim brojem zahtjeva, možda ga neće trebati prijaviti ponovno ako su nedostaci slične prirode.

Prilozi / dokazi

Svi dokazi o neuspjehu trebaju se uhvatiti i dostaviti uz izvještaj o kvaru. Ovo je vizualno objašnjenje opisa nedostatka i pomaže recenzentu, programeru da bolje razumije nedostatak.


Zaključak

U ovom smo članku saznali koje bismo informacije obično trebali sadržavati u izvješću o greškama. Stvaranje dobrog izvješća o programskoj pogrešci ubrzava analizu osnovnog uzroka i ispravljanje programske pogreške.