Så skriver du en felrapport (+ ladda ner en gratis mall)

• Bemästrar felrapporter: Lär dig de viktigaste delarna som varje effektiv felrapport bör innehålla för att effektivisera kommunikationen och påskynda korrigeringar.
• Förbättrar samarbetet i teamet: Upptäck hur välskrivna felrapporter förebygger friktion mellan testare och utvecklare, vilket leder till smidigare arbetsflöden.
• Får en kostnadsfri nedladdningsbar mall: Hämta en kostnadsfri, nedladdningsbar mall för felspårning för att komma igång med en effektiv process för felrapportering.

Viktiga delar i en felrapport

Oavsett vilken typ av applikation du testar, vare sig det är en datorapplikation, webbapplikation, mobilapp eller ett API-projekt, finns det vissa viktiga delar som varje bra felrapport bör innehålla. De flesta programvaror för felspårning tillhandahåller fält för dessa delar, bland annat:

• ID: Om du använder ett projekthanteringsverktyg, till exempel Jira, tilldelas ett ID automatiskt till alla nya ärenden som öppnas. Det finns även verktyg för testhantering i Jira för felspårning
• Titel/beskrivning: Detta är en kort beskrivning av problemet. Den bör vara tillräckligt kortfattad för att vara lätt att läsa, men tillräckligt beskrivande för att andra ska kunna förstå var problemet ligger. Till exempel: ”det går inte att sortera objekt efter pris när ett filter har tillämpats.” 
• Steg för att återskapa: Inkludera så många relevanta detaljer som möjligt här. Se till att den som försöker återskapa problemet eller verifiera korrigeringen kan göra det enbart genom att följa stegen. Hoppa inte över steg eftersom du antar att alla underförstått vet att de ska utföra vissa åtgärder även om de inte nämns; inkludera dem i felrapporten. 
• Förväntat resultat: Anta inte heller här att alla redan vet hur applikationen ska fungera. Om du får ett undantag i användargränssnittet när du trycker på en knapp vet du naturligtvis att det inte är förväntat. Jag skulle dock inte säga att det förväntade resultatet är ”ett undantag kastas inte”, utan snarare vilken åtgärd knappen ska utföra, det vill säga ”inställningsdialogrutan öppnas.”
• Faktiskt resultat: Detta är självförklarande – du bör beskriva vad som händer i applikationen när alla steg för att återskapa problemet har genomförts.
• Allvarlighetsgrad: Detta representerar vilken påverkan felet har på AUT.
• Prioritet: Hur snabbt felet bör åtgärdas. En högre prioritet innebär att felet bör placeras högre upp i backloggen och åtgärdas tidigare.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Annan viktig information att inkludera 

Utöver delarna som nämns ovan kan annan information vara relevant, särskilt när du anger data i ett verktyg för felrapportering. Den kan bero på projekttypen, projektkraven eller till och med själva felet:

• Programvaruversion: Versionsnumret för den version där felet identifierades. Detta kan hjälpa till att isolera de versioner där problemet potentiellt introducerades och identifiera koden som orsakade det.

• Bilagor: Dessa kanske inte alltid behövs eller är tillgängliga, men de tillför vanligtvis mycket värde. Överväg att tillhandahålla skärmbilder eller inspelningar av det upptäckta problemet, loggfiler, stackspårningar, nätverksförfrågningar och svar med mera. 
• Testdata: Ibland kan de fel vi hittar endast återskapas för specifika datauppsättningar. Om så är fallet ska du se till att inkludera dem, antingen i stegen för att återskapa problemet (till exempel ”logga in med användaren andreea@theqalead.com”) eller i ett särskilt fält i verktyget för felspårning.
• Miljödetaljer: Om felet endast återskapas i ett specifikt operativsystem, en viss webbläsare eller utvecklingsmiljö ska du nämna det.  

Tips för att skapa en bra felrapport

• Begränsa dig till en enda bugg per rapport. Om du upptäcker fler buggar inom samma områden kan du länka dem till ditt ärendehanteringssystem. Om du inkluderar mer än ett fel kan det orsaka förvirring och förseningar i de potentiella buggfixarna.
• Kontrollera i ditt ärendehanteringssystem att buggen inte redan har rapporterats. Om den redan är öppnad kan du lägga till relevanta detaljer som du hittade men som inte skickades in med den ursprungliga buggrapporten.
• Försök att återskapa buggen mer än en gång. Du kan försöka hitta det snabbaste sättet att återskapa den (genom att använda så få steg som möjligt).
• Fastna inte i irrelevanta detaljer. Buggrapporten och stegen ska vara enkla att läsa och följa.
• Gör inga antaganden om varför buggen uppstår (såvida du inte är 100 % säker på att du vet vad som orsakade den).

Mall för buggrapport

Nu vill jag dela med mig av några mallar för buggrapporter. Du kan kopiera eller ändra dem enligt projektets behov.

More Articles

• Så integrerar du DevOps-verktyg för AWS
• 9 bästa konferenserna om digital transformation att delta i 2026–2027
• Så använder du DevOps-mätvärden för att skala upp ditt företag

Mall för buggspårning i Jira

Jira är ett mycket vanligt verktyg för ärendehantering från Atlassian. Om ditt team använder det är ärendetypen för buggar förmodligen redan konfigurerad. Som testare eller chef för ett programvaruutvecklingsteam kan du konfigurera ett arbetsflöde för buggspårning under buggnas livscykel (denna funktion är en av många fördelar med programvara för ärendehantering).

Du kan också lägga till anpassade fält i Jira, till exempel för miljön eller ett unikt fält där den testade funktionaliteten läggs till. Du kan också lägga till en standardbeskrivning med all information som du vill ska ingå i varje buggrapport. Här är en som jag skapade:

När jag nu vill skapa en ny bugg kommer den här informationen att vara förifylld. Här är min buggrapportmall i Jira, med anpassade fält och en standardbeskrivning:

Den innehåller den viktiga information som vi sa att buggen behöver innehålla:

• En titel (”Exempel på bugg”)
• I beskrivningen: förutsättningarna, stegen för att återskapa buggen samt förväntade respektive faktiska resultat
• Ett anpassat fält för miljön
• En allvarlighetsgrad och en prioritet, valda från rullgardinsmenyer med fördefinierade värden
• Jag lämnade tilldelad person tom. Beroende på projektets konventioner kan nya buggar automatiskt tilldelas en specifik teammedlem, eller så kan den som börjar arbeta med buggen tilldela den till sig själv
• En etikett – detta kan vara användbart om du till exempel vill följa vilken funktionalitet som påverkas
• Ett förfallodatum – arbetet kanske inte kan slutföras förrän ärendekön har prioriterats
• Rapportören (som i det här fallet fylls i automatiskt med den Jira-användare som skapade buggen)

Jira har även flera integrationer som kan användas valfritt, och buggen kan länkas till testfall, Git-grenar eller till och med pull requests.

Du kan också använda deras mall för buggspårning som projektmall om du bara behöver Jira för felspårning och inte arbetar i en agil miljö.

Mall för buggspårning i Excel

Vissa team kan använda kalkylblad för sitt system för buggspårning. Jag tycker att de är användbara för mycket små projekt där det helt enkelt inte är värt att konfigurera ett verktyg för ärendehantering, eller för att rapportera buggar i nya funktioner som fortfarande är under utveckling. 

Du kan använda Google Sheets/Docs eller Microsoft Excel/Word – oavsett vilket kan en buggrapportmall se ut så här:

Kolumnerna återspeglar den information som rapporten bör innehålla:

• ID:t (Excel vet hur värdet automatiskt ska ökas varje gång en ny rad läggs till)
• En titel
• Stegen för att återskapa felet
• Förväntade och faktiska resultat
• Rapportörens namn
• Allvarlighetsgrad och felprioritet – här använde jag rullgardinsmenyer eftersom värdena bör vara förinställda
• Miljö
• Ytterligare information: Detta är till för allt annat som är värt att notera men som inte passar in i de andra kolumnerna

Slutliga tankar

Att skriva en bra felrapport för programvara är en viktig färdighet för programvarutestare, så ägna extra uppmärksamhet åt de bästa metoderna som förklaras ovan. Du kan också använda exemplen på mallar för felspårning som jag tillhandahöll. De kan anpassas till olika verktyg som du använder, till exempel Trello eller Asana.

Om du gillade det här innehållet kan du prenumerera på The QA Leads nyhetsbrev för att hålla dig uppdaterad om fler nyheter och trender inom programvarutestning!