Hva skal jeg inkludere i en feilrapport?



Hvordan skrive en god feilrapport

Å skrive en god feil eller feilrapport går langt med å identifisere og løse problemene raskt. I dette innlegget lister vi opp de vanlige elementene som normalt er inkludert i en feilrapport.

I ingen spesiell rekkefølge:

Defektidentifikator, ID

Identifikatoren er veldig viktig for å kunne referere til mangelen i rapportene. Hvis et feilrapporteringsverktøy brukes til å logge feil, er ID-en normalt et programgenerert unikt nummer som øker per feillogg.


Sammendrag

Sammendraget er en generell beskrivelse på høyt nivå av feilen og den observerte svikten. Denne korte oppsummeringen skal være et høydepunkt for feilen, da dette er hva utviklerne eller anmelderne først ser i feilrapporten.

Beskrivelse

Defekten må være tydelig skrevet. Hvis en utvikler som vurderer feilen ikke kan forstå og ikke kan følge detaljene i feilen, vil sannsynligvis rapporten bli returnert til testeren og be om mer forklaring og mer detaljer som forårsaker forsinkelser i å løse problemet.


Beskrivelsen skal forklare nøyaktig trinnene for å reprodusere feilen, sammen med hva de forventede resultatene var og hva resultatet av testtrinnet ble. Rapporten skal si i hvilket trinn feilen ble observert.

Alvorlighetsgrad

Alvorlighetsgraden av mangelen viser hvor alvorlig mangelen er når det gjelder å skade andre systemer, bedrifter, miljø og liv for mennesker, avhengig av applikasjonssystemets art. Alvorlighetsgraden er normalt rangert og kategorisert i 4 eller 5 nivåer, avhengig av organisasjonens definisjon.

  • S1 - Kritisk: Dette betyr at mangelen er en utstillingsstopper med store potensielle skader og ikke har noen løsning for å unngå feilen. Et eksempel kan være at applikasjonen ikke starter i det hele tatt og får operativsystemet til å slå seg av. Dette krever øyeblikkelig oppmerksomhet og handling og løsning.
  • S2 - Alvorlig: Dette betyr at noen av hovedfunksjonene i applikasjonene enten mangler eller ikke fungerer, og det er ingen løsning. Eksempel: et program for visning av bilder kan ikke lese noen vanlige bildeformater.
  • S3 - Normal: Dette betyr at noen av hovedfunksjonalitetene ikke fungerer, men det finnes en løsning som kan brukes som en midlertidig løsning.
  • S4 - Kosmetikk / forbedring: Dette betyr at feilen gir ulempe og irritasjon. Eksempel kan være at det kommer en popup-melding hvert 15. minutt, eller du må alltid klikke to ganger på en GUI-knapp for å utføre handlingen.
  • S5 - Forslag: Dette er normalt ikke en feil og et forslag om å forbedre en funksjonalitet. Dette kan være GUI eller visningsinnstillinger.

Prioritet

Når alvorlighetsgraden er bestemt, er neste å se hvordan du kan prioritere oppløsningen. Prioriteten avgjør hvor raskt feilen skal løses. Prioriteringen gjelder vanligvis forretningsbetydningen som innvirkning på prosjektet og den sannsynlige suksessen til produktet på markedet. I likhet med alvorlighetsgrad er også prioritet kategorisert i 4 eller 5 nivåer.

  • P1 - Haster: Betyr ekstremt presserende og krever umiddelbar løsning
  • P2 - høy: Løsningskrav for neste eksterne utgivelse
  • P3 - Medium: Oppløsning som kreves for den første distribusjonen (i stedet for alle distribusjoner)
  • P4 - Lav: Oppløsning ønsket for den første distribusjonen eller påfølgende fremtidige utgivelser

Les mer om alvorlighetsgrad versus prioritet


Det er viktig å merke seg at en mangel som har høy alvorlighetsgrad også har høy prioritet, dvs. en alvorlig mangel vil kreve høy prioritet for å løse problemet så raskt som mulig. Det kan aldri være en høy alvorlighetsgrad og lav prioritetsfeil. Imidlertid kan en mangel ha lav alvorlighetsgrad, men har høy prioritet.

Et eksempel kan være at firmanavnet er feilstavet på sprutskjermen når applikasjonen startes. Dette forårsaker ikke alvorlig skade på miljøet eller menneskers liv, men kan ha potensielle skader på selskapets omdømme og kan skade forretningsfortjenesten.

Dato og tid

Datoen og klokkeslettet for at feilen oppstod eller ble rapportert er også viktig. Dette er vanligvis nyttig når du vil søke etter mangler som ble identifisert for en bestemt programvareutgivelse eller fra testfasen startet.

Versjon og konstruksjon av programvaren under test

Dette er veldig viktig også. I de fleste tilfeller er det mange versjoner av programvare; hver versjon har mange reparasjoner og mer funksjonalitet og forbedringer til de tidligere versjonene. Derfor er det viktig å merke seg hvilken versjon av programvaren som viste feilen vi rapporterer. Vi kan alltid referere til den versjonen av programvaren for å reprodusere feilen.


Rapportert av

Igjen, dette er viktig, for hvis vi kanskje trenger å henvise til personen som reiste feilen, må vi vite hvem vi skal kontakte.

Relatert krav

I hovedsak kan alle funksjonene i en programvare spores til respektive krav. Derfor, når en feil oppdages, kan vi se hvilke krav som har blitt påvirket.

Dette kan bidra til å redusere duplikatfeilrapporter ved at hvis vi kan identifisere kildekravet, og hvis en annen feil er logget med samme kravnummer, trenger vi kanskje ikke rapportere det igjen, hvis feilene er av lignende art.

Vedlegg / bevis

Eventuelle bevis på feilen skal fanges opp og sendes sammen med feilrapporten. Dette er en visuell forklaring på beskrivelsen av feilen og hjelper anmelderen, utvikleren til bedre å forstå feilen.


Konklusjon

I denne artikkelen lærte vi hvilken informasjon vi vanligvis bør inkludere i en feilrapport. Å lage en god feilrapport fremskynder årsaksanalysen og fikseringen av feilen.