Meny

Hvordan skriver jeg en god feilrapport? Tips og triks

how write good bug report

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hvorfor god feilrapport?

Hvis feilrapporten din er effektiv, er sjansene for å bli løst høyere. Så å fikse en feil avhenger av hvor effektivt du rapporterer det. Å rapportere en feil er bare dyktighet, og jeg vil forklare hvordan du kan oppnå denne ferdigheten.

'Poenget med å skrive problemrapport (feilrapport) er å få feil løst' - Av Cem Kaner. Hvis en tester ikke rapporterer om en feil riktig, vil programmereren mest sannsynlig avvise denne feilen og angi at den ikke kan produseres.

Hvordan skrive en god feilrapport

Dette kan skade testernes moralske og noen ganger også egoet. (Jeg foreslår ikke å beholde noen form for ego. Egoene som 'Jeg har rapportert feilen riktig', 'Jeg kan gjengi den', 'Hvorfor han / hun har avvist feilen?', 'Det er ikke min feil' osv. ,).

Hva du vil lære:

Hva er egenskapene til en god programvarebugrapport?

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

Du bør kunne skille mellom en gjennomsnittlig feilrapport og en god feilrapport. Hvordan skiller man mellom en god og dårlig feilrapport? Det er veldig enkelt, bruk følgende egenskaper og teknikker for å rapportere en feil.

Kjennetegn og teknikker inkluderer

# 1) Å ha et tydelig spesifisert feilnummer: Tildel alltid et unikt nummer til hver feilrapport. Dette vil igjen hjelpe deg med å identifisere feiloppføringen. Hvis du bruker et automatisert feilrapporteringsverktøy, genereres dette unike nummeret automatisk hver gang du rapporterer feilen.

Legg merke til nummeret og en kort beskrivelse av hver feil du rapporterte.

# 2) Reproduserbar: Hvis feilen din ikke er reproduserbar, vil den aldri bli løst.

Du bør tydelig nevne trinnene for å reprodusere feilen. Ikke anta eller hopp over noe reproduksjonstrinn. En feil som er beskrevet trinnvis er enkel å reprodusere og fikse.

# 3) Vær spesifikk: Ikke skriv et essay om problemet.

Vær spesifikk og til poenget. Prøv å oppsummere problemet med minimum ord, men likevel på en effektiv måte. Ikke kombiner flere problemer selv om de ser ut til å være like. Skriv forskjellige rapporter for hvert problem.

Effektiv feilrapportering

Feilrapportering er et viktig aspekt av programvaretesting. En effektiv feilrapport kommuniserer godt med utviklingsteamet og unngår forvirring eller feilkommunikasjon.

En god feilrapport burde være tydelig og kortfattet uten noen manglende nøkkelpunkter. Enhver mangel på klarhet fører til misforståelse og bremser også utviklingsprosessen. Mangelskriving og rapportering er et av de viktigste, men forsømte områdene i testets livssyklus.

God skriving er veldig viktig for å arkivere en feil. Det viktigste punktet som en tester bør huske på er ikke å bruke en kommandotone i rapporten. Dette bryter moral og skaper et usunt arbeidsforhold. Bruk en suggestiv tone.

core java intervju spørsmål for erfarne

Ikke anta at utvikleren har gjort en feil, og dermed kan du bruke harde ord. Før rapportering er det like viktig å sjekke om den samme feilen er rapportert eller ikke.

En duplikatfeil er en belastning i testsyklusen. Sjekk hele listen over kjente feil. Noen ganger kan utviklerne ha kjent problemet og ignorert for en fremtidig utgivelse. Verktøy som Bugzilla som automatisk søker etter dupliserte bugs kan også brukes. Det er imidlertid best å søke etter duplikatfeil manuelt.

Importinformasjonen som en feilrapport må kommunisere er 'Hvordan?' og hvor?' Rapporten skal tydelig svare på hvordan testen ble utført og hvor feilen oppstod nøyaktig. Leseren bør enkelt reprodusere feilen og finne hvor feilen er.

Husk at Målet med å skrive feilrapporten er å gjøre det mulig for utvikleren å visualisere problemet. Han / hun bør tydelig forstå mangelen fra feilrapporten. Husk å gi all relevant informasjon som utvikleren søker.

Husk også at en feilrapport vil bli bevart for fremtidig bruk og skal være godt skrevet med nødvendig informasjon. Bruk meningsfulle setninger og enkle ord for å beskrive feilene dine. Ikke bruk forvirrende uttalelser som kaster bort tiden til anmelderen.

Rapporter hver feil som et eget problem. I tilfelle flere problemer i en enkelt feilrapport, kan du ikke lukke den med mindre alle problemene er løst.

Derfor er det best å del problemene i separate feil . Dette sikrer at hver feil kan håndteres separat. En velskrevet feilrapport hjelper en utvikler med å reprodusere feilen på terminalen. Dette hjelper dem med å diagnostisere problemet også.

Hvordan rapportere et feil?

Bruk følgende enkle malrapport:

Dette er et enkelt feilrapportformat. Det kan variere avhengig av feilrapportverktøyet du bruker. Hvis du skriver en feilrapport manuelt, må noen felt nevnes spesielt som feilnummeret, som skal tilordnes manuelt.

Journalist: Ditt navn og e-postadresse.

Produkt: I hvilket produkt du fant denne feilen.

Versjon: Produktversjonen, hvis noen.

Komponent: Dette er de viktigste delmodulene til produktet.

Plattform: Nevn maskinvareplattformen der du fant denne feilen. De forskjellige plattformene som 'PC', 'MAC', 'HP', 'Sun' etc.

Operativsystem: Nevn alle operativsystemene der du fant feilen. Operativsystemer som Windows, Linux, Unix, SunOS, Mac OS. Nevn de forskjellige OS-versjonene som Windows NT, Windows 2000, Windows XP osv., Hvis aktuelt.

Prioritet: Når skal en feil rettes? Prioritet settes vanligvis fra P1 til P5. P1 som “fikse feilen med høyest prioritet” og P5 som “Løs når tiden tillater det”.

Alvorlighetsgrad: Dette beskriver virkningen av feilen.
Typer av alvorlighetsgrad:

oracle pl sql intervju spørsmål for 5 års erfaring
  • Blokkerer: Ingen videre testarbeid kan gjøres.
  • Kritisk: Søknadskrasj, tap av data.
  • Major: Stort funksjonstap.
  • Liten: Mindre funksjonstap.
  • Triviell: Noen UI-forbedringer.
  • Forbedring: Be om en ny funksjon eller forbedring av den eksisterende.

Status: Når du logger feilen inn i et hvilket som helst feilsporingssystem, vil feilstatusen som standard være 'Ny'.
Senere går feilen gjennom forskjellige stadier som Fixed, Verified, Reopen, Won't Fix, etc.

=> Klikk her for å lese mer om den detaljerte Bug Life Cycle.

Tildel til: Hvis du vet hvilken utvikler som er ansvarlig for den aktuelle modulen der feilen oppstod, kan du spesifisere e-postadressen til utvikleren. Ellers ha det tomt, da dette vil tildele feilen til moduleieren hvis ikke lederen vil tildele feilen til utvikleren. Legg muligens til lederens e-postadresse i CC-listen.

URL: Sidens URL der feilen oppstod.

Sammendrag: En kort oppsummering av feilen, hovedsakelig i 60 ord eller under. Forsikre deg om at sammendraget ditt gjenspeiler hva problemet er og hvor det er.

Beskrivelse: En detaljert beskrivelse av feilen.

Bruk følgende felt for beskrivelsesfeltet:

  • Reprodusere trinn: Nevn tydeligvis trinnene for å reprodusere feilen.
  • Forventet resultat: Hvordan applikasjonen skal oppføre seg på de ovennevnte trinnene.
  • Egentlige resultatet: Hva er det faktiske resultatet av å kjøre trinnene ovenfor, dvs. feiladferden.

Dette er de viktige trinnene i feilrapporten. Du kan også legge til 'Rapporttype' som ett felt til som vil beskrive feiltypen.

Rapporttyper inkluderer:

1) Kodefeil
2) Designfeil
3) Nytt forslag
4) Dokumentasjonsproblem
5) Maskinvareproblem

Viktige funksjoner i feilrapporten

Nedenfor er de viktige funksjonene i feilrapporten:

# 1) Feilnummer / id

Et feilnummer eller et identifikasjonsnummer (som swb001) gjør rapportering av feil og henvisning til en feil mye enklere. Utvikleren kan enkelt sjekke om en bestemt feil er løst eller ikke. Det gjør hele test- og omprøvingsprosessen jevnere og enklere.

# 2) Feiltittel

En feiltittel blir lest oftere enn noen annen del av feilrapporten. Det skal si alt om hva som kommer i feilen.

Bug-tittelen skal være suggestiv nok til at leseren kan forstå den. En tydelig feiltittel gjør det enkelt å forstå, og leseren kan vite om feilen har blitt rapportert tidligere eller er løst.

# 3) Prioritet

Basert på alvorlighetsgraden av feilen, kan det prioriteres for den. En feil kan være en blokkerer, kritisk, større, mindre, trivial eller et forslag. En feilprioritet fra P1 til P5 kan gis slik at de viktige blir sett først.

# 4) Plattform / miljø

OS og nettleserkonfigurasjon er nødvendig for en klar feilrapport. Det er den beste måten å kommunisere hvordan feilen kan reproduseres.

Uten den nøyaktige plattformen eller miljøet, kan applikasjonen oppføre seg annerledes, og feilen på testersiden kan ikke replikeres på utviklerens slutt. Så det er best å nevne tydelig miljøet der feilen ble oppdaget.

# 5) Beskrivelse

Feilbeskrivelse hjelper utvikleren til å forstå feilen. Den beskriver problemet du har opplevd. Den dårlige beskrivelsen vil skape forvirring og kaste bort tiden til utviklerne og testerne også.

Det er nødvendig å kommunisere tydelig om effekten av beskrivelsen. Det er alltid nyttig å bruke komplette setninger. Det er en god praksis å beskrive hvert problem separat i stedet for å smuldre dem helt. Ikke bruk ord som 'Jeg tror' eller 'Jeg tror'.

# 6) Fremgangsmåte for reproduksjon

En god feilrapport bør tydelig nevne trinnene for å reprodusere. Fremgangsmåten skal omfatte handlinger som forårsaker feilen. Ikke gi generiske uttalelser. Vær spesifikk i trinnene du skal følge.

Et godt eksempel på en velskrevet prosedyre er gitt nedenfor

Fremgangsmåte:

  • Velg produkt Abc01.
  • Klikk på Legg i kurv.
  • Klikk Fjern for å fjerne produktet fra handlekurven.

# 7) Forventet og faktisk resultat

En feilbeskrivelse er ufullstendig uten de forventede og faktiske resultatene. Det er nødvendig å skissere hva som er resultatet av testen og hva brukeren kan forvente. Leseren skal vite hva det riktige resultatet av testen er. Nevn tydeligvis hva som skjedde under testen og hva som ble resultatet.

# 8) Skjermbilde

Et bilde er verdt tusen ord. Ta et skjermbilde av feilen med riktig billedtekst for å markere feilen. Fremhev uventede feilmeldinger med lys rød farge. Dette gjør oppmerksom på det nødvendige området.

Noen bonustips for å skrive en god feilrapport

Nedenfor er noen flere ekstra tips for å skrive en god feilrapport:

# 1) Rapporter problemet umiddelbart

Hvis du finner noe feil mens du tester, trenger du ikke vente med å skrive en detaljrapport senere. Skriv i stedet feilrapporten med en gang. Dette vil sikre en god og reproduserbar feilrapport. Hvis du bestemmer deg for å skrive feilrapporten senere, er det store sjanser for å gå glipp av de viktige trinnene i rapporten.

# 2) Reproduser feilen tre ganger før du skriver en feilrapport

Feilen din skal være reproduserbar. Forsikre deg om at trinnene dine er robuste nok til å reprodusere feilen uten tvetydighet. Hvis feilen din ikke er reproduserbar hver gang, kan du fremdeles sende inn en feil som nevner periodens karakter.

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

Noen ganger bruker utvikleren den samme koden for forskjellige lignende moduler. Så det er større sjanser for at feilen i en modul også oppstår i andre lignende moduler. Du kan til og med prøve å finne den mer alvorlige versjonen av feilen du fant.

# 4) Skriv et godt sammendrag av feil

Feilsammendrag vil hjelpe utviklerne med å raskt analysere feilens natur. En rapport av dårlig kvalitet vil øke utviklings- og testtiden unødvendig. Kommuniser godt med feilrapportsammendraget. Husk at sammendraget av feilen brukes som en referanse for å søke i feilen i feilbeholdningen.

hvor du finner nettverkssikkerhetsnøkkel på ruteren

# 5) Les feilrapporten før du trykker på Send-knappen

Les alle setningene, ordlyden og trinnene som brukes i feilrapporten. Se om noen setninger skaper tvetydighet som kan føre til feiltolkning. Villedende ord eller setninger bør unngås for å ha en klar feilrapport.

# 6) Ikke bruk voldelig språk

Det er hyggelig at du gjorde et godt arbeid og fant en feil, men ikke bruk denne æren for å kritisere utvikleren eller angripe noen.

Konklusjon

Ingen tvil om at feilrapporten din skal være et dokument av høy kvalitet.

Fokuser på å skrive gode feilrapporter og bruk litt tid på denne oppgaven fordi dette er det viktigste kommunikasjonspunktet mellom testeren, utvikleren og lederen. Ledere bør skape en bevissthet om teamet sitt om at det å skrive en god feilrapport er hovedansvaret til enhver tester.

Din innsats for å skrive en god feilrapport vil ikke bare spare ressursene til selskapet, men også skape et godt forhold mellom deg og utviklerne.

For bedre produktivitet skriv en bedre feilrapport.

Er du ekspert på å skrive en feilrapport? Del gjerne tankene dine i kommentarfeltet nedenfor.

Anbefalt lesing

^