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? Hoe maakt u goede vorderingen op nieuwe functies en gaat u in op uw technische schuld?

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. 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 Over werkitems en typen werkitems voor een overzicht van standaardfuncties.

Bugs bieden ook de volgende 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

• Projecttoegang: Worden toegevoegd aan een project.

• Machtigingen:

  • Werkitems weergeven in dit knooppunt en werkitems bewerken in dit knooppunt machtigingen ingesteld op Toestaan. De groep Inzenders heeft standaard deze machtigingen. Zie Machtigingen voor het bijhouden van werk instellen voor meer informatie.

  • Als u nieuwe tags wilt toevoegen aan werkitems, hebt u Basic-toegang of hoger en hebt u de machtiging Nieuwe tagdefinitie maken op projectniveau ingesteld op Toestaan. De groep Inzenders heeft standaard deze machtiging.

    Notitie

    Belanghebbenden kunnen geen nieuwe tags toevoegen, zelfs niet als de machtiging expliciet is ingesteld vanwege hun toegangsniveau. Voor meer informatie, zie Snelzoekgids toegang als belanghebbende.

• Werkitems per e-mail verzenden: alle projectleden, inclusief de leden in de groep Lezers , kunnen e-mailberichten met werkitems verzenden.

Tip

Als u een fout wilt melden, moet een gebruiker minimaal toegang hebben tot belanghebbenden . Een gebruiker moet werkitems bewerken in deze knooppuntmachtiging hebben ingesteld op Toestaan voor het gebiedspad waar ze de fout toevoegen. Zie Machtigingen voor het bijhouden van werk instellen voor meer informatie

Type bugwerkitem

In de volgende afbeelding ziet u het werkitemtype Bug voor het Scrum-proces. Het type bugwerkitem voor CMMI-processen (Agile and Capability Maturity Model Integration) houdt vergelijkbare informatie bij. Deze wordt weergegeven in de achterstand van het product, samen met vereisten of op het Taskboard, samen met taken.

Notitie

De afbeeldingen die u in uw webportal ziet, kunnen afwijken 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 heeft 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.

---

Systeemgegevensgevonden 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 naar tevredenheid 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 vervolgkeuzemenu van 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 de configuratie van klassieke pijplijnen voor 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 (een ernstige klantervaring), 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. 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 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.
• Organisatie van het werk van uw team. 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

• Prioriteiten stellen of rangschikken, fouten in combinatie met vereisten
• Foutinspanning schatten voor prognose
• Foutstatus aan boord bijwerken
• Bugs opnemen in snelheidsdiagrammen en cumulatieve stroomdiagrammen
• Het hulpprogramma Prognose kunnen gebruiken om sprintplanning te ondersteunen
• Sleep bugs naar het planningsvenster om bugs toe te wijzen aan een sprint
• Bugs in bezorgingsplannen weergeven

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
• Sleep bugs naar 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 bezorgingsplannen

---

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 in achterstanden of borden
• Bugs zijn niet zichtbaar in achterstanden, borden, sprintachterstanden, taskboards of bezorgingsplannen
• U kunt bugs niet naar het planningsvenster slepen 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. Voor 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 te configureren en aan te passen.

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 hulpprogramma's omvatten achterstanden en borden en testhulpprogramma's.

Tip

Standaard is het veld Titel het enige vereiste veld wanneer u een fout maakt. U kunt bugs toevoegen op dezelfde manier als u gebruikersverhalen of productachterstanditems toevoegt met behulp van Azure Boards. U kunt bepaalde velden verplicht stellen door voorwaardelijke regels toe te voegen op basis van een statuswijziging. Zie Een regel toevoegen aan een werkitemtype 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 vanuit uw productachterstand of bord. Zie Uw productachterstand maken of Uw bord gebruiken voor meer informatie.

• Een fout toevoegen vanuit de productachterstand

  

• Een bug toevoegen vanaf het bord

  

Tip

Wanneer u een fout toevoegt vanuit uw productachterstand of -bord, wordt 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 bord, productachterstand, Sprint-achterstand of Sprint Taskboard. U voegt een bug als onderliggend item toe aan een productachterstand.

• 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 gekoppelde onderliggende bug toevoegen vanaf het 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 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 u meer werk vindt nadat u een fout hebt opgelost of gesloten, activeert u deze opnieuw door de status in te stellen op Doorgevoerd 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. Zie Opnieuw toewijzen automatiseren op basis van statuswijziging voor een overnameproces.

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 wanneer een teamlid deze controleert zoals opgelost. U kunt echter ook een bug sluiten om een van de volgende redenen. De beschikbare redenen 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

Nadat een fout is gesloten en de oplossing actief is vrijgegeven in implementaties, is het aanbevolen om 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. U kunt 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, zoals fouten die in de afgelopen drie weken zijn geopend (Created Date > @Today-21)

Wanneer u de query's van belang 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

Nadat u begint met coderen en testen, houdt u periodieke triagevergaderingen 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 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 bugs in uw achterstand. Rangschikking stapelen op andere items. Stack-classificatie is uitgeschakeld wanneer filteren is ingeschakeld.
• Wijs bugs toe aan een sprint vanuit uw achterstand met behulp van het deelvenster Planning .
• Wijs bovenliggende fouten toe aan functies of andere portfolioachterstandsitems 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. In elke sprint ziet u de bugs die zijn toegewezen aan de sprint vanuit de achterstands- of Taskboard-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 zijn gekoppeld aan een bovenliggend productachterstanditem (Scrum), gebruikersverhaal (Agile) of vereiste (CMMI) met een iteratiepad dat is ingesteld op de sprintpagina.
• 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 maakt, worden alleen de taken op onderliggend niveau of de verhalen op onderliggende niveaus onder aan de hiërarchie weergegeven. Zie Problemen met opnieuw ordenen en nesten oplossen voor meer informatie.
• 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 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 bord zoals wordt weergegeven in de volgende afbeelding. Zie Werkitemstatus bijwerken 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 bord
• Een sprint taskboard aanpassen
• Querywijzigingen in een bord uitvoeren

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 bug heeft geopend wanneer een teamlid deze oplost. 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 worden werkitems #300 en #301 ingesteld 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. Wanneer een TFVC-opslagplaats wordt gebruikt, worden koppelingen naar wijzigingensets en versiebeheeritems ondersteund. 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 Een werkitem maken bij een fout voor meer informatie.

Foutstatus, toewijzingen en trends bewaken

U kunt de foutstatus, toewijzingen en trends bijhouden met behulp van query's die u 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.

Zie beheerde query's, grafieken en dashboards voor meer informatie over query's, grafieken en dashboards.

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

De Analytics-service is het rapportageplatform voor Azure DevOps. Het vervangt het vorige platform op basis van SQL Server Reporting Services.

Analyseweergaven bieden vooraf samengestelde 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 About Analytics-weergaven en een actief foutenrapport maken in Power BI op basis van een aangepaste analyseweergave voor meer informatie over het gebruik van analytische weergaven.

U kunt Power BI gebruiken om complexere rapporten te maken dan een query. Zie Verbinding maken met Power BI-gegevensconnector 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 verwijderen, verwijderen of herstellen
• Een werkitem kopiëren of klonen

Productachterstand en bord

• Achterstanden gebruiken om projecten te beheren
• Uw achterstand maken
• Functies en epics definiëren
• Uw achterstand organiseren en onderliggende werkitems toewijzen aan ouders
• Achterstanden, borden, query's en plannen interactief filteren
• De achterstand van uw product voorspellen

Bord

• Over borden en Kanban
• Uw bord gebruiken
• Kaarten opnieuw ordenen
• Taken of onderliggende items toevoegen als controlelijsten

Sprintachterstand en Taskboard

• Meer informatie over best practices voor Scrum
• Achterstandsitems toewijzen aan een sprint
• Taken toevoegen
• Uw 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