onsdag den 13. november 2024

Test i en agil kontekst: Fremgangsmåde, teknikker og værktøjer

I en agil udviklingsmetode, som Scrum eller Kanban, er test en integreret del af udviklingscyklussen snarere end en separat fase, der følger efter udviklingen. Det betyder, at test er noget, der sker kontinuerligt og i tæt samarbejde med udviklerne. Dette kræver en ændret tilgang til teststrategi, teknikker og værktøjer. I dette blogindlæg dykker vi ned i test i en agil kontekst, ser på fremgangsmåder, testteknikker, styrker og faldgruber, samt de værktøjer der understøtter en effektiv agil testproces.

I agile metoder er test ikke en afsluttende fase, men en kontinuerlig aktivitet, der foregår parallelt med udviklingen. Dette betyder, at testere arbejder tæt sammen med udviklerne fra starten af projektet, og test udføres løbende på små, ofte meget små, inkrementer af funktionalitet.

Scrum er et af de mest anvendte agile rammeværk, hvor testere arbejder sammen med udviklerne i sprints (2-4 uger). På hver sprint afsluttes et arbejdspakke, der potentielt er en fungerende produktinkrement. Testene for hver funktionalitet udføres løbende som en del af Definition of Done (DoD) for sprinten.

I Kanban er der mindre struktur, og arbejdet sker kontinuerligt. Her er test ligeledes integreret i udviklingsflowet, hvilket kræver løbende test og hurtig feedback.

I agile projekter er der ofte ikke detaljerede testplaner på forhånd. I stedet fokuseres der på at have en kontinuerlig feedback-loop mellem udviklerne og testerne, så eventuelle problemer kan opdages hurtigt og rettes hurtigt. Testene bliver prioriteret ud fra den funktionalitet, der er vigtigst for forretningsværdien i det aktuelle sprint eller iteration.

Eksempel: Hvis en test fejler, bliver det hurtigt kommunikeret til udvikleren, som kan rette fejlen med det samme. Efter fejlrettelsen kører testen igen for at bekræfte, at fejlen er løst og at systemet stadig fungerer korrekt.

Testdrevet udvikling (TDD) er en teknik, der er meget populær i agile metoder. Her skriver udvikleren først en test for den funktionalitet, der skal implementeres, før koden skrives. Det sikrer, at funktionaliteten er testet, så snart den er udviklet.

 TDD workflow:

1. Skriv en test, der fejler (den skal fejle, fordi den funktionalitet, som testen dækker, ikke er implementeret endnu).

2. Implementer den funktionalitet, som testen dækker.

3. Kør testen, og sørg for, at den passer (testen skal passere).

4. Refaktorer koden (hvis nødvendigt), og kør testen igen for at sikre, at alt stadig fungerer.

TDD hjælper med at sikre, at systemet konstant er i en 'grøn' tilstand og hjælper med at fange fejlene tidligt.

BDD er en teknik, hvor test er skrevet i et formelt sprog, som både udviklere og ikke-tekniske interessenter kan forstå. Det betyder, at test scenarier er skrevet i et sprog som "Givet at", "Når", "Så". BDD fokuserer på systemets adfærd og sikrer, at funktionaliteterne lever op til brugerkravene.

Eksempel på BDD test:

- Givet en bruger er logget ind

- Når de klikker på 'Opdater Profil'

- Så skal de se en besked om, at deres profil er opdateret.

BDD-rammeværktøjer som Cucumber eller SpecFlow understøtter denne tilgang og gør det muligt at køre automatiserede tests baseret på adfærd.

Exploratory test er en teknik, hvor testeren udforsker applikationen uden en foruddefineret testplan eller testdesign. Dette kan give indsigt i problemer, som automatiserede tests eller mere strukturerede tilgange ikke nødvendigvis fanger. Teknikken kombinerer testdesign og eksekvering i én proces, hvilket gør det muligt for testeren at tilpasse sig systemet i realtid.

Exploratory test er særligt nyttig i agile miljøer, hvor kravene ofte kan ændre sig hurtigt, og der er behov for hurtig tilpasning.

Test i en agil kontekst muliggør tidlig identifikation af fejl, hvilket reducerer omkostningerne ved fejlrettelse. Når test og udvikling sker parallelt, opfanges problemer hurtigt og kan rettes med det samme. Det betyder også, at kvaliteten af systemet kontinuerligt forbedres, og man undgår store fejlafsløringer i slutningen af projektet.

Agil test giver en tættere kobling til de forretningsmæssige krav. Testere og udviklere arbejder tæt sammen med produktpersonen for at sikre, at det, der udvikles, faktisk opfylder brugerens behov. Derfor er testene mere relevante og fokuserede på brugerens oplevelse.

En agil testmetode giver løbende feedback, både for udviklerne og for testerens egen proces. Hvis der opstår et problem, er det hurtigt at identificere, og det kan tages hånd om uden forsinkelse. Dette skaber en kontinuerlig forbedringsproces.

Da agile processer er meget fleksible og reaktive, kan der være en tendens til at fokusere på de funktionaliteter, der giver mest værdi på kort sigt. Det betyder, at testdækningen kan være utilstrækkelig, især i mindre komplekse områder af systemet, hvor det ikke er økonomisk forsvarligt at udvikle omfattende automatiserede tests.

I agile teams kan testere være involveret i alle faser af udviklingen, hvilket kan føre til overbelastning. Hvis ikke rollen som tester er klart defineret, kan det føre til, at testere bliver distraheret fra deres primære opgave – at sikre kvalitet – og i stedet arbejder på udviklingsopgaver.

I agile projekter kan testdata og testmiljøer ikke altid være tilgængelige i tide. Dette kan forårsage forsinkelser, især når man arbejder med store, komplekse systemer, der kræver realistiske testmiljøer.

Test i en agil kontekst kræver en ændret tilgang til både teststrategi og teknikker. Fokus på tidlig fejlfinding, tæt samarbejde med udviklerne, og løbende feedback er alle væsentlige elementer i en succesfuld agil testproces. Samtidig er det vigtigt at være opmærksom på de faldgruber, der kan opstå, og være klar til at justere teststrategien løbende

Med de rette værktøjer og metoder kan du sikre, at kvaliteten i et agil udviklingsmiljø er både høj og kontinuerlig.