Menu

Hvordan man skriver en god fejlrapport? Tips og tricks

how write good bug report

Prøv Vores Instrument Til At Fjerne Problemer

Hvorfor god fejlrapport?

Hvis din fejlrapport er effektiv, er dens chancer for at blive rettet højere. Så afhjælpning af en fejl afhænger af, hvor effektivt du rapporterer det. Rapportering af en fejl er intet andet end dygtighed, og jeg vil forklare, hvordan man opnår denne færdighed.

“Pointen med at skrive problemrapport (bugrapport) er at få bugs løst” - Af Cem Kaner. Hvis en tester ikke rapporterer en fejl korrekt, afviser programmøren sandsynligvis denne fejl, idet den angiver den som irreproducerbar.

Sådan skriver du en god fejlrapport

Dette kan skade testernes moralske og undertiden også egoet. (Jeg foreslår ikke at beholde nogen form for ego. Egoerne som 'Jeg har rapporteret fejlen korrekt', 'Jeg kan gengive den', 'Hvorfor han / hun har afvist bugten?', 'Det er ikke min skyld' osv. ,).

Hvad du vil lære:

Hvad er egenskaberne ved en god softwarefejlrapport?

Alle kan skrive en fejlrapport. Men ikke alle kan skrive en effektiv fejlrapport.

Du skal være i stand til at skelne mellem en gennemsnitlig fejlrapport og en god fejlrapport. Hvordan skelnes der mellem en god og dårlig fejlrapport? Det er meget simpelt, anvend følgende egenskaber og teknikker til at rapportere en fejl.

Egenskaber og teknikker inkluderer

# 1) At have et klart specificeret fejlnummer: Tildel altid et unikt nummer til hver fejlrapport. Dette vil igen hjælpe dig med at identificere fejloptegnelsen. Hvis du bruger et automatisk værktøj til rapportering af fejl, genereres dette unikke nummer automatisk hver gang, mens du rapporterer fejlen.

Bemærk antallet og en kort beskrivelse af hver fejl, som du rapporterede.

# 2) Reproducerbar: Hvis din fejl ikke er reproducerbar, bliver den aldrig rettet.

Du bør tydeligt nævne trinene til at gengive fejlen. Du må ikke påtage dig eller springe noget reproduktionstrin over. En fejl, der er beskrevet trin for trin, er let at reproducere og rette.

# 3) Vær specifik: Skriv ikke et essay om problemet.

Vær specifik og til det punkt. Prøv at opsummere problemet med mindst ord endnu på en effektiv måde. Kombiner ikke flere problemer, selvom de ser ud til at være ens. Skriv forskellige rapporter for hvert problem.

Effektiv fejlrapportering

Fejlrapportering er et vigtigt aspekt af softwaretest. En effektiv fejlrapport kommunikerer godt med udviklingsteamet og undgår forvirring eller fejlkommunikation.

En god fejlrapport burde være klar og kortfattet uden manglende nøglepunkter. Enhver mangel på klarhed fører til misforståelse og bremser også udviklingsprocessen. Fejlskrivning og rapportering er et af de vigtigste, men forsømte områder i testets livscyklus.

God skrivning er meget vigtig for arkivering af en fejl. Det vigtigste punkt, som en tester skal huske på, er ikke at bruge en kommandotone i rapporten. Dette bryder moral og skaber et usundt arbejdsforhold. Brug en suggestiv tone.

bedste gratis registry cleaner windows 10

Antag ikke at udvikleren har lavet en fejl, og derfor kan du bruge barske ord. Før rapportering er det lige så vigtigt at kontrollere, om den samme fejl er rapporteret eller ej.

En duplikatfejl er en byrde i testcyklussen. Tjek hele listen over kendte bugs. Til tider har udviklerne måske kendt problemet og ignoreret for en fremtidig frigivelse. Værktøjer som Bugzilla, der automatisk søger efter duplikerede bugs, kan også bruges. Det er dog bedst at manuelt søge efter en duplikatfejl.

De importoplysninger, som en fejlrapport skal kommunikere, er 'Hvordan?' og hvor?' Rapporten skal klart besvare, hvordan testen blev udført, og hvor defekten opstod nøjagtigt. Læseren skal let reproducere bugten og finde, hvor bugten er.

Husk, at mål med at skrive Bug-rapporten er at gøre det muligt for udvikleren at visualisere problemet. Han / hun skal klart forstå manglen fra Bug-rapporten. Husk at give alle relevante oplysninger, som udvikleren søger.

Husk også på, at en fejlrapport bevares til fremtidig brug og skal være velskrevet med de krævede oplysninger. Brug meningsfulde sætninger og enkle ord for at beskrive dine bugs. Brug ikke forvirrende udsagn, der spilder anmelderens tid.

Rapporter hver fejl som et separat problem. I tilfælde af flere problemer i en enkelt fejlrapport kan du ikke lukke den, medmindre alle problemerne er løst.

Derfor er det bedst at opdel problemerne i separate fejl . Dette sikrer, at hver fejl kan håndteres separat. En velskrevet fejlrapport hjælper en udvikler med at reproducere bugten på deres terminal. Dette hjælper dem også med at diagnosticere problemet.

Sådan rapporteres et fejl?

Brug følgende enkle fejlrapportskabelon:

Dette er et simpelt fejlrapportformat. Det kan variere afhængigt af det fejlrapportværktøj, du bruger. Hvis du skriver en fejlrapport manuelt, skal nogle felter nævnes specifikt som bugnummeret, som skal tildeles manuelt.

Reporter: Dit navn og din e-mail-adresse.

Produkt: I hvilket produkt du fandt denne fejl.

Version: Produktversionen, hvis nogen.

Komponent: Dette er produktets hovedundermoduler.

Platform: Nævn hardwareplatformen, hvor du fandt denne fejl. De forskellige platforme som 'PC', 'MAC', 'HP', 'Sun' osv.

Operativ system: Nævn alle de operativsystemer, hvor du fandt fejlen. Operativsystemer som Windows, Linux, Unix, SunOS, Mac OS. Nævn de forskellige OS-versioner også som Windows NT, Windows 2000, Windows XP osv., Hvis det er relevant.

Prioritet: Hvornår skal en fejl rettes? Prioritet er generelt indstillet fra P1 til P5. P1 som “fix bug med den højeste prioritet” og P5 som “Fix når tiden tillader det”.

Alvorlighed: Dette beskriver virkningen af ​​fejlen.
Typer af sværhedsgrad:

oprette en midlertidig falsk e-mail-adresse
  • Blokering: Der kan ikke udføres yderligere testarbejde.
  • Kritisk: Applikationsnedbrud, tab af data.
  • Major: Stort tab af funktion.
  • Mindre: Mindre funktionstab.
  • Trivial: Nogle UI-forbedringer.
  • Forbedring: Anmodning om en ny funktion eller en forbedring af den eksisterende.

Status: Når du logger fejlen ind i et hvilket som helst fejlsporingssystem, er fejlstatus som standard 'Ny'.
Senere går fejlen gennem forskellige faser som Fixed, Verified, Reopen, Won't Fix osv.

=> Klik her for at læse mere om den detaljerede Bug Life Cycle.

Tildel til: Hvis du ved, hvilken udvikler der er ansvarlig for det pågældende modul, hvor fejlen opstod, kan du angive e-mail-adressen til den pågældende udvikler. Ellers skal du holde det tomt, da dette tildeler bugten til modulets ejer, hvis ikke Manager tildeler bugten til udvikleren. Tilføj muligvis lederens e-mail-adresse i CC-listen.

URL: Sidens URL, som fejlen opstod på.

Resumé: En kort oversigt over fejlen hovedsagelig i 60 ord eller derunder. Sørg for, at din oversigt reflekterer over, hvad problemet er, og hvor det er.

Beskrivelse: En detaljeret beskrivelse af fejlen.

Brug følgende felter til beskrivelsesfeltet:

  • Reproducer trin: Nævn klart trinene til reproduktion af fejlen.
  • Forventet resultat: Hvordan applikationen skal opføre sig på de ovennævnte trin.
  • Faktisk resultat: Hvad er det faktiske resultat af at køre ovenstående trin, dvs. fejladfærden.

Dette er de vigtige trin i fejlrapporten. Du kan også tilføje 'Rapporttype' som endnu et felt, der beskriver fejltypen.

Rapporttyper inkluderer:

1) Kodningsfejl
2) Designfejl
3) Nyt forslag
4) Dokumentationsproblem
5) Hardwareproblem

Vigtige funktioner i din fejlrapport

Nedenfor er de vigtige funktioner i fejlrapporten:

# 1) Fejlnummer / id

Et fejlnummer eller et identifikationsnummer (som swb001) gør fejlrapportering og henvisning til en fejl meget lettere. Udvikleren kan let kontrollere, om en bestemt fejl er rettet eller ej. Det gør hele test- og gentestningsprocessen glattere og lettere.

# 2) Fejltitel

En bugtitel læses oftere end nogen anden del af fejlrapporten. Det skal sige alt om hvad der kommer i fejlen.

Fejltitlen skal være nok suggestiv til, at læseren kan forstå den. En tydelig fejltitel gør det let at forstå, og læseren kan vide, om fejlen er blevet rapporteret tidligere eller er rettet.

# 3) Prioritet

Baseret på sværhedsgraden af ​​fejlen kan der indstilles en prioritet for den. En fejl kan være en Blocker, Critical, Major, Minor, Trivial eller et forslag. En fejlprioritet fra P1 til P5 kan gives, så de vigtige først ses.

# 4) Platform / miljø

OS og browser konfiguration er nødvendig for en klar fejlrapport. Det er den bedste måde at kommunikere, hvordan fejlen kan reproduceres.

Uden den nøjagtige platform eller det nøjagtige miljø kan applikationen opføre sig anderledes, og fejlen i testens ende replikerer muligvis ikke i udviklerens ende. Så det er bedst at nævne klart det miljø, hvor bugten blev opdaget.

# 5) Beskrivelse

Fejlbeskrivelse hjælper udvikleren med at forstå fejlen. Den beskriver det stødte problem. Den dårlige beskrivelse skaber forvirring og spilder også tid for udviklerne og testerne.

Det er nødvendigt at kommunikere tydeligt om effekten af ​​beskrivelsen. Det er altid nyttigt at bruge komplette sætninger. Det er en god praksis at beskrive hvert problem separat i stedet for at smuldre dem helt. Brug ikke udtryk som 'jeg tror' eller 'jeg tror'.

# 6) Trin til reproduktion

En god fejlrapport bør tydeligt nævne trinene til reproduktion. Trinene skal omfatte handlinger, der forårsager fejlen. Giv ikke generiske udsagn. Vær specifik i de trin, der skal følges.

Et godt eksempel på en velskrevet procedure er givet nedenfor

Trin:

  • Vælg produkt Abc01.
  • Klik på Tilføj til kurv.
  • Klik på Fjern for at fjerne produktet fra kurven.

# 7) Forventet og faktisk resultat

En fejlbeskrivelse er ufuldstændig uden de forventede og faktiske resultater. Det er nødvendigt at skitsere, hvad resultatet af testen er, og hvad brugeren kan forvente. Læseren skal vide, hvad det korrekte resultat af testen er. Nævn klart, hvad der skete under testen, og hvad var resultatet.

# 8) Skærmbillede

Et billede siger mere end tusind ord. Tag et skærmbillede af forekomsten af ​​fiasko med korrekt billedtekst for at fremhæve defekten. Fremhæv uventede fejlmeddelelser med lys rød farve. Dette gør opmærksom på det krævede område.

Nogle bonustip til at skrive en god fejlrapport

Nedenfor er nogle flere yderligere tip til at skrive en god fejlrapport:

# 1) Rapporter problemet med det samme

Hvis du finder nogen fejl under testen, behøver du ikke vente med at skrive en detaljeret fejlrapport senere. I stedet skal du skrive fejlrapporten med det samme. Dette vil sikre en god og reproducerbar fejlrapport. Hvis du beslutter at skrive fejlrapporten senere, er der store chancer for at gå glip af de vigtige trin i din rapport.

# 2) Reproducer fejlen tre gange, før du skriver en fejlrapport

Din fejl skal være reproducerbar. Sørg for, at dine trin er robuste nok til at reproducere fejlen uden tvetydighed. Hvis din fejl ikke er reproducerbar hver gang, kan du stadig indsende en fejl, der nævner den periodiske karakter af fejlen.

# 3) Test den samme fejlforekomst på andre lignende moduler

Nogle gange bruger udvikleren den samme kode til forskellige lignende moduler. Så der er større chancer for, at fejlen i et modul også forekommer i andre lignende moduler. Du kan endda prøve at finde den mere alvorlige version af den fejl, du fandt.

# 4) Skriv en god fejloversigt

Fejloversigt hjælper udviklerne med hurtigt at analysere fejlens natur. En rapport af dårlig kvalitet vil unødigt øge udviklings- og testtiden. Kommuniker godt med din fejlrapportoversigt. Husk, at fejloversigten bruges som en reference til at søge i fejlen i fejlbeholdningen.

hvad er den bedste youtube til mp3 konverter?

# 5) Læs fejlrapporten, inden du trykker på knappen Send

Læs alle sætninger, formuleringer og trin, der bruges i fejlrapporten. Se om en sætning skaber tvetydighed, der kan føre til fejlagtig fortolkning. Vildledende ord eller sætninger bør undgås for at få en klar fejlrapport.

# 6) Brug ikke Stødende sprog

Det er rart, at du gjorde et godt stykke arbejde og fandt en fejl, men ikke brug denne kredit for at kritisere udvikleren eller angribe nogen.

Konklusion

Ingen tvivl om, at din fejlrapport skal være et dokument af høj kvalitet.

Fokuser på at skrive gode fejlrapporter, og brug lidt tid på denne opgave, fordi dette er det vigtigste kommunikationspunkt mellem testeren, udvikleren og manager. Ledere skal skabe en bevidsthed om deres team om, at det er enhver testers primære ansvar at skrive en god fejlrapport.

Din indsats for at skrive en god fejlrapport sparer ikke kun virksomhedens ressourcer, men skaber også et godt forhold mellem dig og udviklerne.

For en bedre produktivitet, skriv en bedre fejlrapport.

Er du ekspert i at skrive en fejlrapport? Del gerne dine tanker i kommentarfeltet nedenfor.

Anbefalet læsning

^