Jeg vil lige starte med en lille disclaimer – dette er ikke det universelle svar på hvordan man organiserer test i Azure DevOps. Jeg er ikke adminisrtator eller 100-meter mester, men det er en række praktiske erfaringer jeg har gjort mig her på det sidste. Samtidig skal det nævnes at jeg i det følgende kun fokuserer på den manuelle test da det var opgaven.
Det sidste stykke tid har jeg nemlig brugt lidt kræfter på at forstå Azure DevOps testplan modulet, og det har været et rigtig interessant forløb hvor jeg blandt andet er kommet til konklusionen om at spejderbevægelsens motto ”learning by doing” giver så meget mening.
Jeg har i det følgende forsøgt at samle lidt af de erfaringer jeg har gjort mig, både i forhold til at komme i gang med opgaven men også styrker og svagheder ved applikationen undervejs.
- Få styr på hvad du egentlig har brug for: Lad være med bare at kaste dig over applikationen og begynde at konfigurere i vildskab, sæt dig ned og overvej hvilke krav/behov du egentlig har, og husk ikke at gøre det alene; tal med teamet, Scrum Master, Product Owner og evt. andre interessenter. Du skal ikke lave en kæmpe kravspecifikation, men start med nogen grundlæggende krav og lær undervejs… du ved den agile metode.
- Lær og Eksperimenter: Jeg har i udstrakt grad brugt tutorials mv på Microsofts side, og ikke mindst videoer på Youtube til at komme i gang. Men derefter så handler det om at eksperimentere og lære; Lav en sandkasse i Azure hvor du kan lege med applikationen uden at det påvirker dem der sidder og arbejder med det til dagligt.
- Brug Community: En af de første ting jeg gjorde, var at oprette mig i Microsofts community, og det har jeg haft stor gavn af. Når ting ikke opfører sig som jeg synes det burde, når jeg mangler funktionalitet eller når jeg gerne vil aflevere en bug. De reagerer ultrahurtigt og jeg har også undervejs fået godkendt en ny feature til Azure, så de lytter.
- Få styr på sporbarhed mellem stories og test cases: Brug konceptet ”requirement based test suites” og map til dine user stories, så får du skabt en transparens i forhold til hvilken test der udføres for de enkelte user stories.
- Forstå forskellen på copy og clone: Hvis du genbruger test cases på kryds og tværs så er det ret væsentligt. Hvis du bruger ”add existing testcases” så skaber du en reference til en eksisterende testcase og ændringer vil dermed smitte af. Hvis du bruger ”create copy of work item” så er det en ny test case du laver og ændringer vil IKKE smitte af. Rimelig væsentlig detalje faktisk.
- Skab transparens på status på storyniveau: Du kan samle op på status på test på flere niveauer og måder;
Chart pr user story, pr sprint (I det hele taget pr test suite)
Test design status pr user story I sprint board
Test afviklings status pr user story i board. Det er så her jeg har bedt om en ny feature idet man ikke kan få test afviklingsstatus med pr user story i sprintboardet, kun i det der hedder board. - Status på test i sprintet, eller releasen. Du kan nede i testplanen skabe grafer/charts på plan eller suite niveau som giver overblik over fremdrift og status, og det kan konfigureres lige som du har brug for. Men også de to områder ”Progress” og ”Runs” giver dig detaljer status på de enkelte planer og runs.
- Skab sporbarhed mellem stories, tests og fejl. Opret fejl du finder ved afvikling af testcases INDE fra testafviklingsvinduet, så skabes automatisk relation mellem testcase og fejl. Og når du så skal verificere rettelsen så åbn fejlen og brug ”verify” funktionen – så får du testcasen til genkørsel og du får opdateret status på begge.
- Let søgningerne – brug også tags i test cases: Hvis du som jeg skal skabe manuelle retressionstests suiter til brug for test af den samlede leverance så letter det søgningerne gevaldigt at have sat tag på testcases efterhånden. Feks ligger testcases for en feature jo i de enkelte requirement based suites pr story, de er nemme at samle bagefter hvis du har givet dem samme tag.
- Vær opmærksom på add-ons. Der kan tilføjes en gevaldig mængde add-ons til Azure DevOps, så går det helt i hårdknude med at implementere et af dine krav så kunne det jo være der var en add-on der kunne hjælpe. For mig gjaldt det f.eks. at jeg skal kunne eksportere testcases til Excel, det kan man ikke lige nu (de er vist ved at lave en feature der handler om import/export men den er der ikke nu). Men så fandt jeg den add-on der handler om ”offline test case execution”, og den eksporterer testcases i den valgte suite til excel. Men også en add-on som den enkelte tester kan installere så det er nemmere at lave screenshots, videoer mv og tilknytte testcaseafvikling og fejl.
Det var min top ti, jeg håber den måske har kunnet skabe lidt inspiration hos dig til, hvordan du kan bruge Azure DevOps til at få styr på din test i en hverdag i en agil kontekst. Men det vigtigste er nok tip nr 2; Lær og eksperimenter
Hvis du vil have lidt mere i detaljen omkring de ti punkter, så kan du downloade et lille skriv her.
Hvis du gerne vil høre mere om implementering af Azure DevOps og hvordan vi kan hjælpe dig, så ring til Margit Sejerkilde på 49408060.