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

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

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 aan nieuwe functies en pakt u uw technische schuld aan?

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 nog een paar extra functies. 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
• Testhulpmiddelen om bugs vast te leggen
• Ingebouwde integratie in Azure DevOps om bugs bij te houden die zijn gekoppeld aan builds, releases en tests

Prerequisites

Type bug-werkitem

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. Dit wordt weergegeven in de product-backlog samen met vereisten, of op het Taskboard samen met taken.

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 referentie voor informatie over velden die specifiek zijn voor de Bug zoals gedefinieerd in het Capability Maturity Model Integration (CMMI) proces. Zie de index van het veld Werkitem voor informatie over alle andere velden.

Notes

¹ Om de menuselectie of keuzelijst te wijzigen, zie Pas de werkopvolgingservaring aan. 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 een vereiste of als een taak. 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, kunt u ervoor kiezen om bugs bij te houden als taken.
• Organisatie van het werk van uw team. Als uw team afhankelijk is van de productbacklog om prioriteit te geven aan het werk en bugs toe te voegen, registreer bugs als vereisten.
• Hulpprogramma's die uw team wil gebruiken, zoals het planningsvenster, de snelheidsgrafiek, prognose, rollup en leveringsplannen. Het bijhouden van bugs als taken verhindert het gebruik van meerdere van deze hulpmiddelen.

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 opties voor uw team in te stellen.

Werkitemtype aanpassen

U kunt bugtypen 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, raadpleegt u Over het configureren en aanpassen van Azure Boards.

Bugs toevoegen of registreren

U kunt bugs van verschillende Azure DevOps-hulpprogramma's definiëren. Deze hulpmiddelen omvatten backlogs, borden en testtools.

Een bug toevoegen vanuit uw backlog of board

Als uw team ervoor kiest om bugs met vereisten te beheren, kunt u bugs beheren vanuit uw productbacklog of board. Zie Uw productachterstand maken of Uw bord gebruiken voor meer informatie.

• Een fout toevoegen vanuit de productachterstand

  

• Een bug toevoegen vanaf het bord

  

Een bug toevoegen van uw sprint backlog of taskboard

Als uw team ervoor kiest om bugs met taken te beheren, kunt u bugs definiëren op basis van uw bord, productachterstand, sprintachterstand of sprinttaakbord. Voeg een bug als onderliggend item toe aan een werkitem met een productachterstand.

• Een gekoppelde onderliggende bug toevoegen vanuit de sprintachterstand

  Voeg een bug toe op dezelfde manier als u een taak toevoegt aan een sprintbacklog. Zie Taken toevoegen aan de backloglijst voor meer informatie.

  

• Een gekoppelde subbug toevoegen vanaf het bord

  Voeg een bug op dezelfde manier toe als je een taak aan een backlog-item toevoegt. Voor meer informatie, zie Taken of subitems toevoegen als controlelijsten.

  

Een bug creëren vanuit een testhulpmiddel

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

  

Levenscyclus en werkstroomstadia van bugs

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

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

Een oplossing controleren

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

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

Sluit een melding wanneer een teamlid heeft bevestigd dat het is opgelost. U kunt echter ook een bug sluiten om een van de volgende redenen. De redenen die u ziet, zijn afhankelijk van het projectproces en de status van de foutovergang.

Agile proces:

• Uitgestelde: Los de foutoplossing uit tot de volgende productrelease.
• Opgelost: Fout wordt geverifieerd als opgelost.
• Duplicaat: Een andere bug die momenteel gedefinieerd is, wordt bijgehouden. U kunt elke bug koppelen met het koppelingstype duplicaat/duplicaat van 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 Backlog: er wordt een user story geopend om de fout bij te houden.

Scrum-proces:

• Geen bug: er wordt gecontroleerd of het geen bug is.
• Duplicaat: Een andere bug die momenteel gedefinieerd is, wordt bijgehouden. U kunt elke bug koppelen met het koppelingstype duplicaat/duplicaat van en een van de bugs sluiten.
• Verwijderd uit de achterstand: De bug is gecontroleerd en bevestigd dat het geen bug is. Verwijder de bug uit de backlog.
• Werk voltooid: Fout wordt geverifieerd als opgelost.

CMMI-proces:

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

Beschrijf meer details voor het sluiten van een fout in het veld Discussie om toekomstige verwarring te voorkomen over de reden waarom de fout is gesloten.

Fouten op een lijst zetten en prioriteren

De meeste teams definiëren, welke optie ze ook kiezen om bugs bij te houden, een of meer bugquery's. 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.

Foutenquery'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 in behandeling (State = Committed of State = Active)
• Fouten die moeten worden opgelost voor een geplande release (Tags Contains RTM)
• Recente bugs, zoals bugs die in de afgelopen drie weken zijn geopend (Created Date > @Today-21)

Wanneer u de gewenste query's voor uw team hebt, maakt u status- of trendgrafieken. 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, kunt u de lijst met actieve bugs uit uw productachterstand bekijken. Met behulp van de filterfunctie kunt u zich alleen richten op bugs. Vanuit de productachterstand kunt u ook de volgende taken uitvoeren:

• Organiseer bugs op uw werkvoorraad. Rangschik bugs in volgorde van belangrijkheid ten opzichte van andere items. Stack-classificatie is uitgeschakeld wanneer filteren is ingeschakeld.
• Wijs bugs toe aan een sprint vanuit uw backlog met 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 op te sommen en te classificeren. In elke sprint ziet u de bugs die zijn toegewezen aan de sprint vanuit de Sprint-backlog of Taskboard.

Taskboard-items versus query-lijstitems

U merkt misschien op en vraagt zich af waarom de items die op een sprint-taskboard worden weergegeven, verschillen van een querylijst die is gemaakt in een overeenkomstige sprint-backlog.

U kunt taken of fouten toewijzen aan een iteratie, maar deze niet 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 ouder backlog-item. Alleen bugs en taken die zijn gekoppeld aan een bovenliggend productachterstanditem (Scrum), gebruikersverhaal (Agile), of vereiste (CMMI) met een iteratiepad dat is ingesteld op de sprint, worden weergegeven op de sprintachterstandpagina.
• De taak of fout is een bovenliggend item van een andere taak of fout, of het gebruikersverhaal is een bovenliggend item van een ander gebruikersverhaal. Als u een hiërarchie van taken, bugs of gebruikersverhalen maakt, worden alleen de taken of verhalen op kindniveau die onderaan in de hiërarchie staan weergegeven. Voor meer informatie, zie Problemen met opnieuw ordenen en nesten oplossen.
• De gekoppelde bovenliggende taak of fout komt overeen met een achterstandspunt dat voor een ander team is gedefinieerd. Of het gebiedspad van het bovenliggende backlog-item van de taak of bug verschilt van het gebiedspad van de taak of bug.

Inlinetests maken die zijn gekoppeld aan softwarebugs

Wanneer uw team bugs bijhoudt als vereisten, gebruik het bord om tests toe te voegen die de bugfixes verifiëren.

Foutstatus bijwerken

Werk de foutstatus bij door bugs naar een nieuwe kolom op een bord te slepen en daar neer te zetten.

• 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, gebruik dan het Taskboard. Zie Uw Taskboard bijwerken en bewaken voor meer informatie.

  

Uw bord aanpassen om tussenliggende statussen bij te houden

Voeg tussenliggende kolommen toe om uw 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:

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 sluit de fout. Zie Regels toepassen op werkstroomstatussen (overnameproces) voor meer informatie.

Status van werkitem instellen in pull-aanvraag

Integratie in Azure DevOps

Een van de methoden die Azure DevOps gebruikt om integratie te ondersteunen, is het koppelen van objecten aan andere objecten. Naast het koppelen van werkitems aan werkitems, kunt u ook werkitems koppelen aan andere objecten. Maak koppelingen naar objecten zoals builds, releases, branches, commits 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 u een TFVC-opslagplaats gebruikt, worden koppelingen naar wijzigingensets en versie-items ondersteund. Als u de koppeling selecteert, 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

U definieert vaak pijplijnen die automatisch moeten 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 bij een buildfout. Zie Een werkitem maken bij een fout voor meer informatie.

De status van bugs, 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. In de volgende twee voorbeelden ziet u bijvoorbeeld actieve bugtrends 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.

Marketplace extensies

U vindt meerdere buggerelateerde extensies in Marketplace. Zie Marketplace voor Azure DevOps.

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

Volgende stappen

Verwante inhoud

• De achterstand van uw product voorspellen
• Uw Taskboard bijwerken