Hvad laver en softwaretester i et agilt udviklingsteam?
Når udviklingsteams vil arbejde agilt og levere iterativt i korte sprints, kan det være svært at finde ud af, hvad testerens rolle i et agilt team egentlig er.
I dette indlæg vil jeg beskrive softwaretesterens nye rolle i et agilt setup. Denne rolle er markant anderledes i et agilt team, sammenlignet med et traditionelt team. Det er vigtigt at anerkende og forstå hvad det indebærer, både som Scrum Master, softwareudvikler og Test Manager.
Det agile manifest og testerens rolle
I principperne fra det agile manifest, samt i beskrivelsen af Scrum og XP, indgår udviklerrollen flere gange, men ingen steder indgår eller beskrives rollen som softwaretester eller tester. I nogle organisationer drages der derfor den fejlagtige konklusion, at rollen som softwaretester ikke indgår i “udviklerteamet”.
Scrum og XP beskriver ikke blot en separat tester-rolle, men inkluderer kompetencen i det krydsfunktionelle udviklerteam. Dermed gøres op med den ellers solidt forankrede opfattelse, at test er et ansvar for få udvalgte personer. Nu er det et fælles ansvar i udviklingsteamet.
Jeg opdeler i denne artikel udviklerrollen i softwareudvikler og softwaretester. Betegnelse udvikler er en fællesbetegnelse for softwareudvikler og softwaretester.
Hvem har rollen som softwaretester
I mange agile teams vil det være et eller flere teammedlemmer, der har rollen som softwaretester.
På trods af intentionen om at arbejde agilt, kæmper mange udviklingsteams med at komme fra et vandfaldsprojekt – med en separat og længere test-fase – over til et mere agilt udviklingsforløb, med løbende levering af små, værdiskabende leverancer. Dette skyldes, at udviklingsteamets kvalitetssikring er optimeret til en faseopdelt vandfaldsmodel og ikke bruger agile testpraktikker. Testerens rolle bliver dermed den samme, som dét den er i et vandfaldsprojekt.
En god beskrivelse af forskellen på den klassiske og den agile tilgang til kvalitetssikring, findes i GrowingAgiles “Testing Manifesto”.
De fem principper beskrevet i dette agile test-manifest, giver et godt udgangspunkt for hvad der er vigtigt at fokusere på, med hensyn til testerens rolle i et agilt team.
Softwaretesterens nye rolle
I modsætning til den klassiske vandfaldsmodel, er test en integreret del i hele den agile udviklingsproces. Softwaretesterens rolle er dermed også markant anderledes.
I den klassiske vandfaldsmodel er det testerens ansvar at lave kvalitetskontrol, ved at definere, beskrive og eksekvere test-cases, samt rapportere om kvaliteten er god nok til at release. For at kvalitetssikringen kan fungere i et agilt team, er det dog vigtigere, at hele teamet har et ansvar for kvaliteten.
For at gøre test til en integreret del af udviklingsteamets arbejde (built-in quality), er der en række forudsætninger, der skal være opfyldt:
- Testbare acceptkriterier skal være identificeret og beskrevet i samarbejde med forretningen og softwareudviklerne
- Ikke-funktionelle krav skal være identificeret inden implementeringen starter, så behov for sikkerhed, brugervenlighed, performance osv. er afklaret tidligt i forløbet
- Forretningsbehov skal være opdelt i mindre og testbare dele, så test kan starte tidligt og ske parallelt med implementeringen
- Softwaretesteren samarbejder direkte med softwareudviklerne for at afklare strategien for test-eksekveringen, så det er let at ændre og tilføje funktionalitet uden den manuelle testbyrde bliver en flaskehals
- Softwaretesteren skal sammen med softwareudviklerne have et overblik over, hvilke krav der er dækket af automatiseret test og hvilke, der ikke er
- Der skal ligge en klar aftale om hvordan fejl hurtigt synliggøres og kritikalitet klarificeres. Her kan udviklingsteamet eventuelt finde inspiration i ”zero bug”-princippet, for at sikre, at kritiske bugs altid prioriteres over ny funktionalitet
Scrum Masterens rolle
Scrum Masteren kan for det enkelte team hjælpe med at sikre den rette dialog og at de rigtige kompetencer er til stede på ‘refinement’ og ‘Sprint Planning’.
Desuden kan ovenstående punkter være input til teamets ‘Definition of Ready’ og ‘Definition of Done’.
Zero bug-princippet kan også være et input, der kan mindske antallet af features der er i gang med at blive implementeret (begrænsning af WIP) og et emne der kan tages op på et ‘retrospektiv’ i teamet.
Hvordan kan I få støtte til en agil tilgang til kvalitetssikringen?
Kender du nogle af udfordringerne skitseret ovenfor? Jeg møder disse udfordringer i mange af de teams jeg hjælper med at komme i gang med agil test.
Ofte hænger disse udfordringer sammen med at levere værdi løbende og evnen til at bryde opgaver ned i små, værdiskabende leverancer. Det har jeg talt mere om i vores podcast-afsnit Podcast#30 – Typiske udfordringer ved at levere værdi hvert sprint i Den Agile Podcast.
Hvis du eller dit team mangler hjælp eller inspiration til at komme i gang – eller til at løfte jer til næste niveau – er du altid velkommen til at kontakte mig. Jeg tilbyder bl.a. at hjælpe eksisterende teams. Se hvordan her via et forløb, der skaber større sammenhæng mellem krav, kode og test. Se min profil på ugilic.dk/philip for mere information om mig og mine kontaktoplysninger. Du kan også læse mere her og booke en uforpligtende samtale.
