Slik skriver du en feilrapport (+ gratis nedlasting av mal)

Å vite hvordan man oppretter en effektiv feilrapport, er en viktig del av jobben til en programvaretester for å opprettholde kvalitetssikringen, så vi bruker mye tid på å loggføre feil i feilsporingsverktøyene våre. Det kan føles spennende å finne en feil, spesielt hvis det er et interessant scenario. Men hvordan vi rapporterer den, kan være like viktig som hvilken innvirkning den har på systemet.

En dårlig skrevet feilrapport kan skape mye friksjon mellom teammedlemmer, særlig mellom testere og utviklere, noe som kan føre til blokkeringer for feilrettingene og til syvende og sist ødelegge brukeropplevelsen.

I denne artikkelen deler jeg viktige detaljer, blant annet hvordan du kan:

• Beherske feilrapporter: Lær de viktigste elementene alle effektive feilrapporter bør inneholde, slik at kommunikasjonen blir enklere og feilrettinger kan fremskyndes.
• Styrke harmonien i teamet: Oppdag hvordan velskrevne feilrapporter forhindrer friksjon mellom testere og utviklere, noe som fører til smidigere arbeidsflyter.
• Gratis nedlastbar mal: Få en gratis, nedlastbar mal for feilsporing, slik at du raskt kan komme i gang med en effektiv feilrapporteringsprosess.

Viktige elementer i en feilrapport

Uansett hvilken type applikasjon du tester, enten det er en skrivebordsapplikasjon, en nettapplikasjon, en mobilapp eller et API-prosjekt, er det noen viktige elementer alle gode feilrapporter bør inneholde. De fleste programvarer for feilsporing har felt for disse elementene, blant annet:

• ID: Hvis du bruker et prosjektstyringsverktøy, for eksempel Jira, blir en ID automatisk tildelt alle nye saker som åpnes. Det finnes også teststyringsverktøy for Jira for feilsporing
• Tittel/beskrivelse: Dette er en kort beskrivelse av problemet. Den bør være kortfattet nok til å være lett å lese, men samtidig beskrivende nok til at andre kan forstå hvor problemet ligger. For eksempel: «sortering av elementer etter pris fungerer ikke når et filter er lagt til.» 
• Trinn for å gjenskape: Ta med så mange relevante detaljer som mulig her. Sørg for at den som prøver å gjenskape problemet eller bekrefte rettingen, kan gjøre det bare ved å følge trinnene. Ikke hopp over trinn fordi du antar at alle automatisk vet at de skal utføre bestemte handlinger selv om de ikke er nevnt; ta dem med i feilrapporten. 
• Forventede resultater: Igjen bør du ikke anta at folk allerede vet hvordan applikasjonen skal fungere. Hvis du selvfølgelig får et unntak i brukergrensesnittet når du trykker på en knapp, vet du at det ikke er forventet. Jeg ville imidlertid ikke sagt at det forventede resultatet er «unntaket utløses ikke», men heller hvilken handling knappen skal utføre, for eksempel «innstillingsdialogen åpnes.»
• Faktiske resultater: Dette sier seg selv – du bør beskrive hva som skjer i applikasjonen når alle trinnene for å gjenskape problemet, er utført.
• Alvorlighetsgrad: Dette representerer hvilken innvirkning feilen har på AUT.
• Prioritet: Hvor raskt feilen bør rettes. Høyere prioritet betyr at feilen bør plasseres høyere i oppgavelisten og rettes tidligere.

Annen viktig informasjon som bør inkluderes 

I tillegg til elementene som er nevnt ovenfor, kan annen informasjon være relevant, spesielt når du legger inn data i et feilrapporteringsverktøy. Den kan avhenge av prosjekttypen, prosjektkravene eller til og med selve feilen:

• Programvareversjon: Byggenummeret der feilen ble identifisert. Dette kan bidra til å avgrense byggene der problemet potensielt ble introdusert, og identifisere koden som forårsaket det.

• Vedlegg: Disse er kanskje ikke alltid nødvendige eller tilgjengelige, men de gir vanligvis mye verdi. Vurder å legge ved skjermbilder eller opptak av problemet som ble funnet, loggfiler, stakkspor, nettverksforespørsler og svar osv. 
• Testdata: Noen ganger kan feilene vi finner, bare gjenskapes for bestemte datasett. Hvis det er tilfelle, må du sørge for å inkludere dem, enten i trinnene for å gjenskape feilen (for eksempel «logg inn med brukeren andreea@theqalead.com») eller i et spesifikt felt i feilsporingsverktøyet.
• Miljødetaljer: Hvis feilen bare kan gjenskapes på et bestemt operativsystem, i en bestemt nettleser eller i et bestemt utviklingsmiljø, må du nevne det.  

Tips for å lage en god feilrapport

• Begrens deg til én enkelt feil per rapport. Hvis du oppdager flere feil i de samme områdene, kan du lenke dem til sakssystemet ditt. Hvis du inkluderer mer enn én feil, kan det føre til forvirring og forsinkelser i den eventuelle feilrettingen.
• Sjekk sakssystemet ditt for å forsikre deg om at feilen ikke allerede er rapportert. Hvis den allerede er opprettet, kan du legge til relevante detaljer du har funnet, og som ikke ble sendt inn i den opprinnelige feilrapporten.
• Prøv å gjenskape feilen mer enn én gang. Du kan prøve å finne den korteste måten å gjenskape den på (ved å bruke færrest mulig trinn).
• Ikke gå deg vill i irrelevante detaljer. Feilrapporten og trinnene bør være enkle å lese og følge.
• Ikke gjør antakelser om hvorfor feilen oppstår (med mindre du er 100 % sikker på at du vet hva som forårsaket den).

Mal for feilrapport

Nå vil jeg dele noen maler for feilrapporter med deg. Du kan kopiere eller endre dem i henhold til behovene i prosjektet ditt.

Mal for feilsporing i Jira

Jira er et svært vanlig verktøy for sakssporing fra Atlassian. Hvis teamet ditt bruker det, er sakstypen for feil sannsynligvis allerede konfigurert. Som tester eller leder for et programvareutviklingsteam kan du sette opp en arbeidsflyt for feilsporing for feilenes livssyklus (denne funksjonen er én av mange fordeler med programvare for sakssporing). 

Du kan også legge til egendefinerte felt i Jira, for eksempel for miljøet eller et unikt felt der funksjonaliteten som testes, legges til. Du kan også legge til en standardbeskrivelse med all informasjonen du vil skal inkluderes i hver feilrapport. Her er en jeg opprettet:

Nå vil denne informasjonen være forhåndsutfylt når jeg vil opprette en ny feil. Her er feilmalen min i Jira, med egendefinerte felt og en standardbeskrivelse:

Den inneholder den viktige informasjonen vi sa at feilen må inneholde:

• En tittel («Eksempel på feil»)
• I beskrivelsen: forhåndsbetingelsene, trinnene for å gjenskape feilen og forventede kontra faktiske resultater
• Et egendefinert felt for miljøet
• Alvorlighetsgrad og prioritet, valgt fra rullegardinmenyer med forhåndsdefinerte verdier
• Jeg lot feltet for ansvarlig stå tomt. Avhengig av prosjektkonvensjonene deres kan nye feil automatisk tildeles et bestemt teammedlem, eller den som begynner å arbeide med den, kan tildele den til seg selv
• En etikett – dette kan være nyttig hvis du for eksempel vil spore hvilken funksjonalitet som er berørt
• En forfallsdato – arbeidet blir kanskje ikke fullført før oppgavekøen er prioritert
• Rapportøren (som i dette tilfellet fylles ut automatisk med Jira-brukeren som opprettet feilen)

Jira har også flere integrasjoner som kan brukes valgfritt, og feilen kan kobles til testtilfeller, Git-grener eller til og med pull-forespørsler.

Du kan også bruke deres mal for feilsporing som prosjektmal hvis du bare trenger Jira til feilsporing og ikke arbeider i et smidig utviklingsmiljø.

Mal for feilsporing i Excel

Noen team bruker kanskje regneark i feilsporingssystemet sitt. Jeg synes de er nyttige for svært små prosjekter der det ganske enkelt ikke er verdt å sette opp et verktøy for sakssporing, eller for å rapportere feil i nye funksjoner som fortsatt er under utvikling. 

Du kan bruke Google Sheets/Docs eller Microsoft Excel/Word – uansett kan en feilmal se slik ut:

Kolonnene gjenspeiler informasjonen rapporten bør inneholde:

• ID-en (Excel vet hvordan verdien økes automatisk hver gang en ny rad legges til)
• En tittel
• Trinnene for å gjenskape feilen
• Forventede og faktiske resultater
• Navnet på innmelderen
• Alvorlighetsgrad og feilprioritet—her brukte jeg rullegardinmenyer fordi verdiene bør være forhåndsdefinerte
• Miljø
• Ytterligere informasjon: Dette gjelder alt annet som er verdt å merke seg, men som ikke passer inn i de andre kolonnene

Avsluttende tanker

Å skrive en god feilrapport for programvare er en viktig ferdighet for programvaretestere, så vær ekstra oppmerksom på beste praksis som er forklart ovenfor. Du kan også bruke eksemplene på maler for feilsporingssystemer som jeg har lagt ved. De kan tilpasses de ulike verktøyene du bruker, for eksempel Trello eller Asana.

Hvis du likte dette innholdet, abonner på nyhetsbrevet til The QA Lead for å holde kontakten med flere nyheter og trender innen programvaretesting!