Så här bygger du en mall för buggspårning i Jira
En mall för felspårning är ett fördefinierat format för att dokumentera och rapportera fel i programvaruutveckling. Genom att använda en mall säkerställs att viktiga detaljer fångas upp på ett enhetligt sätt, vilket underlättar felspårning, prioritering och kommunikation inom ett team.
Jira är ett verktyg för ärendehantering från Atlassian och är förmodligen ett av de mest populära verktygen för felspårning som används för hantering av utvecklingsprojekt (särskilt i agila miljöer). Jag har använt det i många projekt under de senaste åren, med både Scrum och Kanban, och jag tycker att det är mycket mångsidigt.
I den här artikeln går jag igenom Jiras mångsidighet när det gäller felspårning, anpassning och arbetsflödeshantering samt hur man förbättrar felrapportering med Jira.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Oavsett om du ansvarar för att konfigurera Jira-arbetsflöden eller rapporterar defekter med hjälp av verktyget, skadar det inte att känna till hur det fungerar. Jira är mer än bara ett verktyg för felrapportering, men i den här artikeln fokuserar vi mer på att spåra fel än på att hantera andra typer av ärenden.
Konfigurera ett nytt projekt med Jira Software
Om projektet är nytt är det första du behöver göra att konfigurera Jira-projektet. Den uppgiften brukar ligga på scrum mastern eller projektledaren, men om din QA-roll överlappar med någon av dessa roller kan uppgiften hamna på ditt bord. Det är inte komplicerat och bör dessutom bara behöva göras en gång!
Registreringen är kostnadsfri och för små projekt med färre än tio användare kan du använda gratisplanen. Om du har ett större team eller behöver avancerade funktioner kan du välja en av betalplanerna. Jag går inte in på detaljerna, men du kan läsa mer på Jiras prissida om du är intresserad.
Jag har bara skapat nya projekt för att undervisa i en kurs, men processen är ganska intuitiv. Du får möjlighet att välja mellan olika projekttyper för programvaruutveckling:
Projekttyper
- Ett Kanban-projekt låter dig skapa Kanban-tavlor. Du kan använda den klassiska mallen med de klassiska stegen: Att göra, Pågår och Klart.
- Scrum – Den här mallen låter teamet hantera sina sprintar och sin backlogg med hjälp av Scrum-ramverket.
- Felspårning – En enkel mall som gör det möjligt att spåra ärenden utan att använda någon agil metodik.
Alla projekt kan anpassas så att de innehåller de steg, övergångar och statusar som projektet behöver.
I den här handledningen använder jag Scrum-projektmallen så att du kan spåra användarberättelser och fel i samma projekt, men oroa dig inte – allt jag visar kan även tillämpas på andra projekttyper!
Ärendetyper
De ärendetyper som Jira tillhandahåller som standard är:
- Epos: Inom agil utveckling är ett epos en övergripande samling av användarberättelser och uppgifter.
- Fel: Den ärendetyp vi använder i Jira för att spåra upptäckta fel och defekter. Vi fokuserar på dessa under resten av artikeln.
- Användarberättelse: En agil användarberättelse är beskrivningen av den funktion eller funktionalitet som ska utvecklas och testas.
- Uppgift: Används vanligtvis för att spåra enskilda ärenden eller uppgifter, till exempel att undersöka ett nytt verktyg för testautomatisering eller uppdatera dokumentationen.
- Underuppgift: Detta är en individuell uppgift som tilldelats en teammedlem och som är ett underordnat ärende till ärendet ”Uppgift” som nämndes ovan.
Som jag redan nämnt är Jira mycket mångsidigt, och om du behöver skapa en egen ärendetyp kan du göra det när som helst i projektet.
Jag arbetade till exempel tidigare i ett projekt där vi hade en separat ärendetyp för förbättringar. Dessa liknade användarberättelser, men var främst relaterade till förbättringar av befintliga funktioner i applikationen.
Eller så kan du skapa en ärendetyp för testfall, men vi återkommer till det lite senare, där vi går igenom tillgängliga plugin och Jira-integrationsverktyg.
Defektspårning med Jira
Vi går vidare till det som intresserar oss som testare – rapportering och spårning av defekter. Jira är visserligen ett projektledningsverktyg, inte specifikt ett verktyg för defektspårning, men vi som arbetar med kvalitetssäkring kommer förmodligen att använda det för att rapportera många defekter 😁.
Arbetsflöde och defektens livscykel
Det standardarbetsflöde för defekter (och alla ärenden, för den delen) som tillhandahålls av Jira ser ut så här:
När ett ärende öppnas skapas det med statusen 'Att göra'. Därefter kan ärendet, eller defekten, flyttas till någon av de andra statusarna.
Testledningsteamet, scrum mastern eller projektledaren ansvarar vanligtvis för att utforma anpassade arbetsflöden.
Arbetsflödet återspeglar den livscykel för defekter som du vill ha i projektet. Du kan behålla det enkla standardarbetsflödet eller göra det så komplext som behövs. Jag har ärligt talat aldrig arbetat i ett projekt som inte hade egna, anpassade statusar och övergångar.
För att anpassa livscykeln måste du gå till projektinställningarna, välja ärendetypen för defekter och klicka på 'Redigera arbetsflöde'.
Här kan du lägga till valfri ny status och välja en specifik övergång vid behov. Här är ett exempel:
I det här fallet får ett nytt ärende statusen 'Att göra' när det skapas, och därifrån kan det endast flyttas till 'Pågår.' Innan defekten kan testas måste koden sedan granskas. QA-teamet kan stänga den när den har validerats i statusen 'I QA'. Kodgranskningen och QA-processerna kan naturligtvis misslyckas, och i så fall flyttas defekten tillbaka till 'Pågår.'
Skapa ett arbetsflöde steg för steg
Jag går igenom varje steg du behöver ta för att gå från det första arbetsflödet till det andra (eller till vilket anpassat arbetsflöde som helst som passar ditt projekt):
1. Klicka först på knappen 'Redigera arbetsflöde'
2. Om du vill lägga till en ny status klickar du på en av statusarna – statusarna är indelade i tre kategorier: 'Att göra,' 'Pågår,' och 'Klar,' där varje kategori har en särskild färg. Du kan välja var din status passar bäst. Jag beslutade att statusarna 'Under kodgranskning' och 'I QA' innebär att ärendet fortfarande pågår:
Du kan också ha andra statusar av typen 'Att göra'; till exempel statusen 'Under granskning', när en ny funktion öppnas och produktägaren eller verksamhetsanalytikern fortfarande behöver lägga till information om den, eller när teamet ännu inte har förfinat den och beslutat om dess komplexitet eller uppskattat dess story points.
3. När du har lagt till den nya statusen kan du lägga till en övergång för den. Som standard kan statusen uppdateras från vilken annan status som helst. Om du inte vill ha specifika regler för övergångar är det helt okej. Ett bra arbetsflöde bör dock göra det möjligt att flytta defekter och ärenden till specifika statusar först efter att de har gått igenom vissa processteg.
I exemplet ovan kan QA-teamet inte börja verifiera korrigeringen innan en annan utvecklare har granskat koden. Om du vill lägga till den här övergången klickar du på knappen 'Övergång' och anger uppgifterna:
4. Du kan också ta bort befintliga övergångar och statusar om du vill att allt ska vara 100 % anpassat.
5. En riktigt praktisk funktion är automatiska ansvariga. Detta görs också från arbetsflödet, där du kan ange en standardanvändare som tilldelas när en viss övergång utförs för ärendet (detta är också en viktig fördel med programvara för ärendespårning).
Efter att en bugg till exempel har 'Granskats' och flyttats till 'Under QA' tilldelas den automatiskt till en viss testare eller testansvarig, som avgör vem som ska arbeta med den. Detsamma gäller för 'Pågår' och utvecklingsteamet. Nyskapade ärenden kan automatiskt tilldelas en projektledare eller produktägare, som prioriterar dem i backloggen. Det går att anpassa i hög grad, så att du kan utforma det på det sätt som fungerar bäst för ditt team.
Även om du inte ansvarar för att konfigurera ärendenas livscykler, eller om du inte har åtkomst till projektinställningarna, kan du se arbetsflödet för varje Jira-ärende genom att expandera rullgardinsmenyn för status:
Visa ärenden i Jira
Om projektet inte är ett projekt för buggspårning kan du visa aktuella ärenden på Kanban- eller Scrum-tavlorna:
Det här är bara för att demonstrera; jag tvivlar på att du någonsin kommer att ha turen att få en sprint med bara en användarberättelse och en bugg 😅.
Om du klickar på ett ärende visas dess information. Den omfattar bland annat ett ID, som skapas automatiskt av Jira, en titel, en beskrivning, rapportören, den tilldelade personen samt eventuella bilagor eller kommentarer som teammedlemmarna har lagt till.
Fälten kan också anpassas, och jag kommer att demonstrera det när vi diskuterar vad som bör ingå i en bra buggrapport.
Tilldelade personer
Alla Jira-ärenden kan tilldelas en specifik teammedlem. Du kan tagga personer i kommentarerna eller beskrivningen genom att använda tecknet @ före användarens namn.
Du får aviseringar när någon taggar dig och när ett ärende som tilldelats dig eller rapporterats av dig uppdateras. Du kan också ”bevaka” ärenden. Du får en avisering när bevakade ärenden uppdateras, oavsett vem som rapporterat dem eller tilldelats dem.
Rapportera buggar i Jira
Alla strävar efter en app med få buggar, men låt oss vara ärliga: testare blir alltid glada när vi hittar en bra bugg.
Men en bra bugg är bara så bra som sättet den rapporteras på – en bra buggrapport ser till att den åtgärdas med så lite fram och tillbaka mellan test- och utvecklingsteamen som möjligt. Jira är ett utmärkt verktyg för buggspårning. Har jag redan nämnt det? Det ger stor flexibilitet.
Om du vill skapa ett nytt ärende klickar du på den stora knappen 'Skapa', så öppnas en dialogruta. Välj här ärendetypen 'Bugg' :
En bra buggrapport bör innehålla en bra beskrivning (eller 'Sammanfattning' i Jira). Den bör vara kortfattad men innehålla tillräckligt med information för att det ska vara tydligt vad ärendet gäller.
Lägg sedan till alla relevanta detaljer i beskrivningen. Du kan strukturera dem på ett klassiskt sätt:
- Steg för att återskapa
- Förväntat resultat
- Faktiskt resultat
Ta sedan med alla andra detaljer som är relevanta för defekten. Skärmbilder eller inspelningar är alltid en bra idé, liksom loggar eller specifika filer som användes under körningen.
I Jira kan du lägga till anpassade fält i ärenden. Jag tycker om att skilja 'Allvarlighetsgrad' från 'Prioritet.' Medan 'Prioritet' är ett standardfält som läggs till av Jira kan du alltså lägga till ett anpassat fält för 'Allvarlighetsgrad.'
Andra anpassade fält som kan vara värda att lägga till kan vara relaterade till operativsystemet – ett textfält eller en rullgardinsmeny med fördefinierade värden, till exempel de Android- och iOS-versioner som används vid testning, webbläsaren, versionsnumret eller annan information som kan vara relevant vid buggspårning.
Om du vill lägga till nya fält går du till projektinställningarna, väljer typen 'Bugg' och väljer vilken typ av fält du behöver:
Testfall i Jira
Det sista jag vill ta upp är testfall. Jira Software kan integreras med olika verktyg för testhantering, eller så kan du lägga till utökningar och tillägg från Atlassian, till exempel Zephyr (som brukade vara min favorit) eller Xray. När du skapar en bugg till följd av ett misslyckat testfall kan testet länkas till buggen, vilket kan vara mycket användbart vid hantering av buggar, tester och körning av testfall.
Vill du veta mer?
Jira kan vara ett utmärkt verktyg för felspårning och kan förbättra utvecklingsprocessen eftersom det möjliggör omfattande anpassningar. När det gäller buggar är det verkligen användbart eftersom du kan anpassa arbetsflödet så att det passar den livscykel du vill ha i ditt projekt. Du kan länka buggar till testfall och lägga till anpassade fält på det sätt som passar bäst för just ditt projekt.
För fler instruktionsguider som denna kan du prenumerera på nyhetsbrevet från The QA Lead.
