jira bug tracking tool tutorial
JIRA Bug Tracking: Defect Life Cycle i JIRA
Jira nedladdning och installation förklarades i detalj i vår tidigare handledning. Testteamen är alltid oroliga över att plocka upp JIRA för Defect Management.
Tvivlet är motiverat. Det härrör från det faktum att även om JIRA bug tracking tool är tillämpligt på IT-företag är det ett generiskt biljettsystem.
Även för IT-projekt gör JIRAs popularitet bland utvecklingsteamet testare och QA-team obekväma. Trots komforten eller obehaget har testteamen inget annat val än att använda JIRA-bugspårningsverktyget i de flesta företag. Vår Komplett guide om JIRA-utbildning ger dig en utmärkt kunskap om verktyget.
=> Klicka här för fullständiga JIRA-handledningsserier
Varför? Enkel logik- Företag vill inte investera i flera verktyg. Det är bara bra affärsmässigt att maximera ditt verktygsanvändning och inte bli galen med att köpa för många licenser.
Så om ett utvecklingsteam använder Atlassian JIRA bug tracking tool för att spåra dess krav, förbättringar, uppgifter eller användarberättelser, då testteamet, troligen, måste använda det för bug tracking.
Men slappna av . JIRAs Defect Management är lika bra som alla andra verktyg . I vissa situationer kan det till och med vara bättre.
Det här är handledningen som kommer att visa dig, via skärmdumpar och allt, JIRAs tillämpbarhet för felspårning.
Vad du kommer att lära dig:
- De bästa funktionerna i JIRA Bug Tracking Tool
- # 1) JIRA behandlar allt arbete inuti det som en fråga
- # 2) Felrapportering behöver följande information registreras för varje problem:
- # 3) Defekt livscykel:
- # 4) Kommentarer och samarbete med Dev Team
- # 5) Länka defekten till ett krav för att möjliggöra spårbarhet
- # 6) Fel kan importeras från en CSV-fil
- # 7) Defekter kan exporteras till Word-, XML- och utskrivbara format
- # 8) Omfattande utredningsrapporter:
- Tillämpningen av JIRA på testning - ett alternativt dilemma
- Skapa ett Jira-nummer och olika fält
- Hur hanteras frågor i JIRA
De bästa funktionerna i JIRA Bug Tracking Tool
Nu kör vi.
# 1) JIRA behandlar allt arbete inuti det som en fråga
Så, i JIRA skulle det vara att skapa en fråga av typen ” Insekt ”.
# 2) Felrapportering behöver följande information registreras för varje problem:
- Fel-ID
- Defekt titel
- Defektbeskrivning (steg för att reproducera)
- Miljöinformation
- Skärmdump (bilaga)
- Allvarlighetsgrad
- Tilldela det till någon
- Status- Alla statusar i bugens livscykel
Alla alternativ är tillgängliga för att effektivt kunna skapa en defekt.
Observera fälten markerade i rött nedan:
De två fälten du inte ser här är:
- Fel-ID
- Status
Dessa två fält skapas automatiskt av JIRA. Alla nummer kommer att ha ett unikt ID tilldelat av JIRA. Status för alla problem är 'Att göra' eller 'Nytt' i JIRA som standard när du skapar ett fel.
hur man öppnar .bin-filer
Därför, alla vanliga faciliteter för rapportering av fel finns också i JIRA. Faktum är att fler alternativ som etiketter, länkfel, uppskattningsinsatser kan användas.
# 3) Defekt livscykel:
Alla livscykelstatus för buggar som i Bugzilla (eller någon annan populär bug tracker ) kan uppnås här också:
Detta kommer att behöva anpassas lite av din JIRA-administratör, men det är lätt att göra. För dem vill du inte bry dig om anpassningen, du kan inte gå fel med standardinställningen också.
# 4) Kommentarer och samarbete med Dev Team
Varje utgåva, dess uppdateringar, personaluppdrag, kommentarer från Dev-teamet - allt spåras i JIRA under aktivitetsloggen.
Detta möjliggör bättre synlighet och samarbete med utvecklingsteamen:
# 5) Länka defekten till ett krav för att möjliggöra spårbarhet
Länkalternativ i JIRA-utfältsfältet låter dig länka en viss fråga till en annan. Låt oss säga att om Defekt 2 är en duplikat av Defekt 1 kan du skapa den relationen.
På samma sätt, om en defekt blockerar ett krav eller är relaterad till ett krav - kan du göra denna aspekt synlig i JIRA.
De resulterande länkarna kommer att visas på informationssidan för frågan nedan:
Relationstyperna är självförklarande och användningen av enkelt-vanligt-vardagsspråk ord (som relaterar till, orsakade av, etc.) gör det super enkelt och intuitivt för alla JIRA-användare att använda denna rättighet.
# 6) Fel kan importeras från en CSV-fil
Detta hjälper till att skapa problem i JIRA på en gång. Om ditt team är nytt och du inte vill att de ska skapa problem direkt i verktyget kan du låta dem rapportera bristerna i ett Excel-ark. När de har granskats och bekräftats som giltiga kan de importeras på en gång till verktyget med hjälp av denna funktion.
Oavsett hur du använder det är det här ett stort plus.
# 7) Defekter kan exporteras till Word-, XML- och utskrivbara format
Detta stöder bättre portabilitet av dina defektdata, särskilt användbart om du vill dela dina defektdata med personer som inte är JIRA-användare.
# 8) Omfattande utredningsrapporter:
Dessutom, om du behöver rapporter gå till “ Projekt - rapporter ”Och generera alla typer av rapporter enligt nedan:
Om vi måste granska JIRAs analys i ett ord är det fantastiskt.
Avancerade / kraftanvändare av JIRA kan också skapa avancerade sökfilter för att skapa djupare insikter.
Till exempel, om du vill titta på alla defekter som tilldelats dig i flera projekt (BM och AB), kan du använda en JQL-fråga som nedan:
Så allt som allt, bug tracking / defect management i JIRA är mycket lika om inte överlägsen dedikerade bug trackers. Oroa dig inte nästa gång du måste arbeta med det. Du är i goda händer.
Tillämpningen av JIRA på testning - ett alternativt dilemma
Även om detta är ena sidan av myntet, finns det definitivt en annan dimension i hur människor ser JIRAs tillämpbarhet på QA eller testning.
När du frågar en grupp QA: ”Vad är JIRA?” - Många kommer att svara att JIRA är ett verktyg för defektspårning. Jag har hört detta från många senior QA-proffs. Detta kan bero på att defekthantering / spårning är allt de kan ha använt JIRA för.
Men det finns mycket mer. När det används rätt kan JIRA-kärnan med sina smidiga funktioner vara din one-stop-shop för högnivåprojektledning.
Det kan verkligen stödja kravspårning och framsteg, bugspårning, uppskattning, sprintspårning via SCRUM & KANBAN-kort, rapportering och samarbete.
Du kanske använder ett verktyg för en sak, men nästa gång försöker du lära dig några saker runt och om verktyget som hjälper dig att förstå och använda det bättre.
Så som nästa steg, du kan utforska några andra coola funktioner i JIRA (som kanske inte är direkt relaterade till felspårning) som kan göra det till ditt val.
- Anpassningsbara instrumentpaneler
- Testhanteringstillägg
- Rösta och titta på ett problem
- Tidsuppföljning
- Agile Project och Scrum boards
- Integration av sammanflytande / dokumentation etc.
Skapa ett Jira-nummer och olika fält
Jira Issues: Olika typer av Jira Issues
Jira ger dig väldigt enkla sätt att skapa / logga problem.
Det tillåter oss inte bara att skicka fel men gör det också möjligt för oss i andra typer av 'biljetter' eller 'förfrågningar'. Det är mer en allmän ansökan om hantering av begäranden.
Denna handledning kommer att förklara mer om frågestyper i Jira, skapa ett problem, olika fält på sidan 'Skapa nummer' och deras detaljer i enkla termer med bildrepresentation för din enkla förståelse.
Jira-frågor
Olika organisationer kan ha olika typer av frågor beroende på deras lämplighet / behov. En Jira-administratör kan effektivt anpassa detta fält.
Problem kan vara av olika slag och nedan ges beskrivningen / betydelsen av frågestyper:
- Insekt: Detta är alla fel eller avvikelser som finns i applikationen.
- Förbättringsförfrågan: Det är också känt som en ändringsförfrågan (CR). Denna typ används för att skildra ändringar i befintlig funktionalitet eller helt och hållet en ny funktionalitet.
- Uppgift: Det här är mer en konfigurations- eller analysproblem. Till exempel , att ställa in rätt konfigurationer kan vara en uppgift.
- Fråga: Problemet kan vara så enkelt som att ställa en fråga om hur man använder en del funktioner i applikationen. Denna typ används oftare av slutkunderna.
- Episk: Detta är normalt en enorm fråga som helst är uppdelad i flera små nummer. Det kan ta flera sprints för att fullborda den episka huvudfrågan i en smidig miljö.
- Finansiellt objekt: Ofta använder projekt- / produkthantering denna typ av frågor för att spåra deras ekonomi.
- Berättelse: Hela användarberättelsen om en funktion kan vara en typ av problem.
- Testfall : Problemet kan vara ett testfall. Denna typ av problem kommer att finnas tillgängligt när Jira har integrerats med plugin-program som Zypher.
Skapa ett problem
Förutsatt att en användare har loggat in på Jira och önskat projekt.
Steg 1:
Klicka på knappen '+' ('Skapa') i verktygsfältet.
Detta visar en skärm / sida som visas i bilden nedan:
På den här sidan väljer du projekt och typ av fråga / begäran och klickar sedan på knappen ”Nästa”.
Detta öppnar sidan 'Skapa problem' som visas i följande bilder:
Steg 2:
Ange obligatoriska detaljer och andra uppgifter så mycket som möjligt på sidan ”Skapa problem”.
Steg 3:
Klicka på knappen ”Skapa”. Detta genererar ett unikt problem-ID. ID består av projektidentifierare sammanfogad med numeriska siffror.
I ovanstående exempel är det valda projektet 'TestProject', varför ID kan vara som 'TESTPROJ1234'.
- När problemet har skapats kan det därefter sökas med hjälp av problem-ID.
Beskrivning av fält på sidan ”Skapa problem”
(Skapa sidor med bilder är uppdelade i tre delar för bättre läsbarhet).
Notera :Jira-administratör och / eller utvecklare kan lägga till / ta bort anpassade fält beroende på organisationens behov.
# 1) Sammanfattning :
Detta kallas också oftare som titeln på utgåvan och är ett mycket viktigt fält i en Jira-utgåva.
Titeln ska vara så unik och exakt som möjligt så att frågan kan förstås genom att titta på själva titeln. Detta hjälper felgranskningskortet och / eller produktägare att prioritera och tilldela problemet utan att titta djupt in i det.
# 2) Komponent / er :
Namn på modulen eller området i applikationen där defekten upptäcks i fallet med problemtypen ”Bug”.
Det kan vara det område där ändringarna krävs i händelse av en CR. Detta är vanligtvis en rullgardinsmeny som består av olika moduler / komponenter som finns i applikationen. Projektperson måste hämta den från administratören.
# 3) Beskrivning :
Typiskt bör innehålla stegen för att reproducera problemet om problemet är fel.
I händelse av en förbättringsbegäran bör det beskrivas om det nya kravet som vanligtvis kallas en berättelse i den agila terminologin. Helst bör detta fält uppdateras regelbundet under arbetsflödet.
# 4) Fixa versioner :
Namnet på den version där begäran om utfärdande / förbättring kommer att levereras. Detta värde fylls vanligtvis av produktägaren i samordning med scrummastern i en smidig scrummiljö.
# 5) Prioritet :
Det här fältet anger problemet.
Det kan vara en utställningspropp, vilket innebär att applikationstest inte kan fortsätta i en testfas. En applikations krasch är ett ideal Exempel av en 'Show Stopper' (kritisk) fråga.
Felgranskningskortet och produktägarna har all rätt att ändra prioriteringen av frågan. Det här fältet är en listruta med värden som 'Låg', 'Medium' ('Major'), 'Kritisk', 'Trivial' etc.
# 6) Etiketter :
Detta fält anges med texterna som hjälper till att kategorisera frågor.
# 7) Miljö :
Detta är ett valfritt fält och testmiljön anges här.
# 8) Bilaga :
Stödjer bilder för det problem som skapas. Användaren kan helt enkelt dra och släppa bilder eller kopiera och klistra in.
# 9) Påverkar version / er :
För en “bug” -typ bör produktversionen anges här.
Till exempel 5.6, 5.7 etc.
# 10) Länkade problem :
Andra relevanta frågor kan kopplas till den nya utgåvan genom att välja ett riktigt värde från den här rullgardinsmenyn.
Till exempel, om problemet introduceras genom en fix av något annat problem, kan värdet som ska väljas från rullgardinsmenyn vara 'Introduced By'. Det här fältet blir extremt viktigt om en ny defekt utlöses av någon fix eller förbättring.
=> Utgåva : Efter att ha valt ett korrekt värde i ”Länkade problem” nämns relevant problem-ID här.
# 11) Tilldelad :
Det är namnet på användaren som kommer att arbeta med problemet.
Till exempel, i händelse av ett fel, kommer det att vara namnet på utvecklaren som kommer att åtgärda problemet. Detta fält fylls vanligtvis av produktägaren eller scrummastern. Återigen vem som tilldelar frågan kan variera från en organisation till en annan.
=> Om du klickar på ”Tilldela till mig” (i det högra hörnet av fältet ”Tilldelad”) tilldelas problemet till den inloggade användaren.
# 12) Episk länk :
Välj relevant länk till epiken.
# 13) Sprint :
Sprintens namn väljs här, vilket indikerar när frågan kommer att bearbetas. Det kan bli en framtida sprint enligt produktägaren.
# 14) Team :
Det kan finnas olika team i en smidig miljö. Frågan tilldelas ett av lagen. Denna uppgift görs vanligtvis av produktägaren eller scrummastern i samordning med produktägaren.
# 15) Uppskattning i början :
Det här fältet anger hur mycket tid som krävs för att lösa problemet.
Oftare kallas 'guesstimate'. Detta kommer också att bestå av de nödvändiga testinsatserna. Det kan nämnas i timmar / dagar / veckor eller berättelsespoäng. I en smidig miljö under sprintplanering når hela teamet en gemensam gissning.
# 16) Reporter :
Detta arkiveras automatiskt av Jira med namnet på den inloggade användaren.
Notera: Vi kan ha några andra anpassade fält som nedan (som inte visas i bilderna ovan):
(i) Miljötyp :
Indikerar om en defekt upptäcks i en test- eller produktionsmiljö.
Fältvärdena kan variera från organisation till organisation. Om Jira används för att skapa problem endast internt i organisationen och inte av slutkunder, kanske det här fältet inte existerar alls.
(ii) Reproducerbart :
Är defekten reproducerbar? Det här fältet kommer inte att vara tillgängligt för någon annan typ av problem än ett fel.
(iii) Kund :
Det här fältet anger slutkunden som har registrerat problemet. I vissa organisationer där Jira endast används för intern problemhantering finns det kanske inte detta fält.
Notera: Alla ovan beskrivna fält tillhör fliken 'Fält' på sidan 'Skapa problem', vilket vanligtvis är standardfliken. Sidan kan anpassas för att ha fler flikar som ”Dokumentation” etc. som vi kommer att täcka i våra efterföljande handledning.
Jira ger oss ett effektivt sätt att hantera de olika typerna av frågor enkelt och effektivt.
Med många anpassningar som är möjliga nuförtiden har Jira blivit det mest populära valet.
Hur hanteras frågor i JIRA
Arbeta med JIRA-problem - Hur man loggar defekter i JIRA
Låt oss gå vidare till att skapa ett problem, förutsatt att användaren inloggad inte är administratör och vårt testprojekt är 'Test för STH' med komponenter - Modul 1 och Modul 2, versioner - version 1 och version 2. Nyckel - TFS är redan skapad.
Skapa ett JIRA-nummer
Problem utgör kärnan i JIRA, så för att skapa dem finns det ett alternativ direkt i menyraden:
Klicka på knappen 'Skapa problem'. Alternativt, när du skriver “c” medan du är på JIRA-sidan, öppnas följande ”Skapa problem” -dialog.
Alla fälten på denna sida är självförklarande. Vi kommer att diskutera den viktigaste nedan.
Projekt : Varje fråga tillhör ett projekt. Du kan välja samma genom att klicka på rullgardinsmenyn och välja det projekt som du vill att detta nummer ska tillhöra.
Problemstyp :Det här fältet visar alla typer av problem som kan skapas och spåras via JIRA. Följande alternativ är tillgängliga i den här listan (listan kan variera beroende på inställningen som administratören har ställt in):
Artiklarna Bug, ny funktion, uppgift, förbättring är exakt vad deras namn antyder. Epik och berättelse är mer relevanta för de smidiga projekten. En berättelse är ett krav i Agile som måste spåras från början till slut. En episk är en grupp berättelser.
Välj frågestyp efter behov. Jag ska gå med 'Bug'.
Sammanfattning : Ge ditt fel en titel här. När det används rätt kan detta fält vara mycket framgångsrikt när det gäller att överföra mycket kritisk information. Några aspekter att notera här:
En bugg / defekt är i grunden något som inte är rätt. Det rätta sättet att närma sig en buggtitel är att kortfattat definiera ”vad som är fel”.
Ett exempel av en dålig titel / sammanfattning är ”Det borde finnas ett alternativ för att rensa innehållet på skärmen”. När jag läser detta kommer min första reaktion att vara - ”Okej, det borde finnas - men vad är problemet här? Finns alternativet inte alls? Eller är alternativen närvarande och rensar inte innehållet? ”
Det är också överens om att när jag öppnar detta fel och undersöker det i detalj är jag säker på att jag hittar svaret på den här frågan.
Tyngdpunkten här är dock att använda detta 'Sammanfattningsfält' på det mest effektiva sättet. Därför skulle en mycket lämplig sammanfattning / titel vara 'Alternativet att rensa innehållet på heminloggningssidan rensar inte fälten när du klickar på.'
I det begränsade utrymmet som detta fält ger, försök att skriva din titel på ett sätt som kommunicerar det exakta problemet utan tvetydighet.
Prioritet : Det här fältet kan ta ett av följande värden.
Välj ett lämpligt alternativ för din bugg.
Med sätta t : Den här listan visar komponenterna i projektet. Välj på lämpligt sätt.
Berörd version och fixversion: Dessa två fält visar vilka versioner som är tillgängliga för projektet. Det är inte nödvändigt att en viss fråga som du stött på i en viss version fixas i samma. I sådana fall kan du välja den berörda versionen som den aktuella versionen och fixversionen som nästa.
Dessa fält kan också ta flera värden. Du kan välja att ange att ett visst problem påverkar både version 1 och version 2 enligt nedan:
Tilldelad : Du kan skriva in namnet på den person till vilken frågan ska överlämnas vidare. Du kan också tilldela en fråga till dig själv.
Beskrivning : Detta är ett valfritt textfält som hjälper dig att ange så mycket information som du vill om ditt problem. Vid en insekt är det typiskt att använda detta fält för att ge detaljerad information om stegen för att reproducera defekten.
Det är av yttersta vikt att ge all information.
”Säg, det finns två fält - beroende - stat och stad. När jag väljer Stat i listrutan ska det i fältet Stad visa respektive städer i den stat jag valde.
Om jag tog upp ett fel som 'Städerna är tomma för vissa stater valde jag'. Beskrivningsfältet är platsen för mig att utarbeta denna defekt.
Ett exempel på en otillräcklig beskrivning är:
1) Gå in på webbplatsen
2) Klicka på adressidan
3) Ange övriga detaljer som namn, gatuadress etc.
4) Klicka på rullgardinsmenyn ”Stat”. Välj ett tillstånd
5) Klicka på rullgardinsmenyn ”Stad” - notera stadens namn
Ovanstående beskrivning, även om den är exakt, är den inte fullständig. När det gäller detta fält är det på sidan att ge för mycket information men inte för lite.
Om följande steg läggs till i beskrivningen kommer detta vara mer vettigt.
6) Välj staten som 'Kalifornien' och klicka på rullgardinsmenyn 'Stad' - alla stater visas och användaren kan välja en stad efter behov.
7) Välj staten som 'Louisiana' och klicka på rullgardinsmenyn 'Stad' - listan kommer att vara tom.
8) Städerna är tomma för delstaterna New Jersey och Utah.
Så, för att upprepa, ge de exakta stegen, de exakta uppgifterna och all annan information som du tycker är nödvändig för att fylla i detta fält.
Anknytning : Alla stödjande dokument kan laddas upp med ett problem.
När all information har matats in till din tillfredsställelse kan problemet skapas genom att klicka på knappen 'Skapa' i slutet av dialogen 'Skapa problem'.
Problemet skapas och ett meddelande visas för användaren med problem-ID:
Obs! Lägg märke till problem-ID: t; det föregås av projektets “nyckel”. Det är JIRAs sätt att spåra / gruppera de frågor som hör till ett visst projekt.
Du kan nu visa det skapade problemet genom att klicka på länken som visas i ovanstående meddelande.
Ytterligare information om sidan Skapa problem
1) Det kommer att finnas ett alternativ för konfigureringsfält i det övre högra hörnet på sidan 'Skapa problem'.
Det här alternativet kan användas för att välja / ändra de fält som du vill se i dialogrutan skapa problem. När ett val har gjorts kommer JIRA att komma ihåg ändringarna för dina efterföljande nummer.
två) Längst ner på sidan 'Skapa problem' finns en 'skapa en annan'
När du väljer det här alternativet och klickar på 'Skapa' - en gång skapas det aktuella problemet; JIRA behåller
Dialogrutan 'Skapa problem' är öppen med Project, Issue-typ och andra fält förutom att sammanfattningen automatiskt har valts enligt de tidigare skapade problemen.
Med det avslutar vi ämnet ”Skapa ett problem i JIRA”.
I nästa Atlassian JIRA-handledning lär vi oss om deluppgifter och hur man använder dem för specifika QA-ändamål.
=> Besök här för fullständiga JIRA-handledningsserier
Över till dig
Nu är det dags att höra från dig. Har du mött några utmaningar med JIRA för att spåra fel?
Tror du att det finns någon vikt för motståndet som testteam har för att anpassa JIRA för defekthantering?
PREV-handledning | NÄSTA självstudie
Rekommenderad läsning
- Backlog Bug Tracking Tool Hands-on Review Tutorial
- GitLab Jira Integration Tutorial
- Jira nedladdning och installation med Jira License Setup
- JIRA-handledning: En fullständig användarguide för JIRA
- JIRA Administration Tutorial: JIRA Admin and User Management
- JIRA och SVN Integration Tutorial
- Fördjupade förmörkningsövningar för nybörjare
- JIRA Agile Tutorial: Hur man använder JIRA effektivt för att hantera agila projekt