https://commons.wikimedia.org/wiki/File:Godin_van_de_Wind_4_Nieuwpoort.jpg

F: Felrapporter som fungerar

Av Charlotta Carlsson 2020-02-09

Det är ingen bra idé att prata om hur man skriver felrapporter med ovana acceptanstestare innan testerna har börjat. De är helt enkelt inte "där" ännu. De behöver med all rätt fokusera på att skaffa kunskaper om systemet och hur det ska stödja deras vardag på jobbet. Jag brukar i det läget nöja mig med att säga att det kan bli så att de hittar fel i testerna som de i så fall ska rapportera in. Å ena sidan vill jag ju inte slå hål på entusiasmen som många känner över att äntligen få köra systemet på riktigt. Å andra sidan måste jag förbereda dem mentalt på att det kommer motgångar.

Det är hur som helst viktigt att som acceptanstestledare förstå det mindset som de flesta av dessa personer har kring att testa. Det är inte som med professionella testare vars yrke är att systematiskt leta fel. Frågar jag innan testen vad testarnas förväntningar är så svarar många: "att systemet ska fungera". Och ja, det är ju också en högst rimlig förväntan.

Med detta sagt, när testarna väl har kommit igång så hittar de kanske något som inte verkar stämma. Då är det dags att förklara hur man skriver en bra felrapport!

Grundläggande:
1. Kort tydlig rubrik som talar om vad det är för fel.
2. Utförlig felbeskrivning där du talar om vad du gjorde steg för steg när du stötte på felet. 
3. Ange vilka testdata du använde (sådant som: vilket kontonummer, vilket produktid, vilken datafil)
4. En eller flera skärmdumpar är ett måste!
5. Klassning av felet utifrån verksamhetspåverkan

Efter projektets behov:
6. Vilken systemdel eller verksamhetsområde gäller det
7. Vilken testmiljö
8. Vilken systemversion
9. Vilken användarroll var du inloggad som
10. Vilken systemleverantör ska hantera felet
11. m.m.

Exempel på dålig felrapport:
Rubrik: Lagersaldo
Felbeskrivning: Saldot syns inte.
Skärmdump finns men visar bara en liten del av skärmbilden.

Exempel på bra felrapport:
Rubrik: Lagersaldo går inte att se på beställningsbilden
Felbeskrivning: Jag är inloggad som lagerpersonal 1234 Nisse Nilsson. Jag har markerat en produkt BL9088 Krossade tomater (se skärmdump) och går till "beställning". Jag ser inget lagersaldo på beställningsbilden. Det fungerar inte att behöva gå till detaljbilden när man ska beställa.
Skärmdump: Bilden visar hela skärmen så det går att se var användaren står i systemet. Testaren har ringat in stället där informationen saknas.
Klassning: 2 - Hög verksamhetspåverkan (då den dagliga beställningsproceduren kommer att bli ineffektiv, och det berör alla våra butiker i landet.)

Om du slarvar med felbeskrivningen är det svårt för systemleverantören att felsöka och återskapa felet. Då kommer felrapporterna i bästa fall tillbaka för komplettering men framför allt finns risken för missförstånd. Den möda du lägger ner på en bra felrapport lönar sig i längden. Jag brukar ha som regel att om en person som inte är insatt i detaljerna i testområdet förstår felrapporten så är den bra.  Som acceptanstestledare i ett stort projekt är jag tillräckligt insatt men kan samtidigt tillräckligt lite om detaljerna för att kunna vara detta "idiotsäkringsfilter". Fattar jag, så fattar systemleverantören antagligen också.

Du som acceptanstestar i ett mindre projekt, kanske med daglig kontakt med utvecklarna, tycker möjligen att det känns som onödig administration med skriftliga felrapporter? Du går ju bara till Nisse och ber honom fixa felet. Självklart behöver testrutiner alltid kontextanpassas, men att på något sätt dokumentera de fel som hittas för att praktiskt kunna följa upp dem, skulle jag i princip alltid rekommendera.

Slutsats för bokstaven F: Felrapporter ska vara övertydliga.