Dokumenter feilmeldinger: lag en nyttig supportrapport

En god supportrapport skiller observasjoner fra antakelser. Noter feiltekst, tidspunkt, miljø og trygge trinn for å gjenskape feilen uten å dele fortrolige data. Veiledningen er uavhengig av operativsystem; navnene på versjonsdialogene varierer mellom programmer.

1. Registrer hendelsen

Noter dato, klokkeslett og tidssone samt programmet og den nøyaktige versjonen. Legg til operativsystemets versjon, enhetstype og siste kjente tidspunkt da det fungerte. Skriv “ukjent” når opplysninger mangler, i stedet for å gjette. Beskriv omfanget: gjelder feilen én fil, én bruker eller flere arbeidsstasjoner?

2. Beskriv feilen og trinnene presist

  1. Kopier hele feilmeldingen og feilkoden hvis mulig. Ellers tar du et skjermbilde og skriver også av teksten. Ikke oversett eller forkort feilkoden.
  2. Nummerer handlingene frem til feilen: utgangspunkt, åpnet fil eller funksjon, konkret knapp og resultat. Bruk nøytrale plassholdere for filnavn ved behov.
  3. Skill forventet resultat fra det du faktisk observerte. Skriv “Lagre viser feil X” fremfor “Serveren er ødelagt” så lenge årsaken ikke er påvist.
  4. Oppgi om feilen oppstår alltid, av og til eller bare én gang. Gjenta bare trygge trinn med testdata eller en kopi. Ikke gjenta betalinger, sletting eller handlinger som kan gi datatap for å gjenskape problemet.

3. Dokumentasjon og tidligere forsøk

Legg til kjente endringer rett før feilen og tiltak som allerede er prøvd, med resultatet av hvert. Ikke endre flere innstillinger samtidig. Beskytt originalloggen; del bare nødvendige utdrag fra det relevante tidsrommet. En samtidig hendelse er et spor, ikke bevis på årsaken.

4. Kontroller før sending

Fjern passord, sesjonstokener, personopplysninger og fortrolig dokumentinnhold fra kopien som skal sendes. Kontroller også adressefeltet, filstier og bakgrunnen i skjermbilder. Et rektangel over teksten i en redigerbar fil er ikke sikker fjerning. Åpne det endelige vedlegget på nytt og kontroller resultatet. Bruk den avtalte supportkanalen og kontroller mottaker og vedlegg; ikke publiser ukontrollerte, komplette diagnosepakker i et forum.

Mal som kan kopieres

  • Kort tittel og omfang:
  • Dato, klokkeslett, tidssone:
  • Program/versjon, operativsystem/versjon, enhet:
  • Utgangspunkt og nummererte trinn:
  • Forventet / faktisk observert:
  • Full feiltekst og kode:
  • Hyppighet, siste vellykkede forsøk, kjente endringer:
  • Allerede forsøkt / resultat av hvert forsøk:
  • Kontrollerte vedlegg uten fortrolige data:

Sluttkontroll: en annen person bør forstå forløpet uten å spørre om grunnleggende trinn. Uavhengige problemer skal meldes separat.

Kilde

Mozilla: Bug Writing Guidelines – grunnlag for presise trinn, tydelige resultater og separate rapporter; personvernkontrollen supplerer den generelle supportprosessen.