Forudsætninger

Forudsætninger for at komme i gang med at anvende Azure Test Plans:

• Der skal være oprettet et projekt i Azure Devops
• Der skal sikres de rette brugerrettigheder og -adgange
  • Som test manager er der behov for at kunne oprette testplaner og testsuites, hvilket kræver den store Test Plans-licens.
  • Som tester/udvikler er der behov for at kunne oprette testcases og afvikle testpoints, hvilket kun  kræver basic licens.

Proces

Når man arbejde med testplanlægning og testafvikling i Azure Test Plans, er processen som følger:

1. Opret testcases (kan også oprettes direkte under testsuiten – eller på et senere tidspunkt) 
2. Opret testplan (kræver Test Plans-licens)
3. Opret testsuites (kræver Test Plans-licens)
4. Opret eventuelle konfigurationer og assign til testplan/testsuite/testcase
5. Afvikl testpoints
6. Rapporter eventuelle fejl
7. Gentest ved at genafvikle testpoints (alternativt opret en ny testplan/testsuite, tilknytte de relevante testcases og afvikl testpoints).
8. Lav løbende opfølgning ved hjælp af "progress report" og andre relevante udtræk/´dashboards.

Yderligere information

​https://trailheadtechnology.com/properly-tracking-manual-testing-in-azure-devops/

• ​En testplan i Azure Test Plans er sit eget "work item", dvs. den har sin egen ID og kan fremsøges på forskellige vis.
• En testplan kan have testcases direkte under sig, eller den kan struktureres i en eller flere testsuites.
• ​​Det anbefales at oprette en ny testplan pr. sprint, pr. relase/milepæl/inkrement og pr. prøve.

• ​​En testsuite i Azure Test Plans er sit eget "work item", dvs. den har sin egen ID og kan fremsøges på forskellige vis.​
• En testsuite er en samling testcases, ​som grupperes i en egen ”mappe” under en testplan.
• Der kan oprettes mange testsuites under samme testplan.
• Der kan oprettes testsuites i testsuites, så man kan lave en folderstruktur (alle summeres op på øverste niveau).
• Man kan klone en suite fra en anden testplan i samme projekt eller fra et andet projekt.
• En testsuite består af tre elementer:
  • Define-fane (oversigt over testcases indeholdt i suiten)
  • Execute-fane (oversigt over testpoints indeholdt i suiten, disse kan afvikles)
  • Chart-fane (giver mulighed for visning af forskellige metrikker for testdesign og for testafvikling).

• ​Der er tre typer testsuites, som beskrives nærmere nedenfor:

  • Static suite
  • Requirement based suite
  • Query based suite

Static testsuite

• Opretter en tom suite uden tilknyttede testcases
• Testcases oprettes direkte i suiten eller eksisterende testcases tilføjes
• Suiten opdateres ikke automatisk, når der oprettes nye testcases.
• Anbefalet anvendelse:
  • Prøver, hvor suiten skal fastfryses, og hvor der ikke må ske automatisk opdatering undervejs i prøven.
  • Projekter, hvor det er vigtigt, at suiten er fastfrossent, og hvor der ikke automatisk må tilføjes nye krav og/eller testcases.

Requirement based testsuite

• Tilføjer requirements (= user stories) og deres tilhørende testcases til testplanen
• Der oprettes en suite pr. user story
• Suiten indeholder alle de testcases, der er relateret til user story.
• Når der tilføjes nye testcases til user stories, tilføjes de automatisk til suiten.
• Når der oprettes nye user stories tilføjes disse IKKE automatisk som suites under testplanen. De skal udsøges og tilføjes efterfølgende.
• Anbefalet anvendelse: 
  • Sprinttest, hvor user stories pr. sprint er fastlagt ved sprintstart, og hvor testen løbende udbygges med nye testcases undervejs i sprintet.
  • Prøver, hvor krav skal efterprøves,
    • og hvor krav i form af epics/features er oprettede i Azure Board,
    • og hvor det er usandsynligt, at der oprettes nye epics/features, dvs. der er ikke risiko for, at testscope i suiten ændres ved en automatisk opdatering.

Query based testsuite

• Fremsøger og tilføjer de testcases, der skal indgå i suiten via en query
• Når der oprettes nye testcases, der matcher querien, eller når der opdateres/slettes i eksisterende testcases, opdateres suiten automatisk.
• Anbetalet anvendelse:
  • Eksempelvis regressionstest, hvor testcases tagges på tværs af user stories og sprints, og hvor suiten gerne må opdateres automatisk.

Tildel testcases til testere

• Tildel testcases til relevante personer - typisk til den tester, der skal afvikle testcasen
• Testcases kan tildeles enkeltvis - eller alle testcases i en testsuite kan tildeles på en gang
• Tester, der assignes til en gruppe testcases i en testsuite, kan notificeres herom via mail.

Ændre rækkefølgen af testcases (testafviklingsplan)

• Man kan ændre den rækkefølge, testcases skal afvikles i.
  • Man kan ændre rækkefølgen, som testsuites står i ved at anvende "drag and drop".
  • Man kan ændre rækkefølgen, som testcases i en testsuite står i, ved at anvende "drag and drop" i Define-fanen

Opsætning

• ​Man skal konfigurere, hvordan man gerne vil have håndteret indrapporterede fejl (bugs). Det gøres under Boards > Team configuraion:
  • ​Konsekvens af konfiguration
    • 1. Bugs lægges i backloggen (anbefalet)
    • 2. Bugs lægges i sprintet
    • 3. Bugs lægges i hverken backlog eller sprint
• Det anbefales at vælge opsætning 1. Der kan være oprettet fejl, som ikke er relateret til krav/User Stories, og som stadig skal kunne prioriteres ind i et (kommende) sprint. Ved af vælge opsætning 1 kan bugs således findes i backloggen og lægges i det ønskede sprint.

Forslag til metrikker for fejl

• ​Brug queries til at udarbejde charts over relevante metrikker til opfølgning på bugs.
• Man kan tilføje test-charts´ene til teamets eller projektets dashboard for at sikre fælles fokus på status og fremdrift.
• ​Her er forslag relevante charts:
  • Åbne bugs pr. prioritet (State <> Done or State <> Closed)
  • Bugs, der skal rettes i en target release (tags Contains RTM)
  • Seneste bugs - bugs oprettet indenfor de seneste tre uger (Created Date > @Today-21)

• For hurtigt overblik over en test kan "Progress report" anvendes - her kan man nemt på vist test-fremdrift på tværs af testplaner og testsuites. 
• Rapportering på forskellige typer af work items (som eksempelvis bugs, user stories og testcases) kan desuden anvende Queries til at udsøge sit datagrundlag, som man efterfølgende kan præsenteres i forskellige charts på dashboardet.
• Nogle testcharts er prædefinerede og kræver ikke, at man først laver en querie - disse findes på chart-fanen for testplanen eller for testsuite.
• Man kan tilføje test-charts til teamets eller projektets dashboard for at sikre fælles fokus på status og fremdrift.
• Man kan ikke søge på work item typen "testsuite" eller "testplan" og eksempelvis få vist alle de fejl, der er fundet i testplanen/testsuiten via den ordinære søgning. Hvis man ønsker dette relevante overblik, skal man istedet benytte søgning på linked work items ved at anvende ”Work items and direct links”.

  • ​Dette forudsætter, at bugs linkes til relevant testplan med relationen ”Related”. ​Det samme gælder testcases.

Yderligere information

Bugs relateret til testplan/testsuite​
https://learn.microsoft.com/en-us/azure/devops/boards/queries/linking-attachments?view=azure-devops&tabs=browser

Progress report
https://learn.microsoft.com/en-us/azure/devops/test/progress-report?view=azure-devops

Eksempler på forskellige queries
https://learn.microsoft.com/en-us/azure/devops/boards/queries/query-index-quick-ref?view=azure-devops

Flytte user stories mellem teams

• Hvis man flytter en user story fra et team til et andet (ved at ændre area path), skal man være opmærksom på, at allerede oprettede testplaner og testsuites ikke automatisk flyttes med. Det er derfor nødvendigt manuelt at flytte både testplan og testsuites til det nye team ved at ændre area path på disse.

Testsituationer og bedste praksis