Definiera, samla in, sortera och hantera programbuggar i Azure Boards

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Hur spårar och hanterar du defekter i koden? Hur ser du till att programvaruproblem och kundfeedback åtgärdas snabbt för att stödja programvarudistributioner av hög kvalitet? Och hur gör du goda framsteg med nya funktioner och tar itu med din tekniska skuld?

Du behöver minst ett sätt att samla in dina programvaruproblem, prioritera dem, tilldela dem till en teammedlem och spåra förloppet. Och du vill hantera dina kodfel på ett sätt som överensstämmer med dina agila metoder.

För att stödja dessa scenarier tillhandahåller Azure Boards en specifik typ av arbetsobjekt för att spåra kodfel med namnet Bugg. Buggarbetsobjekt delar alla standardfunktioner i andra typer av arbetsobjekt med några fler. En översikt över standardfunktioner finns i Spåra arbete med användarberättelser, problem, buggar, funktioner och epos.

Buggar innehåller också följande ytterligare funktioner:

• Alternativ för varje team att välja hur de vill spåra buggar
• Testverktyg för att fånga buggar
• Inbyggd integrering i Azure DevOps för att spåra buggar som är länkade till byggen, versioner och tester

Kommentar

Felarbetsobjekttyper är inte tillgängliga med Basic-processen. Basic-processen spårar buggar som problem och är tillgänglig när du skapar ett nytt projekt från Azure DevOps Services eller Azure DevOps Server 2019.1 eller senare versioner.

Förutsättningar

• Du måste läggas till i ett projekt.
• Om du vill visa eller ändra arbetsobjekt måste du ha behörigheten Visa arbetsobjekt i den här noden och Redigera arbetsobjekt i den här nodbehörigheten inställd på Tillåt. Som standard har gruppen Deltagare den här behörighetsuppsättningen . Mer information finns i Ange behörigheter och åtkomst för arbetsspårning.
• Om du vill lägga till nya taggar som ska läggas till i arbetsobjekt måste du ha grundläggande åtkomst eller högre och ha behörigheten Skapa ny taggdefinition på projektnivå inställd på Tillåt. Som standard har gruppen Deltagare den här behörighetsuppsättningen . Även om behörigheten uttryckligen har angetts för en intressent har de inte behörighet att lägga till nya taggar, eftersom de är förbjudna via sin åtkomstnivå. Mer information finns i Snabbreferens för intressentåtkomst.
• Alla projektmedlemmar, även medlemmar i gruppen Läsare , kan skicka e-postmeddelanden som innehåller arbetsobjekt.

Dricks

För att rapportera ett fel måste en användare ha minst, Intressentåtkomst och Redigera arbetsobjekt i den här nodens behörighet inställd på Tillåt för den områdessökväg där de lägger till buggen. Mer information finns i Ange behörigheter och åtkomst för arbetsspårning

Typ av buggarbetsobjekt

Följande bild visar typ av buggarbetsobjekt för Scrum-processen. Typ av buggarbetsobjekt för Agile- och CMMI-processer spårar liknande information. Den är utformad för att visas i produktloggen tillsammans med krav eller på Aktivitetstavlan tillsammans med uppgifter.

Kommentar

De bilder du ser från webbportalen kan skilja sig från de bilder du ser i den här artikeln. Dessa skillnader beror på uppdateringar av webbappen, alternativ som du eller administratören har aktiverat och vilken process som valdes när du skapade projektet – Agile, Basic, Scrum eller CMMI. Basic-processen är tillgänglig med Azure DevOps Server 2019 Update 1 och senare versioner.

Fält som är specifika för buggar

Typ av buggarbetsobjekt använder vissa felspecifika fält. Om du vill samla in både det inledande problemet och pågående identifieringar använder du fälten som beskrivs i följande tabell. Information om fält som är specifika för buggen som definierats för CMMI-processen (Capability Maturity Model Integration) finns i Fältreferens för buggar, problem och risker. Information om alla andra fält finns i Index för arbetsobjektfält.

---

Fält, grupp eller flik

Användning

---

Steg för att återskapa
(eget namn=Repro-steg)

Använd för att samla in tillräckligt med information så att andra teammedlemmar fullt ut kan förstå kodfelet. Inkludera åtgärder som vidtas för att hitta eller återskapa felet och förväntat beteende.

---

Systeminformation
Finns i build

Information om den programvaru- och systemkonfiguration som är relevant för buggen och testerna som ska tillämpas. Fälten Systeminformation och Hitta i Bygg fylls automatiskt i när du skapar en bugg via ett testverktyg. De här fälten anger information om programvarumiljön och skapar var felet inträffade. Mer information finns i Testa olika konfigurationer.

---

Godkännandekriterier

Ange de kriterier som ska uppfyllas innan felet kan stängas. Innan arbetet börjar ska du beskriva kundens acceptanskriterier så tydligt som möjligt. Teams bör använda det här kriterierna som grund för godkännandetester och för att utvärdera om ett objekt har slutförts på ett tillfredsställande sätt.

---

Integrerad i build

Anger namnet på bygget som innehåller koden som åtgärdar felet. Det här fältet bör anges när du löser felet. För lokala Azure DevOps, för att få åtkomst till en nedrullningsbara meny med alla versioner som har körts, kan du uppdatera FIELD definitionerna för Found in Build and Integrated in Build för att referera till en global lista. Den globala listan uppdateras automatiskt med varje version som körs. Mer information finns i Fråga baserat på bygg- och testintegreringsfält.
Information om hur du definierar versionsnummer finns i formatalternativ för versionsnummer.

---

Prioritet¹

• 1: Produkten kräver en lyckad lösning av arbetsuppgiften innan den levereras och åtgärdas snart.
• 2: Produkten kräver en lyckad lösning av arbetsobjektet innan den levereras, men behöver inte åtgärdas omedelbart.
• 3: Lösning av arbetsobjektet är valfritt baserat på resurser, tid och risk.

---

^{Allvarlighetsgrad 1}

En subjektiv klassificering av effekten av en bugg eller ett arbetsobjekt på projektet eller programvarusystemet. Till exempel: Om en fjärrlänk i användargränssnittet – en sällsynt händelse – gör att ett program eller en webbsida kraschar – en allvarlig kundupplevelse kan du ange Allvarlighetsgrad = 2 – Hög och Prioritet = 3. Tillåtna värden och föreslagna riktlinjer är:

• 1 – Kritisk: Måste åtgärdas. En defekt som orsakar avslutning av en eller flera systemkomponenter eller hela systemet, eller som orsakar omfattande dataskador. Och det finns inga godtagbara alternativa metoder för att uppnå nödvändiga resultat.
• 2 – Hög: Överväg att åtgärda. En defekt som orsakar avslutning av en eller flera systemkomponenter eller hela systemet, eller som orsakar omfattande dataskador. Det finns dock en godtagbar alternativ metod för att uppnå nödvändiga resultat.
• 3 – Medel: (standard) En defekt som gör att systemet ger felaktiga, ofullständiga eller inkonsekventa resultat.
• 4 - Låg: En mindre eller kosmetisk defekt som har godtagbara lösningar för att uppnå nödvändiga resultat.

---

Distribution

Distributionskontrollen stöder länkar till och visning av versioner som innehåller arbetsobjekt. Om du vill använda kontrollen måste du aktivera inställningar för versionen. Mer information finns i Länka arbetsobjekt till versioner senare i den här artikeln.

---

Utveckling

Utvecklingskontrollen stöder länkar till och visning av länkar till utvecklingsobjekt. Dessa objekt inkluderar Git-incheckningar och pull-begäranden eller TFVC-ändringsuppsättningar och versionsobjekt. Du kan definiera länkar från arbetsobjektet eller från incheckningar, pull-begäranden eller andra utvecklingsobjekt. Mer information finns i Länka arbetsobjekt till utveckling senare i den här artikeln.

---

Anteckningar:

¹ Om du vill ändra menyval eller listruta läser du Anpassa arbetsspårningsupplevelsen. Anpassningsmetoden beror på vilken processmodell som används av projektet.

Välj hur ditt team spårar buggar

Ditt team kan spåra buggar som krav eller som uppgifter. Tänk på följande faktorer för att stödja teamets val.

• Storleken på ditt team. Mindre team kan upprätthålla ett lättviktsavtryck genom att spåra buggar som krav.
• Organisationskrav för att spåra arbete. Om ditt team måste spåra timmar väljer du att spåra buggar som uppgifter.
• Hur ditt team organiserar arbetet. Om ditt team förlitar sig på produkteftersläpningen för att prioritera arbete och lägga till buggar kan du spåra buggar som krav.
• Verktyg som ditt team vill använda, till exempel planeringsfönstret, hastighetsdiagram, prognos, sammanslagning och leveransplaner. Spårning av buggar som uppgifter förhindrar användning av flera av dessa verktyg.

I följande tabell sammanfattas de tre alternativ som teamen har för att spåra buggar. Mer information och om du vill ange alternativet för ditt team finns i Visa buggar i kvarvarande uppgifter och tavlor.

---

Alternativ

Välj när du vill...

---

Spåra buggar som krav

• Prioritera buggar (stackrank) tillsammans med krav
• Beräkna buggarbete för prognostisering
• Uppdatera felstatus på Kanban-tavlan
• Inkludera buggar i hastighetsdiagram och kumulativa flödesdiagram
• Kan använda prognosverktyget för att stödja sprintplanering
• Kan dra och släppa buggar till planeringsfönstret för att tilldela buggar till en sprint
• Kan visa buggar i leveransplaner

Kommentar

• Buggar tilldelas till kravkategorin

---

Spåra buggar som uppgifter

• Beräkna arbete för buggar som liknar uppgifter
• Uppdatera felstatus på sprint Taskboards
• Länka buggar till krav som underordnade objekt
• Kan dra och släppa buggar till planeringsfönstret för att tilldela buggar till en sprint

Kommentar

• Buggar tilldelas till aktivitetskategorin
• Användarberättelser (agil), produktpost för kvarvarande uppgifter (Scrum) eller krav (CMMI) är den naturliga överordnade arbetsobjekttypen för buggar
• Buggar visas inte i leveransplaner

---

Buggar visas inte i kvarvarande uppgifter eller tavlor

• Hantera buggar med hjälp av frågor

Kommentar

• Buggar är associerade med buggkategorin och visas inte på några kvarvarande uppgifter eller tavlor
• Buggar visas inte i kvarvarande uppgifter, tavlor, sprint-kvarvarande uppgifter, uppgiftstavlor eller leveransplaner
• Det går inte att dra och släppa buggar till planeringsfönstret för att tilldela buggar till en sprint

---

Anpassa typ av arbetsobjekt

Du kan anpassa buggen och andra typer av arbetsobjekt. Eller skapa anpassade typer för att spåra programvaruproblem eller kundfeedback. Med alla typer av arbetsobjekt kan du anpassa följande element:

• Lägga till eller ta bort anpassade fält
• Lägga till anpassade kontroller eller anpassade flikar i arbetsobjektsformuläret
• Anpassa arbetsflödestillstånden
• Lägga till villkorsstyrda regler
• Välj den kvarvarande nivå där arbetsobjekt visas

Innan du anpassar processen rekommenderar vi att du läser Konfigurera och anpassa Azure Boards.

Information om hur du anpassar din process finns i Anpassa en arvsprocess.

Lägga till eller samla in buggar

Du kan definiera buggar från flera olika Azure DevOps-verktyg. Dessa omfattar kvarvarande uppgifter och tavlor och testverktyg.

Dricks

Som standard är fältet Rubrik det enda obligatoriska fältet när du skapar en bugg. Du kan snabbt lägga till buggar på samma sätt som du lägger till användarberättelser eller produktloggobjekt med hjälp av Azure Boards. Om du vill göra vissa fält obligatoriska gör du det genom att lägga till villkorsregler baserat på en tillståndsändring. Mer information finns i Lägga till en regel i en typ av arbetsobjekt (arvsprocess).

Lägga till en bugg från din kvarvarande eller bräde

Om ditt team väljer att hantera buggar med krav kan du definiera buggar från din produkts kvarvarande uppgifter eller Kanban-tavlan. Mer information finns i Skapa din produkteftersläpning eller Börja använda din Kanban-tavla.

• Lägga till en bugg från produktloggen

  

• Lägga till en bugg från produktloggen

  

Dricks

När du lägger till en bugg från din produkts kvarvarande uppgifter eller Kanban-anslagstavlan tilldelas felet automatiskt den standardområdessökväg och iterationssökväg som definierats för teamet. Mer information finns i Teamstandarder som refereras till av kvarvarande uppgifter och tavlor.

Lägga till en bugg från din sprint-kvarvarande uppgifter eller Aktivitetstavla

Om ditt team väljer att hantera buggar med uppgifter kan du definiera buggar från din Kanban-tavla, produktpostlogg, sprint-kvarvarande uppgifter eller Sprint Taskboard. Du lägger till en bugg som ett underordnat objekt i ett arbetsobjekt för produkteftersläpning.

• Lägga till en länkad underordnad bugg från Kanban-tavlan
  Du lägger till en bugg på samma sätt som du lägger till en uppgift i ett kvarvarande objekt. Mer information finns i Lägga till uppgifter eller underordnade objekt som checklistor.

  

• Lägga till en länkad underordnad bugg från Sprint-kvarvarande uppgifter
  Du lägger till en bugg på samma sätt som du lägger till en uppgift i en sprint-kvarvarande uppgifter. Mer information finns i Lägga till uppgifter i kvarvarande uppgifter.

  

Skapa en bugg från ett testverktyg

De två testverktyg som du kan använda för att lägga till buggar vid testning är testkörare för webbportalen och tillägget Test & Feedback.

• Test Runner: När du kör manuella tester kan du välja Skapa bugg. Mer information finns i Köra manuella tester.

  

• Test- och feedbacktillägg: När du kör undersökande tester kan du välja Skapa bugg eller Skapa uppgift. Mer information finns i Undersökande testning med test- och feedbacktillägget

Tillstånd för bugglivscykel och arbetsflöde

Precis som med alla andra typer av arbetsobjekt har typen Felarbetsobjekt ett väldefinierat arbetsflöde. Varje arbetsflöde består av tre eller flera tillstånd och en orsak. Orsaker anger varför objektet övergick från ett tillstånd till ett annat. Följande bilder illustrerar standardarbetsflödet för buggar som definierats för processerna Agile, Scrum och CMMI .

Flexibel	Scrum	CMMI

För Scrum-buggar ändrar du tillståndet från Bekräftat (liknar Aktivt) till Klar. För Agile och CMMI löser du först felet och väljer en orsak som anger att felet är åtgärdat. Vanligtvis verifierar personen som skapade buggen korrigeringen och uppdaterar tillståndet från Löst till Stängt. Om mer arbete har hittats efter att ett fel har lösts eller stängts kan du återaktivera det genom att ange Tillståndet till Bekräftat eller Aktivt.

Kommentar

Arbetsobjekttypen Agile process bug tidigare hade en regel som omtilldelade buggen till den person som skapade den. Den här regeln har tagits bort från standardsystemprocessen. Du kan återställa den här automatiseringen genom att lägga till en regel. En arvsprocess finns i Tillämpa regler för arbetsflödestillstånd, Automatisera omtilldelning baserat på tillståndsändring.

Verifiera en korrigering

För att verifiera en korrigering försöker en utvecklare eller testare återskapa felet och leta efter mer oväntat beteende. Om det behövs bör de återaktivera felet.

När du verifierar en felkorrigering kan det hända att felet inte har åtgärdats eller att du inte håller med om lösningen. I det här fallet ska du diskutera buggen med den person som löste den, komma överens och eventuellt återaktivera buggen. Om du återaktiverar en bugg ska du ta med orsakerna till att återaktivera felet i felbeskrivningen.

Stäng en bugg

Du stänger en bugg när den har verifierats som åtgärdad. Men du kan också stänga en bugg av någon av följande orsaker. Vilka orsaker som är tillgängliga för att välja beror på projektprocessen och felövergångstillstånden.

Flexibel process:

• Uppskjuten: Skjut upp felkorrigeringen till nästa produktversion.
• Åtgärdat: Buggen har verifierats som åtgärdad.
• Duplicera: Bugg spårar en annan bugg som för närvarande har definierats. Du kan länka varje bugg med länktypen Duplicera/Duplicera och stänga en av buggarna.
• Som den är utformad: Funktionen fungerar som den är utformad.
• Det går inte att återskapa: Tester visar att felet inte kan återskapas.
• Föråldrad: Buggens funktion finns inte längre i produkten.
• Kopierad till kvarvarande uppgifter: En användarberättelse har öppnats för att spåra felet.

Scrum-process:

• Inte en bugg: Buggen är verifierad att den inte är en bugg.
• Duplicera: Bugg spårar en annan bugg som för närvarande har definierats. Du kan länka varje bugg med länktypen Duplicera/Duplicera och stänga en av buggarna.
• Har tagits bort från kvarvarande uppgifter: Buggen har verifierats att den inte är en bugg. Ta bort buggen från kvarvarande uppgifter.
• Arbetet har slutförts: Buggen har verifierats som åtgärdad.

CMMI-process:

• Uppskjuten: Skjut upp felkorrigeringen till nästa produktversion.
• Duplicera: Bugg spårar en annan bugg som för närvarande har definierats. Du kan länka varje bugg med länktypen Duplicera/Duplicera och stänga en av buggarna.
• Avvisad: Buggen har verifierats att den inte är en bugg.
• Verifierad: Buggen har verifierats som åtgärdad.

Dricks

När en bugg har stängts och korrigeringen har släppts aktivt i distributioner rekommenderar vi att du aldrig öppnar den igen på grund av regression. I stället bör du överväga att öppna en ny bugg och länka till den äldre, stängda buggen.

Det är alltid en bra idé att beskriva mer information om hur du stänger en bugg i fältet Diskussion för att undvika framtida förvirring om varför buggen stängdes.

Automatisera buggstängning vid sammanslagning av pull-begäranden

Om ditt team använder en Git-lagringsplats kan du ange tillståndet i länkade buggar och andra arbetsobjekt för att stänga vid lyckad sammanslagning av pull-begäranden. Mer information finns i Ange arbetsobjekttillstånd i pull-begäran senare i den här artikeln.

Lista och sortera buggar

De flesta team, oavsett vilket alternativ de valde för att spåra buggar, definierar en eller flera buggfrågor. Med frågor kan du lista aktiva buggar, otilldelade buggar, inaktuella buggar, buggtrender med mera. Du kan sedan lägga till frågor och frågediagram i teamets instrumentpaneler för att övervaka buggstatus och förlopp.

Buggfrågor

Öppna en delad fråga eller använd frågeredigeraren för att skapa användbara felfrågor, till exempel följande alternativ:

• Aktiva buggar efter prioritet (State <> Done eller State <> Closed)
• Pågående buggar (State = Committed eller State = Active)
• Buggar som ska åtgärdas för en målversion (Tags Contains RTM)
• Senaste buggar – buggar som öppnats under de senaste tre veckorna (Created Date > @Today-21)

När du har frågor av intresse för ditt team kan du skapa status- eller trenddiagram. Du kan också lägga till diagrammet som du skapar på en instrumentpanel.

Sorteringsläge i frågeresultat

När du har börjat koda och testa vill du hålla regelbundna triagemöten för att granska och rangordna dina buggar. Vanligtvis kör projektägaren buggtriagemötena. Teamledare, affärsanalytiker och andra intressenter som kan tala om specifika projektrisker deltar i triagemötena.

Projektägaren kan definiera en delad fråga för nya och öppnade buggar för att lista buggar som ska sorteras.

Från frågeresultatsidan kan du snabbt flytta upp och ned i listan över felarbetsobjekt med hjälp av uppåt- och nedåtpilarna. När du granskar varje bugg kan du tilldela den, lägga till information eller ange prioritet.

Organisera och tilldela buggar till en sprint

Om ditt team spårar buggar som krav kan du visa listan över aktiva buggar från dina kvarvarande uppgifter. Med filterfunktionen kan du fokusera enbart på buggar. Från kvarvarande produktuppgifter kan du också utföra följande uppgifter:

• Organisera buggar i din kvarvarande uppgifter, stackrankning mot andra objekt (stackrankning inaktiveras när filtrering är aktiverat)
• Tilldela buggar till en sprint från din kvarvarande information med hjälp av planeringsfönstret
• Överordnade buggar till funktioner eller andra kvarvarande portföljobjekt med hjälp av fönstret Mappning
• Visa sammanslagning av arbete för portföljens kvarvarande uppgifter.

Om ditt team spårar buggar som uppgifter använder du hanterade frågor för att lista och sortera buggar. I varje sprint ser du sedan buggarna som tilldelats sprinten från sprintens kvarvarande uppgifter eller Aktivitetstavla.

Objekt i aktivitetstavlan jämfört med frågelistobjekt

Du kanske märker och undrar varför de objekt som visas på en sprint Taskboard kan skilja sig från en frågelista som skapats i motsvarande sprint-kvarvarande uppgifter.

Det är möjligt att tilldela uppgifter eller buggar till en iteration men inte ha dem länkade till ett överordnat kvarvarande objekt. Dessa objekt visas i den skapade frågan, men kanske inte visas på själva aktivitetstavlan. Systemet kör frågan och tillämpar sedan några bakgrundsprocesser innan objekt i Aktivitetstavla visas.

Dessa orsaker kan göra att arbetsobjekt som tillhör aktivitetskategorin inte visas i en sprint-kvarvarande uppgifter eller i Aktivitetstavla:

• Uppgiften eller buggen har inte länkats till ett överordnat kvarvarande objekt. Endast buggar och uppgifter som du har länkat till ett överordnat produktpost (Scrum), användarberättelse (Agile) eller krav (CMMI) med en iterationssökväg inställd på sprinten visas på sidan med kvarvarande sprintuppgifter.
• Uppgiften eller buggen är överordnad en annan uppgift eller bugg, eller så är användarberättelsen överordnad till en annan användarberättelse. Om du har skapat en hierarki med uppgifter, buggar eller användarberättelser visas endast aktiviteter på underordnade nivåer eller berättelser på undernivå längst ned i hierarkin.
• Aktivitetens eller buggens länkade överordnade motsvarar ett kvarvarande objekt som definierats för ett annat team. Eller så skiljer sig områdessökvägen för aktivitetens eller buggens överordnade kvarvarande uppgifter från aktivitetens eller buggens områdessökväg.

Skapa infogade tester som är länkade till buggar

När ditt team spårar buggar som krav kan du använda Kanban-kortet för att lägga till tester för att verifiera felkorrigeringar.

Uppdatera felstatus

Du kan uppdatera buggstatusen genom att dra och släppa buggar till en ny kolumn på en tavla.

• Om ditt team spårar buggar som krav använder du Kanban-tavlan enligt följande bild. Mer information finns i Kom igång med din Kanban-tavla.

  

• Om ditt team spårar buggar som uppgifter använder du Aktivitetstavlan. Mer information finns i Uppdatera och övervaka din aktivitetstavla.

  

Anpassa ditt bräde för att spåra mellanliggande tillstånd

Du kan lägga till mellanliggande kolumner för att spåra felstatusen på tavlan. Du kan också definiera frågor som filtrerar baserat på statusen för en brädkolumn. Mer information finns i följande artiklar:

• Lägga till kolumner i Kanban-brädet
• Anpassa en sprint-aktivitetstavla
• Kanban-styrelseändringsfrågor

Automatisera omtilldelning av buggar baserat på arbetsflödestillstånd

Om du vill automatisera utvalda åtgärder lägger du till anpassade regler i typen Felarbetsobjekt. Lägg till exempel till en regel som visas i följande bild. Den här regeln anger att en bugg ska tilldelas till den person som öppnade buggen när den har lösts. Normalt verifierar den personen att felet är åtgärdat och stänger buggen. Mer information finns i Tillämpa regler på arbetsflödestillstånd (arvsprocess).

Ange status för arbetsobjekt i pull-begäran

När du skapar en pull-begäran kan du ange tillståndsvärdet för de länkade arbetsobjekten i beskrivningen. Följ syntaxen: {state value}: #ID. När du sammanfogar pull-begäran läser systemet beskrivningen och uppdaterar arbetsobjektets tillstånd. I följande exempel anger vi arbetsobjekt #300 och #301 till Lösta och #323 och #324 till Stängda.

Integrering i Azure DevOps

En av metoderna som används av Azure DevOps för att stödja integrering är att länka objekt till andra objekt. Tillsammans med att länka arbetsobjekt till arbetsobjekt kan du även länka arbetsobjekt till andra objekt. Länka till objekt som byggen, versioner, grenar, incheckningar och pull-begäranden enligt följande bild.

Du kan lägga till en länk från arbetsobjektet eller från bygg- och versionsobjekten.

Länka arbetsobjekt till utveckling

Utvecklingskontrollen stöder länkning till och visning av länkar till byggen, Git-incheckningar och pull-begäranden. Eller när en TFVC-lagringsplats används stöder den länkar till ändringsuppsättningar och versionsobjekt. Om du väljer länken öppnas motsvarande objekt på en ny webbläsarflik. Mer information finns i Drive Git development from a work item (Driva Git-utveckling från ett arbetsobjekt).

Länka arbetsobjekt till versioner

Distributionskontrollen stöder länkar till och visning av versioner som innehåller arbetsobjekten. Följande bild visar till exempel flera versioner som innehåller länkar till det aktuella arbetsobjektet. Du kan expandera varje version för att se information om varje steg. Du kan välja länken för varje version och fas för att öppna motsvarande version eller fas. Mer information finns i Länka arbetsobjekt till distributioner.

Länka arbetsobjekt till pipelinekörningar

Pipelines definieras ofta för att köras automatiskt när en ny incheckning sker till en Git-lagringsplats. Arbetsobjekt som är associerade med incheckningspipelines visas som en del av pipelinekörningen om du anpassar dina pipelineinställningar. Mer information finns i Anpassa din pipeline.

Skapa eller redigera ett arbetsobjekt vid ett byggfel

Om du använder klassiska pipelines (inte YAML) kan du skapa arbetsobjekt vid ett byggfel. Mer information finns i Skapa alternativ, Skapa ett arbetsobjekt om fel.

Övervaka buggstatus, tilldelningar och trender

Du kan spåra buggstatus, tilldelningar och trender med hjälp av frågor som du sedan kan diagram och lägga till på en instrumentpanel. Här är till exempel två exempel som visar aktiva buggtrender efter tillstånd och aktiva buggar efter prioritet över tid.

Om du vill veta mer om frågor, diagram och instrumentpaneler; se Om hanterade frågor och diagram samt instrumentpaneler.

Använda Analysvyer och Analytics-tjänsten för att skapa felrapporter

Analytics-tjänsten är rapporteringsplattformen för Azure DevOps och ersätter den tidigare plattformen baserat på SQL Server Reporting Services.

Analysvyer tillhandahåller fördefinierade filter för att visa arbetsobjekt. Fyra analysvyer stöds för felrapportering. Du kan använda dessa vyer som definierade eller redigera dem ytterligare för att skapa en anpassad, filtrerad vy.

• Buggar – all historik per månad
• Buggar – senaste 26 veckorna
• Buggar – senaste 30 dagarna
• Buggar – idag

Mer information om hur du använder analysvyer finns i Vad är analysvyer och Skapa en rapport om aktiva buggar i Power BI baserat på en anpassad analysvy.

Du kan använda Power BI för att skapa mer komplexa rapporter än vad du kan få från en fråga. Mer information finns i Anslut med Power BI Data Anslut or.

Marketplace-tillägg

Det finns flera buggrelaterade Marketplace-tillägg. Se Marketplace för Azure DevOps.

Mer information om tillägg finns i Azure Boards-tillägg som utvecklats av Microsoft.

Nästa steg

Använda mallar för att lägga till och uppdatera arbetsobjekt

Relaterade artiklar

• Flytta, ändra typ eller ta bort arbetsobjekt
• Kopiera eller klona ett arbetsobjekt

Produkt-kvarvarande uppgifter och Kanban-anslagstavla

• Kvarvarande uppgifter, portföljer och flexibel projekthantering
• Skapa kvarvarande uppgifter
• Definiera funktioner och epos
• Organisera kvarvarande uppgifter, mappa underordnade arbetsobjekt till föräldrar
• Filtrera kvarvarande uppgifter, tavlor, frågor och planer interaktivt
• Prognostisera din produkts kvarvarande uppgifter

Kanban-tavla

• Om boards och Kanban
• Snabbstart för Kanban-tavla
• Ändra ordning på kort
• Lägga till uppgifter eller underordnade objekt som checklistor

Sprint-kvarvarande uppgifter och Aktivitetstavla

• Scrum och arbeta med bästa praxis för sprintar
• Tilldela kvarvarande uppgifter till en sprint
• Lägga till uppgifter
• Uppdatera aktivitetstavlan

Integrering i Azure DevOps

• Länka användarberättelser, problem, buggar och andra arbetsobjekt
• Följ ett arbetsobjekt eller en pull-begäran
• Konfigurera körnings- eller byggnummer

Branschresurser

• Bra och dålig teknisk skuld (och hur TDD hjälper) av Henrik Kniberg
• Managing Technical Debt postat av Sven Johann & Eberhard Wolff