Gengivelse af et problem

Du kan ikke løse et problem, hvis du ikke har problemet i første omgang. Derfor er det en forudsætning for at løse problemet, at det kan gengives. I software betegnes problemer ofte som "bugs", og problemer kaldes ofte "bugrapporter".

Nogen har indsendt en fejlrapport. Du skal kontrollere, at de trin, som rapportøren beskriver, resulterer i den fejl, der rapporteres. Kan du gengive det samme resultat ved at gøre nøjagtigt det, der er beskrevet i rapporten? Hvis du ikke kan, skal du finde ud af hvorfor.

For at begynde at gengive et problem skal du have et udviklingsmiljø opsat.

Fejl i koden

I en ideel situation har du samme opsætning som den person, der har rapporteret fejlen, du følger trinene, og du kan gengive fejlen som beskrevet. I mange tilfælde er det dog ikke så ligetil. Mange fejlrapporter indeholder kun vage forklaringer og en række vage betingelser. Problemet er, at mange fejl varierer afhængigt af de involverede betingelser, herunder hvordan de interagerer, forskellige forudsætninger, operativsystem, operativsystemversion, CPU-arkitektur, eller om brugerens maskine er gammel og langsom eller ny og hurtig. Jo flere oplysninger vi har om situationen omkring fejlen, jo bedre. Forsøg at genskabe de betingelser, som rapportøren har angivet. Hvis du ikke er i stand til det, kan det næste skridt være at anmode om flere oplysninger fra den person, der har rapporteret fejlen.

Den bedste måde at gengive en fejl på er med det mindst mulige eksempel, der stadig viser problemet. Oftest giver rapporterende personer ikke et minimalt brugbart eksempel; hvis de overhovedet giver et eksempel, vil det være kopieret direkte fra deres "virkelige" applikation. Dit mål vil være at reducere rapporten til den mest enkle form, der viser problemet. Den bedste reproduktionssag er det mindst mulige program. Denne reduktion er i sig selv nyttig, fordi den bestemmer, hvad det egentlige problem er. Alle kan tage det minimale eksempel, køre det og observere den beskrevne fejl.

Fejl i dokumentationen

Fejl i dokumentationen kan manifestere sig på forskellige måder. Der kan være problemer med formateringen, som medfører problemer med gengivelsen. Nogle gange er det ikke engang en fejl; personen har måske misforstået dokumentationen eller begået en ægte fejl. Det betyder ikke nødvendigvis, at der ikke er noget problem med dokumentationen. Indholdet kan være uklart eller upræcist, hvilket giver plads til forvirring eller fejlagtig fortolkning. Det er muligt, at et koncept, der burde diskuteres, ikke bliver det, fordi det er fuldstændig udokumenteret.

Når der indberettes en fejl vedrørende et dokumentationsproblem, skal du kontrollere, at det indberettede problem stadig eksisterer. I tilfælde af gengivelsesproblemer skal du oprette dokumentationen for at se, om du kan gengive problemet. Indholdsproblemer skal læses igennem for at kontrollere, at ingen har indsendt en opdatering.

Opdater problemet

Det sidste trin i triageprocessen er at dokumentere dine fund ved at skrive en kommentar til problemet.

Hvis du kan gengive problemet nøjagtigt som beskrevet, er det alt, du behøver at sige. Skriv en kommentar om, at du har bekræftet, at du oplever det samme problem, præcis som den oprindelige rapporterende person beskriver det.

Hvis du kan give yderligere kontekst, skal du medtage detaljer om denne kontekst. Dette kan omfatte muligheden for at gengive problemet på et andet operativsystem eller med en anden version af noget af den involverede software eller noget andet, der adskiller sig fra den oprindelige rapport.

Hvis den oprindelige rapport manglede detaljer, som du havde brug for for at kunne gengive rapporten, skal du medtage disse detaljer. Dette kan omfatte oplysninger om operativsystem eller version, som den oprindelige rapport ikke indeholdt, mere komplette logfiler eller stack traces eller klarere instruktioner om den nøjagtige rækkefølge af handlinger, der er nødvendige for at gengive problemet. Hvis du har udviklet en enklere måde at gengive problemet på (eller hvis den oprindelige rapporterende ikke har angivet et reproduktionsscenario), kan du medtage detaljer om denne reproduktionsmetode.

Hvis du ikke kan gengive problemet, skal du også skrive en kommentar, hvor du beskriver, hvad du har prøvet. Det er næsten lige så vigtigt at vide, hvor et problem ikke findes, som at vide, hvor det findes, fordi det hjælper med at indsnævre en mulig årsag. Hvis du har nogen teorier om, hvorfor du ikke kan genskabe problemet – for eksempel hvis du tror, det er en fejl i brugen, eller at problemet er blevet løst ved en nylig opdatering af operativsystemet – så medtag den spekulation i din kommentar.

Til sidst kan du give eventuelle anbefalinger til kerneteamet. Hvis du mener, at den oprindelige rapport er forkert, kan du foreslå, at sagen lukkes. Hvis du har en teori om årsagen til problemet, kan du også foreslå den. Dine kommentarer vil hjælpe kerneteamet med at finde ud af, hvordan sagen kan føres videre til næste trin.

På dette tidspunkt kan du vælge at forsøge at løse problemet, du netop har gengivet. Alternativt kan du skrive dine fund ned og forsøge at gengive et andet problem.