Traceerbaarheid van vereisten

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

De traceerbaarheid van vereisten is de mogelijkheid om twee of meer fasen van een ontwikkelingsproces te relateren en te documenteren, die vervolgens zowel vooruit als achteruit kunnen worden getraceerd vanaf de oorsprong ervan. Vereisten traceerbaarheid helpt teams inzicht te krijgen in indicatoren zoals kwaliteit van vereisten of gereedheid om de vereiste te verzenden. Een fundamenteel aspect van de traceerbaarheid van vereisten is het koppelen van de vereisten om cases, bugs en codewijzigingen te testen.

Lees de woordenlijst om inzicht te hebben in de terminologie van het testrapport.

Agile-teams die geautomatiseerde tests uitvoeren

Agile-teams hebben kenmerken, waaronder, maar niet beperkt tot het volgende

• Snellere releasecycli
• Doorlopend testen in een pijplijn
• Verwaarloosbare handmatige testvoetafdruk; beperkt tot verkennende tests
• Hoge mate van automatisering

In de volgende secties worden de traceringspunten van kwaliteits-, bug - en bronpunten voor Agile-teams verkend.

Kwaliteit traceerbaarheid

Om ervoor te zorgen dat gebruikersvereisten voldoen aan de kwaliteitsdoelstellingen, kunnen de vereisten in een project worden gekoppeld aan testresultaten, die vervolgens kunnen worden weergegeven op het dashboard van het team. Dit maakt end-to-end traceerbaarheid mogelijk met een eenvoudige manier om testresultaten te bewaken. Als u geautomatiseerde tests wilt koppelen aan vereisten, gaat u naar het testrapport in build of release.

1. Selecteer in de sectie resultaten onder het tabblad Tests van een build- of releaseoverzicht de test(en) die u wilt koppelen aan vereisten en kies Koppeling.

   

2. Kies een werkitem dat u wilt koppelen aan de geselecteerde test(en) op een van de opgegeven manieren:

   • Kies een van toepassing werkitem in de lijst met voorgestelde werkitems. De lijst is gebaseerd op de laatst bekeken en bijgewerkte werkitems.
   • Geef een werkitem-id op.
   • Een werkitem zoeken op basis van de titeltekst.

   

   In de lijst worden alleen werkitems weergegeven die behoren tot de categorie Vereisten.

3. Teams willen vaak de samengevatte weergave van de tracering van vereisten vastmaken aan een dashboard. Gebruik hiervoor de kwaliteitswidget Vereisten.

   

4. Configureer de widget Vereistenkwaliteit met de vereiste opties en sla deze op.

   • Vereistenquery: Selecteer een werkitemquery die de vereisten vastlegt, zoals de gebruikersverhalen in de huidige iteratie.
   • Kwaliteitsgegevens: Geef de fase van de pijplijn op waarvoor de kwaliteit van de vereisten moet worden getraceerd.

   

5. Bekijk de widget in het dashboard van het team. Hierin worden alle vereisten in het bereik vermeld, samen met de wachtwoordfrequentie voor de tests en het aantal mislukte tests. Als u het aantal mislukte tests selecteert, wordt het tabblad Tests voor de geselecteerde build of release geopend. De widget helpt ook bij het bijhouden van de vereisten zonder bijbehorende test(en).

   

Traceerbaarheid van fouten

Testen geeft een meting van het vertrouwen om een wijziging aan gebruikers te verzenden. Een testfout geeft een probleem aan met de wijziging. Fouten kunnen om vele redenen optreden, zoals fouten in de bron onder test, ongeldige testcode, omgevingsproblemen, flaky tests en meer. Bugs bieden een robuuste manier om testfouten bij te houden en verantwoordelijkheid in het team te stimuleren om de vereiste herstelacties uit te voeren. Als u bugs wilt koppelen aan testresultaten, gaat u naar het testrapport in build of release.

1. Selecteer in de resultatensectie van het tabblad Tests de tests waarvoor de fout moet worden gemaakt en kies Bug. Meerdere testresultaten kunnen worden toegewezen aan één bug. Dit wordt meestal gedaan wanneer de reden voor de fouten is toe te schrijven aan één oorzaak, zoals de onbeschikbaarheid van een afhankelijke service, een databaseverbindingsfout of soortgelijke problemen.

   

2. Open het werkitem om de fout te zien. Hiermee wordt de volledige context van de testresultaten vastgelegd, waaronder belangrijke informatie, zoals het foutbericht, stacktracering, opmerkingen en meer.

   

3. Bekijk de fout met het testresultaat, rechtstreeks in context, op het tabblad Tests . Het tabblad Werkitems bevat ook eventuele gekoppelde vereisten voor het testresultaat.

   

4. Navigeer vanuit een werkitem rechtstreeks naar de bijbehorende testresultaten. Zowel de testcase als het specifieke testresultaat zijn gekoppeld aan de bug.

   

5. Selecteer in het werkitem Testcase of Testresultaat om rechtstreeks naar de pagina Tests voor de geselecteerde build of release te gaan. U kunt de fout oplossen, uw analyse bijwerken in de bug en de wijzigingen aanbrengen die nodig zijn om het probleem op te lossen, indien van toepassing. Hoewel beide koppelingen u naar het tabblad Tests leiden, isde standaardsectie geschiedenis en foutopsporing respectievelijk.

   

Traceerbaarheid van bron

Bij het oplossen van testfouten die consistent optreden gedurende een bepaalde periode, is het belangrijk om terug te gaan naar de eerste set wijzigingen, waarbij de fout afkomstig is. Dit kan aanzienlijk helpen bij het beperken van het bereik voor het identificeren van de problematische test of bron die wordt getest. Als u het eerste exemplaar van testfouten wilt detecteren en deze wilt traceren naar de bijbehorende codewijzigingen, gaat u naar het tabblad Tests in build of release.

1. Selecteer op het tabblad Tests een testfout die moet worden geanalyseerd. Kies op basis van of het een build of release is, de kolom Mislukte build of Mislukte release voor de test.

   

2. Hiermee opent u een ander exemplaar van het tabblad Tests in een nieuw venster, met het eerste exemplaar van opeenvolgende fouten voor de test.

   

3. Op basis van de build- of release-pijplijn kunt u de tijdlijn of pijplijnweergave kiezen om te zien welke codewijzigingen zijn doorgevoerd. U kunt de codewijzigingen analyseren om de mogelijke hoofdoorzaak van de testfout te identificeren.

   

Traditionele teams die gebruikmaken van geplande tests

Teams die overstappen van handmatig testen naar continue (geautomatiseerde) tests en een subset van tests hebben die al zijn geautomatiseerd, kunnen ze uitvoeren als onderdeel van de pijplijn of op aanvraag (zie testrapport). Ook wel gepland testen genoemd, kunnen geautomatiseerde tests worden gekoppeld aan de testcases in een testplan en uitgevoerd vanuit Azure Test Plans. Zodra deze tests zijn gekoppeld, dragen deze tests bij aan de metrische kwaliteitsgegevens van de bijbehorende vereisten.

Help en ondersteuning

• Zie onze pagina voor probleemoplossing
• Krijg advies over Stack Overflow en krijg ondersteuning via de Ontwikkelaarscommunity