Generel forståelse

Da Azure Test Plans lever "inden i" Azure Devops, er der nogle gennemgående nøglebegreber, som det er vigtigt at kende til for at kunne arbejde effektivt med testen. Disse er beskrevet nedenfor.

Work items

De opgaver, der arbejdes med i Azure Devops, hedder "work items" (i Jira hedder de "Issues"). Der findes forskellige typer af work items, som er organisereret hierarkisk:

Epic
Feature
User story
Task
Bug

Desuden er der følgende work item types, som understøtter test i Azure Devops - og som er udenfor ovenstående hierarki:

Test case
Test plan
Test suite
Shared steps
Shared parameters

Area paths

Area paths gør det muligt at gruppere work items pr. team, pr. produktområde/komponent eller pr. feature.

Man kan definere et hierarki af “paths”.

Area path sættes op på projektniveau, men meget gerne i overensstemmelse med den måde, som man ønsker at kunne rapportere på testen (typisk pr. team, pr. produktområde/komponent).

Iteration paths

Iteration paths gør det muligt at gruppere work items i sprints, milepæle eller andre event-relaterede eller tids-relaterede perioder.

Man kan definer et hierarki af “paths”. Eksempelvis kan et større inkrement inddeles i en række underliggende sprints.

Iteration path sættes op på projektniveau, men meget gerne i overensstemmelse med den måde, som man ønsker at kunne rapportere på testen (typisk pr. sprint, pr. milepæl, pr. prøve).

Boards

Test Plans virker i sammenhæng med boards i Azure Devops.

Der er to boards i Azure Devops, men testcases kan kun vises på det ene:

Boards – backloggen (inkl. user stories, der ligger i sprint). Test foregår på user story-niveau, og testcases vises kun på Board-niveau.
Sprintboard - viser sprintbackloggen og foregår på task-niveau. Testcases vises IKKE i sprintboardet.

På sprint-boardet vises de enkelte user storys som overskrift til de tasks, der skal til for at løse user storien. Her er det ikke muligt at tilknytte testcases. Det betyder, at testprocessen i Azure Devops er følgende:

Tasks testes udforskende i samarbejde med udvikler og i udgangspunktet uden scriptede testcases (ikke at forveksle med struktureret og med scriptede unit-/integrationstests).
Når alle tasks er løst, er user storien klar til at blive testet ved at afvikle de testcases, der fremgår af Board.

Visning af bugs på boards/sprintboard er konfigurerbart. Det anbefales at vælge indstillingen ”Bugs are managed with requirements”, hvilken betyder, at oprettede bugs default lægges i product backloggen, hvor de kan prioriteres og flyttes til det ønskede sprint. Alternativt kan bugs håndteres som tasks, dvs. de oprettede bugs lægges direkte i det aktive sprint under en user story. Denne indstilling fordrer dog, at alle bugs er tilknyttet en user story, hvilket ikke altid vil være tilfældet.

Teams

Sammenhæng mellem teams og testplaner/testsuites:

Hvert team kan have sine egne testplaner/suites
På testplaner og testsuites angives både iteration og area path. Area path angiver det team, testplanen/suiten skal tilknyttes.
Flere teams kan "abonnere" på det samme area path.