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? Hur gör du goda framsteg med nya funktioner och hanterar 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. Du vill hantera 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 Om arbetsobjekt och typer av arbetsobjekt.

Buggar innehåller också följande 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

• Projektåtkomst: Vara projektmedlem.

• Behörigheter:

  • Om du vill visa, följa och redigera arbetsobjekt har du Visa arbetsobjekt i den här noden och Redigera arbetsobjekt i den här nodens behörigheter inställda på Tillåt. Som standard har gruppen Deltagare dessa behörigheter. Mer information finns i Ange behörigheter för arbetsspårning.

• Om du vill lägga till taggar i arbetsobjekt har du behörigheten Skapa ny taggdefinition på projektnivå inställd på Tillåt. Som standard har gruppen Deltagare den här behörigheten.

• Åtkomstnivåer:

  • Om du vill lägga till nya taggar i arbetsobjekt eller för att visa eller följa pull-begäranden har du minst grundläggande åtkomst.
  • Om du vill visa eller följa arbetsobjekt har du minst intressentåtkomst . Mer information finns i Om åtkomstnivåer.
  • Alla projektmedlemmar, inklusive de i gruppen Läsare , kan skicka e-postmeddelanden som innehåller arbetsobjekt.

  Kommentar

  • Ge intressenterna åtkomst till medlemmar som vill bidra till diskussionen och granska förloppet. Det här är vanligtvis medlemmar som inte bidrar till kod, men som vill visa arbetsobjekt, kvarvarande uppgifter, tavlor och instrumentpaneler.
  • Intressenter kan inte lägga till nya taggar, även om behörigheten uttryckligen har angetts på grund av deras åtkomstnivå. Mer information finns i Snabbreferens för intressentåtkomst.

Dricks

Om du vill rapportera ett fel måste en användare ha minst intressentåtkomst . En användare måste ha behörigheten Redigera arbetsobjekt i den här noden 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 för arbetsspårning

Typ av buggarbetsobjekt

Följande bild visar typ av buggarbetsobjekt för Scrum-processen. Typ av buggarbetsobjekt för CMMI-processer (Agile and Capability Maturity Model Integration) spårar liknande information. Det 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.

---

Systeminformationfinns 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 villkoret 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 kan du uppdatera FIELD definitionerna för Found in Build och Integrated in Build för att referera till en global lista för att få åtkomst till en listmeny med alla versioner som har körts. 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 Konfiguration av klassiska pipelines.

---

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. 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. 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 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.

---

Kommentar

¹ 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.
• Organisation av teamets arbete. 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, eller stackranka, buggar tillsammans med krav
• Beräkna buggarbete för prognostisering
• Uppdatera felstatus ombord
• Inkludera buggar i hastighetsdiagram och kumulativa flödesdiagram
• Kunna använda prognosverktyget för att stödja sprintplanering
• Dra buggar till planeringsfönstret för att tilldela buggar till en sprint
• 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
• Dra 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, aktivitetstavlor eller leveransplaner
• Du kan inte dra 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. För 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 Om att 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 verktyg 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 lägga till buggar på samma sätt som du lägger till användarberättelser eller produktinformation med hjälp av Azure Boards. Du kan göra vissa fält obligatoriska genom att lägga till villkorsregler baserat på en tillståndsändring. Mer information finns i Lägga till en regel i en arbetsobjekttyp.

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 anslagstavlan. Mer information finns i Skapa din produkts kvarvarande uppgifter eller Använd din tavla.

• Lägga till en bugg från produktloggen

  

• Lägga till en bugg från tavlan

  

Dricks

När du lägger till en bugg från din produkts kvarvarande uppgifter eller anslagstavlan tilldelas buggen 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 ditt bräde, dina kvarvarande produktuppgifter, Sprint-kvarvarande uppgifter eller Sprint Taskboard.If your team chose to manage bugs with tasks, you can define bugs from your board, product backlog, Sprint backlog, or 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 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.

  

• Lägga till en länkad underordnad bugg från 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.

  

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 tillägget Test & Feedback.

  

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 du hittar mer arbete när du har löst eller stängt ett fel återaktiverar du 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 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 en gruppmedlem verifierar den som fast. Men du kan också stänga en bugg av någon av följande orsaker. Vilka orsaker som är tillgängliga beror på projektprocessen och tillståndet för buggövergången.

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 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)
• De senaste buggarna, till exempel 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 håller du 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 flytta upp och ned i listan över buggarbetsobjekt 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 dina 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.
• Mappa ö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 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 länka dem 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 är inte länkad till ett överordnat kvarvarande objekt. Endast buggar och uppgifter är länkade 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 skapar en hierarki med uppgifter, buggar eller användarberättelser visas endast aktiviteter på undernivå eller berättelser på undernivå längst ned i hierarkin. Mer information finns i Felsöka problem med omordning och kapsling.
• 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 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 tavlan enligt följande bild. Mer information finns i Uppdatera status för arbetsobjekt.

  

• 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 ditt bräde
• Anpassa en sprint-aktivitetstavla
• Frågeändringar i en tavla

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 felet när en gruppmedlem löser det. 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 anges 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. 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 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 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.

Mer information om frågor, diagram och instrumentpaneler finns i hanterade frågor, diagram och instrumentpaneler.

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

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

Analysvyer innehå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 Om 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 en fråga. Mer information finns i Ansluta med Power BI Data Connector.

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

• Ta bort, ta bort eller återställa arbetsobjekt
• Kopiera eller klona ett arbetsobjekt

Kvarvarande uppgifter och anslagstavla för produkter

• Använda kvarvarande uppgifter för att hantera projekt
• Skapa kvarvarande uppgifter
• Definiera funktioner och epos
• Organisera kvarvarande uppgifter och mappa underordnade arbetsobjekt till föräldrar
• Filtrera kvarvarande uppgifter, tavlor, frågor och planer interaktivt
• Prognostisera din produkts kvarvarande uppgifter

Bräde

• Om boards och Kanban
• Använd din tavla
• Ändra ordning på kort
• Lägga till uppgifter eller underordnade objekt som checklistor

Sprint-kvarvarande uppgifter och Aktivitetstavla

• Lär dig mer om Metodtips för Scrum
• Tilldela kvarvarande uppgifter till en sprint
• Lägga till uppgifter
• Uppdatera din aktivitetstavla

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