lørdag den 18. november 2017

Skal testerne være med i sprintet eller ej?

Pixabay / Pexels

I agile udviklingsprojekter syntes jeg at have stødt på dette spørgsmål mange gange. Virkeligheden er, at jeg kan se fordele og ulemper i begge løsninger.

Jeg skal måske lige starte med en disclaimer: Jeg er godt nok certificeret Scrum master, men jeg er på ingen måde certificeret agil tester, jeg har dog en bred erfaring med test i agile projekter og det er den erfaring jeg lader tale i denne artikel.

For at holde det simpelt antager vi at der kun er to løsninger her: At testerne er med i sprint-teamet eller de ikke er.

Testerne skal være med i teamet

Hvis testerene er med i teamet, levere teamet ikke kun en implementeret feature, men en implementeret og testet feature senest ved sprintslut. Det er utroligt brugbart for de projekter hvor man rent faktsik går live med sit produkt efter hver sprint (eller hvornår det nu passer ind) og naturligvis også for de projekter der benytter sig af Continuous Delivery (CD). Teams der kører på denne måde har efter min mening også nemmere ved at dels holde sustainable phase og dels at holde testpyramiden sådan at den absolut største del af testen kommer til at ligge i unit og unit-integrations niveauet.

Det er en forudsætning for at det bliver en succes at have testerne som en del af teamet at ens stories er nogen lunde velstrukturerede og at der er en product owner tilgængelig til at svare på spærgsmål. Årsagen til dette er naturligvis at testere generelt er et meget spærgelystent folk, og da vi er nødt til at vide hvordan produktet er skruet sammen, bliver vi simpelt hen ved med at spørge indtil vi får svar. En del af det svar er nok også at testere jo ikke har bygget produktet, og derfor ikke kan forventes at vide alle detaljerne hvorfor det ikke fremstår som “dumme spørgsmål” når testeren beder om den tredie uddybelse af en funktion den dag :-)
Man kan sige at det er et succeskriterie for ethvert agilt team at der er styr på det, men min erfaring siger mig at teams med integreret test er mere følsomt overfor mindre gode product ownere eller product ownere der ikke er til stede eller på anden vis ikke fungere godt.

Samarbejdet mellem udviklere og testere kommer helt naturligt til at blomstre når men er en del af samme team. Og her skal testeren være varsom, for man skal værne om sin objektivitet og sin uafhængighed til produktet. En måde at sikre dette er ved ikke at committe produktionskode nogen sinde. Det er op til udviklerene. Som tester committer jeg kun testkode, men jeg kan godt hjælpe med at skrive dokumentation som jo som oftest er en kærkommen hjælp. Jeg har dog også set det andet ske, hvor en tester begyndt at påtage sig udvikler opgaver som vedkommende sagtens kunne løse, men det gik meget ud over testarbejdet da han begyndte at tage parti overfor produktet, hvilket forminskede hans uafhængighed og objektivitet betydeligt som så igen betød at han leverede en miondre god indsats som tester.

Testerne skal ikke være med i sprintet

Det her er så den modsatte synsvinkel. I dette setup er det ret tit testerne der står for klargøring af stories til udvikling. Dette sker naturligvis i samarbejde med PO, men testerne, dem der arbejder som rtest analytikkere eller tekniske testere, ender ofte med at blive en slags refinement managere (jeps, det er et seperat blogpost, og det er op vej). Det har den positive effekt at stories ret ofte er ret godt forberedt, og det har en meget positiv effekt på udviklingsforløbet. Det har desværre også den bagside at testerens mulighed for at sikre testpyramiden er ved at inkludere instruktioner til hvad der minimum skal dækkes af unit test til udviklerene.
Hvis man bliver klogere som tester efter at story er lagt i sprint, så går det ofte sådan at det er integrationstesten der bliver udvidet med de ting man er blevet klogere på, og ikke unit testen. Jeg ved ikke om det kun er derfor eller om der også er andre grunde, men jeg ser tit at teams der køre med testere der ikke er med i sprintet har en forholdsvis stor mængde integrationstest i forhold til mængden af unit og unit-integrations test = testpyramiden er ikke blevet overholdt.

Til gengæld er der ingen problemer med at holde sig uafhængig når man ikke er med i teamet. Den naturlige afstand der kommer ved det vil sørge for at man som tester bevarer sin uafhængighed. Det der til gengæld kan blive lidt udfordrende er at have testen klar samtidigt med udviklingen, specielt i pressede perioder op til milestone releases f.eks da det kan være svært at nå at teste mens der bliver udviklet på en story. Dette løses som regel med en testperiode efter sprintet hvor det tjekkes at den test der er blevet upfundet til at tjekke integrationer også virker og ikke finder noget uforudset. I den ægte agile verden er dette ikke velset da det forsinker processen, men i nogle agiel setups, f.eks SAFe, fungere det fint.

Begge disse modeller kan fint have deres berettigelse, men jeg personligt kan bedst lide den første i det den er mest agil i forhold til at kunne skifte retning rekalibrere under vejs i projektet. Jeg kan på den anden side også godt tænke tilbage til nogen af de projekter jeg har været på hvor det ikke ville være den rigtige styringsform.

2 kommentarer: