Softwarefouten definiëren, vastleggen, classificeren en beheren in Azure Boards

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Hoe kunt u defecten in uw code bijhouden en beheren? Hoe zorgt u ervoor dat softwareproblemen en feedback van klanten snel worden aangepakt om software-implementaties van hoge kwaliteit te ondersteunen? En hoe maakt u goede vooruitgang met nieuwe functies en kunt u uw technische schuld aanpakken?

U hebt minimaal een manier nodig om uw softwareproblemen vast te leggen, prioriteiten te stellen, ze toe te wijzen aan een teamlid en de voortgang bij te houden. En u wilt uw codefouten beheren op een manier die overeenkomt met uw Agile-procedures.

Ter ondersteuning van deze scenario's biedt Azure Boards een specifiek type werkitem voor het bijhouden van codefouten met de naam Bug. Foutwerkitems delen alle standaardfuncties van andere typen werkitems met een paar meer. Zie Werk bijhouden met gebruikersverhalen, problemen, bugs, functies en epics voor een overzicht van standaardfuncties.

Bugs bieden ook de volgende aanvullende functies:

• Opties voor elk team om te kiezen hoe ze bugs willen bijhouden
• Hulpprogramma's testen om bugs vast te leggen
• Ingebouwde integratie in Azure DevOps om bugs bij te houden die zijn gekoppeld aan builds, releases en tests

Notitie

Typen bugwerkitems zijn niet beschikbaar bij het Basic-proces. Het Basic-proces houdt bugs bij als problemen en is beschikbaar wanneer u een nieuw project maakt op basis van Azure DevOps Services of Azure DevOps Server 2019.1 of nieuwere versies.

Vereisten

• U moet worden toegevoegd aan een project.
• Als u werkitems wilt weergeven of wijzigen, moet u de werkitems weergeven in dit knooppunt hebben en werkitems bewerken in deze knooppuntmachtigingen ingesteld op Toestaan. De groep Inzenders heeft standaard deze machtigingenset. Zie Machtigingen en toegang instellen voor het bijhouden van werk voor meer informatie.
• Als u nieuwe tags wilt toevoegen aan werkitems, moet u basistoegang of hoger hebben en de machtigingen voor nieuwe tagdefinities op projectniveau maken ingesteld op Toestaan. De groep Inzenders heeft standaard deze machtigingenset. Zelfs als de machtiging expliciet is ingesteld voor een belanghebbende, zijn ze niet gemachtigd om nieuwe tags toe te voegen, omdat ze niet zijn toegestaan via hun toegangsniveau. Voor meer informatie, zie Snelzoekgids toegang als belanghebbende.
• Alle projectleden, zelfs leden in de groep Lezers , kunnen e-mailberichten met werkitems verzenden.

Tip

Als u een fout wilt melden, moet een gebruiker minimaal werkitems in dit knooppunt hebben en werkitems bewerken die zijn ingesteld op Toestaan voor het gebiedspad waar ze de fout toevoegen. Zie Machtigingen en toegang instellen voor het bijhouden van werk voor meer informatie

Type bugwerkitem

In de volgende afbeelding ziet u het werkitemtype Bug voor het Scrum-proces. Het werkitemtype Bug voor Agile- en CMMI-processen houdt vergelijkbare informatie bij. Het is ontworpen om samen met de vereisten of op het Taskboard samen met taken op de productachterstand te worden weergegeven.

Notitie

De afbeeldingen die u in uw webportal ziet, kunnen verschillen van de afbeeldingen die u in dit artikel ziet. Deze verschillen zijn het gevolg van updates die zijn aangebracht in uw web-app, opties die u of uw beheerder hebben ingeschakeld en welk proces is gekozen bij het maken van uw project: Agile, Basic, Scrum of CMMI. Het Basic-proces is beschikbaar met Azure DevOps Server 2019 Update 1 en nieuwere versies.

Velden die specifiek zijn voor fouten

Het werkitemtype Bug maakt gebruik van enkele bugspecifieke velden. Als u zowel het eerste probleem als de lopende detecties wilt vastleggen, gebruikt u de velden die in de volgende tabel worden beschreven. Zie Fouten, problemen en risicovelden voor informatie over velden die specifiek zijn voor het CMMI-proces (Capability Maturity Model Integration) voor informatie over velden die specifiek zijn voor de bug die is gedefinieerd voor het CMMI-proces (Capability Maturity Model Integration). Zie de index van het veld Werkitem voor informatie over alle andere velden.

---

Veld, groep of tabblad

Gebruik

---

Stappen om te reproduceren
(beschrijvende naam=stappen voor opnieuw proberen)

Gebruik dit om voldoende informatie vast te leggen, zodat andere teamleden het codefout volledig kunnen begrijpen. Neem acties op die zijn uitgevoerd om de bug en het verwachte gedrag te vinden of te reproduceren.

---

Systeemgegevens
Gevonden in build

Informatie over de software- en systeemconfiguratie die relevant is voor de fout en tests die moeten worden toegepast. De systeemgegevens en gevonden in buildvelden worden automatisch ingevuld wanneer u een fout maakt via een testhulpprogramma. Deze velden geven informatie op over de softwareomgeving en bouwen waar de fout is opgetreden. Zie Verschillende configuraties testen voor meer informatie.

---

Acceptatiecriteria

Geef de criteria op waaraan moet worden voldaan voordat de fout kan worden gesloten. Voordat het werk begint, beschrijft u de acceptatiecriteria van de klant zo duidelijk mogelijk. Teams moeten deze criteria gebruiken als basis voor acceptatietests en om te evalueren of een item bevredigend is voltooid.

---

Geïntegreerd in build

Hiermee geeft u de naam op van de build die de code bevat waarmee de fout wordt opgelost. Dit veld moet worden opgegeven wanneer u de fout oplost. Voor on-premises Azure DevOps kunt u voor toegang tot een vervolgkeuzelijst met alle builds die zijn uitgevoerd, de FIELD definities bijwerken voor Gevonden in Build en Geïntegreerd in Build om te verwijzen naar een algemene lijst. De algemene lijst wordt automatisch bijgewerkt met elke build die wordt uitgevoerd. Zie Query op basis van build- en testintegratievelden voor meer informatie.
Zie opties voor buildnummernotatie voor meer informatie over het definiëren van buildnummers.

---

Prioriteit¹

• 1: Product vereist een succesvolle oplossing van het werkitem voordat het wordt verzonden en binnenkort wordt aangepakt.
• 2: Product vereist een succesvolle oplossing van het werkitem voordat het wordt verzonden, maar hoeft niet onmiddellijk te worden aangepakt.
• 3: Oplossing van het werkitem is optioneel op basis van resources, tijd en risico.

---

^{Ernst 1}

Een subjectieve beoordeling van de impact van een bug of werkitem op het project of softwaresysteem. Bijvoorbeeld: Als een externe koppeling in de gebruikersinterface( een zeldzame gebeurtenis) ervoor zorgt dat een toepassing of webpagina vastloopt, kunt u ernst = 2 - Hoge en prioriteit = 3 opgeven. Toegestane waarden en voorgestelde richtlijnen zijn:

• 1 - Kritiek: Moet worden opgelost. Een defect dat beëindiging van een of meer systeemonderdelen of het volledige systeem veroorzaakt, of uitgebreide beschadiging van gegevens veroorzaakt. En er zijn geen acceptabele alternatieve methoden om vereiste resultaten te bereiken.
• 2 - Hoog: Overweeg een oplossing. Een defect dat beëindiging van een of meer systeemonderdelen of het volledige systeem veroorzaakt, of uitgebreide beschadiging van gegevens veroorzaakt. Er bestaat echter een acceptabele alternatieve methode om vereiste resultaten te bereiken.
• 3 - Gemiddeld: (standaard) Een defect dat ervoor zorgt dat het systeem onjuiste, onvolledige of inconsistente resultaten produceert.
• 4 - Laag: Een klein of cosmetisch defect met acceptabele tijdelijke oplossingen om de vereiste resultaten te bereiken.

---

Implementatie

Het besturingselement Implementatie ondersteunt koppelingen naar en weergave van releases die werkitems bevatten. Als u het besturingselement wilt gebruiken, moet u instellingen voor de release inschakelen. Zie Werkitems koppelen aan releases verderop in dit artikel voor meer informatie.

---

Ontwikkeling

Het besturingselement Ontwikkeling ondersteunt koppelingen naar en weergave van koppelingen naar ontwikkelingsobjecten. Deze objecten omvatten Git-doorvoeringen en pull-aanvragen, of TFVC-wijzigingensets en versiebeheeritems. U kunt koppelingen definiëren vanuit het werkitem of vanuit de doorvoeringen, pull-aanvragen of andere ontwikkelobjecten. Zie Werkitems koppelen aan ontwikkeling verderop in dit artikel voor meer informatie.

---

Opmerkingen:

¹ Zie De ervaring voor het bijhouden van werk aanpassen als u de menuselectie of selectielijst wilt wijzigen. De aanpassingsmethode is afhankelijk van het procesmodel dat door uw project wordt gebruikt.

Kiezen hoe uw team bugs bijhoudt

Uw team kan bugs bijhouden als vereisten of als taken. Houd rekening met de volgende factoren om de teamkeuze te ondersteunen.

• Grootte van uw team. Kleinere teams kunnen een lichtgewicht footprint onderhouden door bugs bij te houden als vereisten.
• Organisatievereisten voor het bijhouden van werk. Als uw team uren moet bijhouden, kiest u ervoor om bugs bij te houden als taken.
• Hoe uw team werkt. Als uw team afhankelijk is van de achterstand van het product om prioriteit te geven aan werk en bugs toe te voegen, houdt u bugs bij als vereisten.
• Hulpprogramma's die uw team wil gebruiken, zoals het planningsvenster, de snelheidsgrafiek, prognose, rollup en leveringsplannen. Bijhouden van bugs als taken voorkomt het gebruik van verschillende van deze hulpprogramma's.

De volgende tabel bevat een overzicht van de drie opties die teams nodig hebben om bugs bij te houden. Zie Bugs in achterstanden en borden weergeven voor meer informatie en om de optie voor uw team in te stellen.

---

Optie

Kies wanneer u wilt...

---

Bugs bijhouden als vereisten

• Bugs prioriteren (stack rank) samen met vereisten
• Foutinspanning schatten voor prognose
• Foutstatus bijwerken op kanbanbord
• Bugs opnemen in snelheidsdiagrammen en cumulatieve stroomdiagrammen
• Kan het hulpprogramma Prognose gebruiken ter ondersteuning van sprintplanning
• Kan bugs slepen en neerzetten in het planningsvenster om bugs toe te wijzen aan een sprint
• Kan bugs in bezorgingsplannen bekijken

Notitie

• Bugs worden toegewezen aan de categorie Vereisten

---

Bugs bijhouden als taken

• Werk schatten voor fouten die vergelijkbaar zijn met taken
• Foutstatus bijwerken op sprint taskboards
• Bugs koppelen aan vereisten als onderliggende items
• Kan bugs slepen en neerzetten in het planningsvenster om bugs toe te wijzen aan een sprint

Notitie

• Fouten worden toegewezen aan de taakcategorie
• Gebruikersverhalen (Agile), Productachterstanditems (Scrum) of Vereisten (CMMI) zijn het natuurlijke bovenliggende werkitemtype voor bugs
• Bugs zijn niet zichtbaar in leveringsplannen

---

Bugs worden niet weergegeven op achterstanden of borden

• Fouten beheren met behulp van query's

Notitie

• Bugs zijn gekoppeld aan de categorie Bugs en worden niet weergegeven op achterstanden of borden
• Bugs zijn niet zichtbaar in achterstanden, borden, sprintachterstanden, taskboards of leveringsplannen
• Kan bugs niet slepen en neerzetten in het planningsvenster om bugs toe te wijzen aan een sprint

---

Type werkitem aanpassen

U kunt de typen bug en andere werkitems aanpassen. Of maak aangepaste typen om softwareproblemen of feedback van klanten bij te houden. Met alle typen werkitems kunt u de volgende elementen aanpassen:

• Aangepaste velden toevoegen of verwijderen
• Aangepaste besturingselementen of aangepaste tabbladen toevoegen in het werkitemformulier
• De werkstroomstatussen aanpassen
• Voorwaardelijke regels toevoegen
• Kies het achterstandsniveau waarin werkitems worden weergegeven

Voordat u uw proces aanpast, raden we u aan Azure Boards configureren en aanpassen te bekijken.

Zie Een overnameproces aanpassen om uw specifieke proces aan te passen.

Bugs toevoegen of vastleggen

U kunt bugs van verschillende Azure DevOps-hulpprogramma's definiëren. Deze omvatten achterstanden en borden en testhulpprogramma's.

Tip

Standaard is het veld Titel het enige vereiste veld bij het maken van een fout. U kunt snel bugs toevoegen op dezelfde manier als u gebruikersverhalen of productachterstanditems toevoegt met behulp van Azure Boards. Als u bepaalde velden vereist wilt maken, doet u dit door voorwaardelijke regels toe te voegen op basis van een statuswijziging. Zie Een regel toevoegen aan een werkitemtype (overnameproces) voor meer informatie.

Een bug toevoegen vanuit uw achterstand of bord

Als uw team ervoor heeft gekozen om bugs met vereisten te beheren, kunt u bugs definiëren op basis van uw productachterstand of Kanban-bord. Zie Uw productachterstand maken of Uw Kanbanbord gebruiken voor meer informatie.

• Een fout toevoegen vanuit de productachterstand

  

• Een fout toevoegen vanuit de productachterstand

  

Tip

Wanneer u een fout toevoegt vanuit uw productachterstand of Kanbanbord, wordt de fout automatisch het standaardgebiedpad en iteratiepad toegewezen dat voor het team is gedefinieerd. Zie De standaardinstellingen van Team waarnaar wordt verwezen door achterstanden en borden voor meer informatie.

Een fout toevoegen vanuit uw sprintachterstand of Taskboard

Als uw team ervoor heeft gekozen om bugs met taken te beheren, kunt u bugs definiëren op basis van uw Kanban-bord, productachterstand, Sprint-achterstand of Sprint Taskboard. U voegt een bug als onderliggend item toe aan een productachterstand.

• Een gekoppelde onderliggende bug toevoegen vanuit het Kanban-bord
  U voegt een fout op dezelfde manier toe als u een taak toevoegt aan een achterstandsitem. Zie Taken of onderliggende items toevoegen als controlelijsten voor meer informatie.

  

• Een gekoppelde onderliggende fout toevoegen uit de sprintachterstand
  U voegt een bug op dezelfde manier toe als u een taak toevoegt aan een sprintachterstand. Zie Taken toevoegen aan achterstandsitems voor meer informatie.

  

Een fout maken op basis van een testhulpprogramma

De twee testhulpprogramma's die u kunt gebruiken om bugs toe te voegen tijdens het testen, zijn de webportal Test Runner en de extensie Test & Feedback.

• Test Runner: Bij het uitvoeren van handmatige tests kunt u ervoor kiezen om een fout te maken. Zie Handmatige tests uitvoeren voor meer informatie.

  

• Test & Feedback-extensie: Bij het uitvoeren van verkennende tests kunt u ervoor kiezen om een fout te maken of een taak te maken. Zie Experimentele tests met de extensie Test & Feedback voor meer informatie

Statussen van levenscyclus en werkstroom van fouten

Net als bij alle andere typen werkitems heeft het werkitemtype Bug een goed gedefinieerde werkstroom. Elke werkstroom bestaat uit drie of meer statussen en een reden. Redenen geven aan waarom het item is overgezet van de ene status naar de andere. In de volgende afbeeldingen ziet u de standaardfoutwerkstroom die is gedefinieerd voor de Agile-, Scrum- en CMMI-processen .

Flexibel	Scrum	CMMI

Voor Scrum-bugs wijzigt u de status van Vastgelegd (vergelijkbaar met Actief) in Gereed. Voor Agile en CMMI lost u eerst de fout op en selecteert u een reden die aangeeft dat de fout is opgelost. Normaal gesproken controleert de persoon die de bug heeft gemaakt, de oplossing en werkt de status bij van Opgelost naar Gesloten. Als er meer werk is gevonden nadat een fout is opgelost of gesloten, kunt u deze opnieuw activeren door de status in te stellen op Vastgelegd of Actief.

Notitie

Het werkitemtype Agile-procesfout had eerder een regel waarmee de bug opnieuw werd toegewezen aan de persoon die het heeft gemaakt. Deze regel is verwijderd uit het standaardsysteemproces. U kunt deze automatisering opnieuw instellen door een regel toe te voegen. Voor een overnameproces raadpleegt u Regels toepassen op werkstroomstatussen, Automatisch opnieuw toewijzen op basis van statuswijziging.

Een oplossing controleren

Om een oplossing te controleren, probeert een ontwikkelaar of tester de bug te reproduceren en zoekt naar onverwacht gedrag. Indien nodig moeten ze de bug opnieuw activeren.

Wanneer u een foutoplossing controleert, kan het zijn dat de fout niet is opgelost of dat u het niet eens bent met de oplossing. In dit geval bespreekt u de bug met de persoon die het heeft opgelost, komt u tot een overeenkomst en activeert u de fout mogelijk opnieuw. Als u een fout opnieuw activeert, neemt u de redenen op voor het opnieuw activeren van de fout in de beschrijving van de fout.

Een bug sluiten

U sluit een bug zodra deze is geverifieerd als opgelost. U kunt echter ook een bug sluiten om een van de volgende redenen. Redenen die beschikbaar zijn om te selecteren, zijn afhankelijk van het projectproces en de statussen van de foutovergang.

Agile-proces:

• Uitgestelde: Los de foutoplossing uit tot de volgende productrelease.
• Opgelost: Fout wordt geverifieerd als opgelost.
• Duplicaat: Er wordt een andere fout bijgehouden die momenteel is gedefinieerd. U kunt elke bug koppelen aan het type duplicaat/duplicaat van het koppelingstype en een van de bugs sluiten.
• Zoals ontworpen: Functie werkt zoals ontworpen.
• Kan niet reproduceren: tests bewijzen dat de fout niet kan worden gereproduceerd.
• Verouderd: de functie van de fout bevindt zich niet meer in het product.
• Gekopieerd naar achterstand: er is een gebruikersverhaal geopend om de fout bij te houden.

Scrum-proces:

• Geen bug: er wordt gecontroleerd of het geen bug is.
• Duplicaat: Er wordt een andere fout bijgehouden die momenteel is gedefinieerd. U kunt elke bug koppelen aan het type duplicaat/duplicaat van het koppelingstype en een van de bugs sluiten.
• Verwijderd uit de achterstand: Er wordt gecontroleerd of het geen bug is. Verwijder de fout uit de achterstand.
• Werk voltooid: Er is een fout geverifieerd als opgelost.

CMMI-proces:

• Uitgestelde: Los de foutoplossing uit tot de volgende productrelease.
• Duplicaat: Er wordt een andere fout bijgehouden die momenteel is gedefinieerd. U kunt elke bug koppelen aan het type duplicaat/duplicaat van het koppelingstype en een van de bugs sluiten.
• Geweigerd: Er wordt gecontroleerd of het geen bug is.
• Geverifieerd: Fout wordt geverifieerd als opgelost.

Tip

Zodra een fout is gesloten en de oplossing actief wordt uitgebracht in implementaties, is het raadzaam deze nooit opnieuw te openen vanwege regressie. In plaats daarvan kunt u overwegen om een nieuwe bug te openen en een koppeling te maken naar de oudere, gesloten bug.

Het is altijd een goed idee om meer details te beschrijven voor het sluiten van een bug in het veld Discussie om toekomstige verwarring te voorkomen over de reden waarom de fout is gesloten.

Fouten sluiten automatiseren bij het samenvoegen van pull-aanvragen

Als uw team gebruikmaakt van een Git-opslagplaats, kunt u de status instellen in gekoppelde bugs en andere werkitems om te worden gesloten bij het samenvoegen van pull-aanvragen. Zie Status van werkitem instellen in pull-aanvraag verderop in dit artikel voor meer informatie.

Fouten weergeven en classificeren

De meeste teams, welke optie ze ook hebben gekozen om bugs bij te houden, een of meer bugquery's te definiëren. Met query's kunt u actieve bugs, niet-toegewezen bugs, verouderde bugs, bugtrends en meer weergeven. Vervolgens kunt u query's en querygrafieken toevoegen aan uw teamdashboards om de foutstatus en voortgang te controleren.

Foutquery's

Open een gedeelde query of gebruik de query-editor om nuttige foutquery's te maken, zoals de volgende opties:

• Actieve bugs op prioriteit (State <> Done of State <> Closed)
• Fouten die worden uitgevoerd (State = Committed of State = Active)
• Fouten die moeten worden opgelost voor een doelrelease (Tags Contains RTM)
• Recente bugs : bugs die zijn geopend in de afgelopen drie weken (Created Date > @Today-21)

Zodra u de query's voor uw team hebt, kunt u status- of trendgrafieken maken. U kunt ook de grafiek die u maakt toevoegen aan een dashboard.

Triagemodus in queryresultaten

Zodra u bent begonnen met coderen en testen, wilt u periodieke triagevergaderingen houden om uw bugs te beoordelen en te rangschikken. Normaal gesproken voert de projecteigenaar de bug-triagevergaderingen uit. Teamleiders, bedrijfsanalisten en andere belanghebbenden die kunnen spreken over specifieke projectrisico's, nemen deel aan de triagevergaderingen.

De projecteigenaar kan een gedeelde query definiëren voor nieuwe en opnieuw geopende bugs om fouten weer te geven die moeten worden gesorteerd.

Op de pagina met queryresultaten kunt u snel omhoog en omlaag gaan in de lijst met bugwerkitems met behulp van de pijl-omhoog en pijl-omlaag. Wanneer u elke fout bekijkt, kunt u deze toewijzen, details toevoegen of prioriteit instellen.

Fouten organiseren en toewijzen aan een sprint

Als uw team bugs bijhoudt als vereisten, bekijkt u de lijst met actieve bugs uit uw achterstand. Met de filterfunctie kunt u zich alleen richten op bugs. Vanuit de productachterstand kunt u ook de volgende taken uitvoeren:

• Organiseer fouten in uw achterstand, stapelpositie ten opzichte van andere items (stackrangschikking is uitgeschakeld wanneer filteren is ingeschakeld)
• Bugs toewijzen aan een sprint vanuit uw achterstand met behulp van het planningsvenster
• Bovenliggende fouten in functies of andere portfolioachterstanditems met behulp van het deelvenster Toewijzing
• Samenvouwen van werk weergeven aan portfolioachterstanditems.

Als uw team bugs bijhoudt als taken, gebruikt u beheerde query's om bugs weer te geven en te classificeren. Vervolgens ziet u binnen elke sprint de bugs die zijn toegewezen aan de sprint vanuit de achterstand of Taskboard van Sprint.

Taskboard-items versus querylijstitems

U ziet en vraagt zich misschien af waarom de items die worden weergegeven op een sprint Taskboard, kunnen verschillen van een querylijst die is gemaakt in een overeenkomende sprintachterstand.

Het is mogelijk om taken of bugs toe te wijzen aan een iteratie, maar deze niet te koppelen aan een bovenliggend backlog-item. Deze items worden weergegeven in de gemaakte query, maar worden mogelijk niet weergegeven op het Taskboard zelf. Het systeem voert de query uit en past vervolgens enkele achtergrondprocessen toe voordat Taskboard-items worden weergegeven.

Deze redenen kunnen ertoe leiden dat werkitems die deel uitmaken van de taakcategorie niet worden weergegeven in een sprintachterstand of Taskboard:

• De taak of fout is niet gekoppeld aan een bovenliggend backlog-item. Alleen bugs en taken die u hebt gekoppeld aan een bovenliggend productachterstanditem (Scrum), gebruikersverhaal (Agile) of vereiste (CMMI) met een iteratiepad dat is ingesteld op de sprint, wordt weergegeven op de pagina Achterstallige sprint.
• De taak of fout is een bovenliggend item van een andere taak of bug, of het gebruikersverhaal is een bovenliggend item van een andere gebruiker. Als u een hiërarchie van taken, bugs of gebruikersverhalen hebt gemaakt, worden alleen de taken op onderliggende niveaus of de verhalen op onderliggende niveaus onder aan de hiërarchie weergegeven.
• De gekoppelde bovenliggende taak of fout komt overeen met een achterstandsitem dat is gedefinieerd voor een ander team. Of het gebiedspad van het bovenliggende backlog-item van de taak of bug verschilt van het gebiedspad van de taak of het gebiedspad van de fout.

Inlinetests maken die zijn gekoppeld aan bugs

Wanneer uw team bugs bijhoudt als vereisten, kunt u het Kanban-bord gebruiken om tests toe te voegen om bugfixes te controleren.

Foutstatus bijwerken

U kunt de foutstatus bijwerken door bugs naar een nieuwe kolom op een bord te slepen en neer te laten vallen.

• Als uw team bugs bijhoudt als vereisten, gebruikt u het Kanban-bord, zoals wordt weergegeven in de volgende afbeelding. Zie Aan de slag met uw Kanban-bord voor meer informatie.

  

• Als uw team bugs bijhoudt als taken, gebruikt u het Taskboard. Zie Uw Taskboard bijwerken en bewaken voor meer informatie.

  

Uw bord aanpassen om tussenliggende statussen bij te houden

U kunt tussenliggende kolommen toevoegen om de foutstatus op het bord bij te houden. U kunt ook query's definiëren die filteren op basis van de status van een bordkolom. Raadpleeg voor meer informatie de volgende artikelen:

• Kolommen toevoegen aan uw Kanban-bord
• Een sprint taskboard aanpassen
• Kanbanboard-wijzigingsquery's

Het opnieuw toewijzen van fouten automatiseren op basis van de werkstroomstatus

Als u selectieacties wilt automatiseren, voegt u aangepaste regels toe aan uw type bugwerkitem. Voeg bijvoorbeeld een regel toe zoals wordt weergegeven in de volgende afbeelding. Deze regel geeft aan dat een bug opnieuw moet worden toegewezen aan de persoon die de fout heeft geopend zodra deze is opgelost. Normaal gesproken controleert die persoon of de fout is opgelost en wordt de fout gesloten. Zie Regels toepassen op werkstroomstatussen (overnameproces) voor meer informatie.

Status van werkitem instellen in pull-aanvraag

Wanneer u een pull-aanvraag maakt, kunt u de statuswaarde van de gekoppelde werkitems instellen in de beschrijving. Volg de syntaxis: {state value}: #ID. Wanneer u de pull-aanvraag samenvoegt, leest het systeem de beschrijving en werkt het de status van het werkitem bij. In het volgende voorbeeld stellen we werkitems #300 en #301 in op Opgelost, en #323 en #324 op Gesloten.

Integratie in Azure DevOps

Een van de methoden die door Azure DevOps worden gebruikt ter ondersteuning van integratie, is het koppelen van objecten aan andere objecten. Naast het koppelen van werkitems aan werkitems, kunt u ook werkitems koppelen aan andere objecten. Maak een koppeling naar objecten zoals builds, releases, vertakkingen, doorvoeringen en pull-aanvragen, zoals geïllustreerd in de volgende afbeelding.

U kunt een koppeling toevoegen vanuit het werkitem of vanuit de build- en releaseobjecten.

Werkitems koppelen aan ontwikkeling

Het besturingselement Ontwikkeling biedt ondersteuning voor het koppelen en weergeven van koppelingen naar builds, Git-doorvoeringen en pull-aanvragen. Of, wanneer een TFVC-opslagplaats wordt gebruikt, ondersteunt deze koppelingen naar wijzigingensets en versiebeheeritems. Als u de koppeling kiest, wordt het bijbehorende item in een nieuw browsertabblad geopend. Zie Drive Git-ontwikkeling vanuit een werkitem voor meer informatie.

Werkitems koppelen aan releases

Het besturingselement Implementatie ondersteunt koppelingen naar en weergave van releases die de werkitems bevatten. In de volgende afbeelding ziet u bijvoorbeeld verschillende releases die koppelingen naar het huidige werkitem bevatten. U kunt elke release uitbreiden om details over elke fase te bekijken. U kunt de koppeling voor elke release en fase kiezen om de bijbehorende release of fase te openen. Zie Werkitems koppelen aan implementaties voor meer informatie.

Werkitems koppelen aan pijplijnuitvoeringen

Pijplijnen worden vaak gedefinieerd om automatisch te worden uitgevoerd wanneer een nieuwe doorvoering plaatsvindt in een Git-opslagplaats. Werkitems die zijn gekoppeld aan de doorvoerpijplijnen worden weergegeven als onderdeel van de pijplijnuitvoering als u uw pijplijninstellingen aanpast. Zie Uw pijplijn aanpassen voor meer informatie.

Een werkitem maken of bewerken bij een buildfout

Als u klassieke pijplijnen (niet YAML) gebruikt, kunt u werkitems maken op een buildfout. Zie Build-opties voor meer informatie, Een werkitem maken bij een fout.

Foutstatus, toewijzingen en trends bewaken

U kunt de foutstatus, toewijzingen en trends bijhouden met behulp van query's die u vervolgens kunt weergeven en toevoegen aan een dashboard. Hier volgen bijvoorbeeld twee voorbeelden met actieve fouttrends per State en Active Bugs by Priority in de loop van de tijd.

Voor meer informatie over query's, grafieken en dashboards; zie Over beheerde query's en grafieken en dashboards.

Analytics-weergaven en de Analytics-service gebruiken om foutenrapporten te maken

De Analytics-service is het rapportageplatform voor Azure DevOps, waarbij het vorige platform wordt vervangen op basis van SQL Server Reporting Services.

Analyseweergaven bieden vooraf gemaakte filters om werkitems weer te geven. Vier analytische weergaven worden ondersteund voor foutrapportage. U kunt deze weergaven gebruiken zoals gedefinieerd of verder bewerken om een aangepaste, gefilterde weergave te maken.

• Bugs - Alle geschiedenis per maand
• Bugs - Afgelopen 26 weken
• Bugs - Afgelopen 30 dagen
• Bugs - Vandaag

Zie Wat zijn analyseweergaven en een actief foutenrapport maken in Power BI op basis van een aangepaste analyseweergave voor meer informatie over het gebruik van analyseweergaven.

U kunt Power BI gebruiken om complexere rapporten te maken dan wat u uit een query kunt ophalen. Zie Verbinding maken met Power BI Data Verbinding maken or voor meer informatie.

Marketplace-extensies

Er zijn meerdere foutgerelateerde Marketplace-extensies. Zie Marketplace voor Azure DevOps.

Zie Azure Boards-extensies die zijn ontwikkeld door Microsoft voor meer informatie over extensies.

Volgende stappen

Sjablonen gebruiken om werkitems toe te voegen en bij te werken

Verwante artikelen:

• Werkitems verplaatsen, wijzigen of verwijderen
• Een werkitem kopiëren of klonen

Productachterstand en Kanbanbord

• Achterstanden, portfolio's en Agile-projectmanagement
• Uw achterstand maken
• Functies en epics definiëren
• Organiseer uw achterstand, wijs onderliggende werkitems toe aan ouders
• Achterstanden, borden, query's en plannen interactief filteren
• De achterstand van uw product voorspellen

Kanbanbord

• Over borden en Kanban
• Snelstart voor Kanban-bord
• Kaarten opnieuw ordenen
• Taken of onderliggende items toevoegen als controlelijsten

Sprintachterstand en Taskboard

• Scrum en werken met best practices voor sprints
• Achterstandsitems toewijzen aan een sprint
• Taken toevoegen
• Het Taskboard bijwerken

Integratie binnen Azure DevOps

• Gebruikersverhalen, problemen, bugs en andere werkitems koppelen
• Een werkitem of pull-aanvraag volgen
• Uitvoerings- of buildnummers configureren

Industriebronnen

• Goede en slechte technische schuld (en hoe TDD helpt) door Microsoft Kniberg
• Technische schuld beheerd door Sven Johann & Eberhard Wolff