Underskatta inte en bra skriven buggrapport!

Har du någon gång fått en buggrapport att verifiera eller reproducera som du inte själv har skrivit?

Ibland är sådana buggrapporter förståeliga, men oftast inte. Kanske är den självklar om du har jobbat i samma system i fem år och dessutom kan verksamhetens alla krav och fallgropar som ett rinnande vatten. Ärligt talat är man inte i den positionen särskilt ofta, särskilt inte i konsultrollen då man byter uppdrag med mer eller mindre jämna mellanrum.

Nedan listar jag två olika typer av buggrapporter jag själv stött på, och vilka problem de kan innebära.

1.  Bug: Exception 0x31311Gai125nyx module 3

Okej, var börjar man? Någonstans i applikationen har ett Exception inträffat, så mycket verkar klart. Med lite tur är det i module 3, vad det nu är för något. Nu börjar ett detektivarbete där man som testare får spendera mycket tid med att prata med den som rapporterade buggen, eller någon utvecklare som har upp över öronen med saker att göra. Eller krav. I värsta fall till och med kunden, som man inte gärna vill störa med sådana här frågor.

2.  Datafel när konfigurationsalternativ "Advanced" är valt i dropdown för XTZ-maskinen

Jaha. Den här XTZ-maskinen är alltså något som är frikopplat från applikationen jag faktiskt testar?

Vad är en XTZ-maskin? Samma detektivarbete uppstår för att ta reda på sådana här saker. De kanske är självklara om man är väl förtrogen med systemet man jobbar med, fast kanske inte ens då. Troligtvis inte ens då.

XTZ-maskinen visar sig vara en fristående skrivare som står nere på lagret och kommunicerar med applikationen via ett protokoll. Det finns ingen dokumentation för hur man konfigurerar maskinen, och än mindre hur man ens får igång den. Men den är viktig för en kund så det måste testas. Det tar en vecka innan man får igång allting och har lyckats konfigurera den på ett rimligt sätt. Men inte ens då kan man vara säker på att det är helt rätt.

Så hur löser man sådana här problemställningar?

Mitt förslag är att aldrig underskatta en bra skriven buggrapport.

I några enkla steg innebär det att den inkluderar följande:

Rubrik: skriv en kort, koncis rubrik som sammanfattar problemet: "Data försvinner då man trycker på Spara-knappen"
Förutsättning: icke admin-användare behövs för att reproducera
Steg: beskriv i detalj, men på rimlig nivå, vad som krävs för att återskapa:

1.  konfigurera XTZ-maskinen enligt den här guiden "Konfigurationsguide till XTZ.doc"

2.  öppna det här fönstret (Arkiv -> Settings -> Advanced)

3.  välj "Advanced" i dropdown

Problem: beskriv problemet: "Datafel uppstår. Jag förväntade mig siffran 3 men fick 5"
Loggar: bifoga eventuella loggar som kan hjälpa utveckling att hitta och åtgärda problemet
Bild: bifoga bilder!

Ibland spelar det ingen roll hur tydligt man än utformar buggrapporten, den missförstås ändå. En enda bild kan på ett tydligt sätt visa vad som faktiskt är fel, och således eliminera timmar av frustration, återskapandeförsök eller samtal med utvecklare.

Jobbar man inom test kan allt det här tyckas vara en självklarhet, men så är inte fallet. Ibland blir buggrapporterna lidande på grund av tidsbrist, och ibland är de helt enkelt slarviga eller dåliga. Det hjälper dock otroligt mycket att lägga ett par minuter extra på att skriva ner ordentliga steg och att bifoga en bild. Kom ihåg att det som är självklart för dig inte är det för någon annan.

Behövs en guide till den där XTZ-maskinen, skriv en och hänvisa till den.

Annars finns risken att det kommer gå åt åtskilliga timmar till att få igång den igen. Förmodligen för dig själv, eftersom du nu är expert och har förlagt kunskapen du förvärvade förra gången. Sådan är verkligheten.

När du skriver en buggrapport, skriv den på ett sådant sätt att en person som är helt ny i systemet ändå ska kunna återskapa buggen. Det kommer vara värt det.

Underskatta inte en bra skriven buggrapport!

Hans Olsson
Teknisk testare | Författare

Kort om författaren

Hans Olsson är en noggrann teknisk testare, som även tycker om att arbeta med användbarhetstester och utforskande tester. Med fokus på kvalitet strävar han till att alltid göra det bästa av de situationer han ställs inför. Hans O. är även författare med fem skönlitterära titlar bakom sig och utöver konsultrollen driver han även förlaget Zakuli Förlag