Å 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:
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.
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.
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.
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.
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.
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.
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.
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.
Igjen, dette er viktig, for hvis vi kanskje trenger å henvise til personen som reiste feilen, må vi vite hvem vi skal kontakte.
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.
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.
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.