Enhver projektleder ved, at der altid opstår fejl i ens projekter. Uanset hvor dygtig man er, eller hvor grundigt man tester, så vil der slippe nogle fejl gennem nettet af og til.
Men fejl/bugs behøver ikke at ødelægge hele din dag.
Med en klar rapporteringsproces, kan din projektgruppe opdage og løse problemerne hurtigt, så din software er kørende igen med minimal downtime og frustration for kunderne.
Hvad er en fejlrapport?
Før vi går om bord i alle detaljerne med fejlrapportering, så lad os bruge et sekund på at definere det. En fejlrapport er helt basalt den plan du giver dine udviklere, for at hjælpe dem med at komme til bunds i et softwareproblem og få løst det.
Du kan indsende en fejlrapport gennem et formelt ticketsystem eller et værktøj til projektledelse. Derefter kan dine softwareudviklere læse rapporten og spore sig frem til løsningen.
Hvilken information skal du inkludere i en fejlrapport til dine udviklere?
Nedenfor kan du se mine råd til hvad jeg mener skal være med i en fejlrapport til dine udviklere. Lad os starte med det helt basale. De følgende punkter udgør fundamentet for enhver almindelig fejlrapport:
- Kort beskrivelse af fejlen
Det første du skal gøre er, at give fejlen et navn. Hold det kort, men med nok detaljer til at fortælle dine udviklere, hvad der sker og hvilken funktion der påvirkes. - Trin til at genskabe fejlen
Det er også vigtigt at forklare hvordan du opdagede fejlen i første omgang. Tænk over disse spørgsmål:- Sker problemet sporadisk, eller kan du duplikere det?
- Hvis fejlen kan gentages, hvad skal man så gøre for at genskabe den?
- Jo flere detaljer, jo bedre. Når du kan gentage et problem, er det nemmere at finde årsagen.
- Forventet resultat
Når det gælder fejlrapportering, så er det helt rigtigt, at det er ”tanken der tæller”. Når du laver fejlrapportering, så skriv ned hvad der burde være sket da du fik sat fejlen i gang. - Tag et skærmbillede eller skærmoptagelse af det faktisk resultat
Nu hvor du har beskrevet dine forventninger, så skal du vise hvad der sker i virkeligheden. Husk at et billede siger mere end tusind ord. Vedhæft et skærmbillede eller en skærmoptagelse af problemet, hvis du vil have ekstra god karma hos dine udviklere. - Miljøoplysninger
Det er bare en fin måde at beskrive, hvor henne fejlen gemmer sig. Sådan her kan du vise vejen, så dine udviklere kan få fat i fejlen hurtigere. Det kunne eventuelt være ved at besvare disse spørgsmål:- Hvilke browsere påvirkes?
- Opstår problemet på bestemte enheder: Mobil, Tablet eller Desktop?
- Hvilket operativsystem (OS) brugte du eller kunden?
- Omfanget af problemet
Hvis du ved hvor mange kunder der påvirkes af fejlen – og endda hvor meget det koster dig – så hjælper du dine softwareudviklere med at fastslå problemets omfang. På denne måde kan de prioritere løsningen af problemet ud fra de øvrige opgaver. - Bonuspoints: Browserkonsolfejl
Denne hører bestemt til den mere avancerede del af fejlrapportering. Men det er en fed måde at få en masse bonuspoint for dine vilde fejlrapporterings-evner hos dine softwareudviklere. 😍
Browser-konsollen giver udviklere et kig bag kulisserne på funktionen af webappen, Denne gode guide viser dig, hvordan du får adgang til konsollen i forskellige browsere. Når først du er derinde, kan du tage et screenshot af alle de fejl du ser når du er logget ind på konsollen, og vedhæfte det i din fejlrapport.
Eksempel på en fejlrapportering af software
Dette ovenfor var min måde til at dokumentere og spore softwareproblemer. Nedenfor vil du kunne se et eksempel på det, hvordan det ville se ud hvis man eksempelvis rapporterede en fejl i TeamGantt
