Spela Roll! Spelar Roll? – Vad händer med testrollerna i en agil organisation?

I takt med att fler och fler företag och organisationer väljer att införa agila utvecklingsprocesser så visar det sig allt tydligare att de traditionella testrollerna behöver förändras. I denna blogg skissar jag lite på hur testningen kan se ut i en scrum-baserad utvecklingsprocess och så pekar jag på några av de förändringar i rollerna som blir följden.

För att tydliggöra skillnaderna behöver jag först rekapitulera det traditionella upplägget. I den vanliga vattenfallsmodellen genomförs utveckling i ett antal steg där varje steg har en motsvarande testfas. Testfaserna (eller testnivåerna som de också kallas) följer på varandra och fokuserar på att testa succesivt större och större objekt.

Låt oss för enkelhetens skull anta att vi har tre testfaser: komponenttest, integrationstest och systemtest. I ett sådant upplägg har oftast utvecklaren även en testroll, i vilken genomförandet av komponenttest ingår. I integrationstestfasen kan det variera, antingen är det även här utvecklaren som i en testroll genomför testningen eller så görs den av dedikerade testare. Om integrationstestningen genomförs av dedikerade testare brukar det även finnas en testledare som leder arbetet. Slutligen på systemtestnivån är det vanligast att man har ett eller flera testteam med ett antal testare och en testledare per team. Testledarna fungerar som ”mini-projektledare” med ansvar för att planera och styra testningen medan testarna ansvarar för att förbereda och exekvera själva testerna.

Agila upplägg har en annan grundorganisation och därmed förändras spelreglerna även för testningen. Låt oss ta scrum som exempel. Här utgör scrum-teamet kärnan i utvecklingsarbetet. Scrum-teamet är ett självorganiserade team, som idealt ska vara sammansatt av personer från flera olika discipliner, däribland test.  Teamet har ingen formell ledare utan beslut tas gemensamt i teamet och alla teammedlemmar är gemensamt ansvariga för att teamets uppgifter blir utförda. Förutom team-medlemmarna finns även en scrum-master i teamet. Dennes främsta uppgift är att skydda teamet från yttre störningar. Scrum-mastern deltar oftast inte aktivt i teamets arbete utan sysslar enbart med att lösa problem som hindrar eller bromsar teamets progress.

Vidare så genomförs jobbet i så kallade sprintar med en i förväg bestämd längd (oftast två-fyra veckor).  Vanligen startar en sprint med ett krav- och designarbete. Därefter genomförs utveckling och testning inom ramarna för sprinten.

Var scrumteamets ansvar slutar kan variera lite beroende på organisation och upplägg, men det är oftast så att ansvaret inte sträcker sig hela vägen fram till slutrelease. Det behövs m.a.o. ytterligare testning som tar vid där scrum-teamets ansvar slutar. Vanligast är att denna testorganisation fokuserar på icke-funktionella systemtester, men även andra testtyper som systemregression och acceptanstest kan falla på denna testorganisations lott. Låt oss kalla detta för ”Agil systemtest”

Vad blir då konsekvenserna för testare och testledare när organisationen rör sig från traditionell utveckling till scrum?

Den första stora skillnaden man lägger märke till är att det nu finns en testare tillgänglig för teamet redan när det är dags för komponenttest. Låt oss kalla denna roll för scrumtestare.

Det är visserligen så att scrumtestaren knappast har tid att ensam testa allt som teamets utvecklare producerar och det är ju heller inte tanken, men det är sannolikt att scrumtestaren kommer att delta i det kodnära testarbetet på ett sätt som testaren i traditionella testupplägg inte gör.

Nästa viktiga skillnad för scrumtestaren är att där det tidigare funnits en testledare som skött mycket av planering och styrning, så finns det nu ingen sådan roll utan dessa frågor kommer också att tillfalla scrumtestaren.

Slutsatsen för scrumtestaren är alltså att det ställs väsentligt högre krav på kompetens hos de personer som ska ha denna roll jämfört med den traditionella testrollen. Dessa personer behöver, utöver all traditionell testkunskap, både ha insikt i förutsättningar och genomförande av (kodnära) komponenttest samt kunskaper om och vissa färdigheter i testledning.

För testledaren, som i det traditionella upplägget hade ansvar för att planera och leda hela systemtestningen, och ibland även integrationstestningen, har nu testomfattningen troligen reducerats till det som är kvar när scrumteamet är klart (agil systemtest). Detta kan vid första anblicken verka som en förenkling, men faktum är att testledarens roll nu blir svårare. Den viktigaste orsaken till detta är att kärnan i agil utveckling är lättrörlighet, vilket bland annat manifesteras i att beslut om vad som ska göras i kommande sprint tas av scrum-teamet vid sprintplaneringen under första sprintdagen. Detta gör att framförhållningen för testledaren vid agil systemtest sällan är längre än sprintens längd. Ytterligare en försvårande omständighet är att testledaren inte är med i scrum-teamet och därför inte deltar under sprintplaneringen vilket gör att denne inte med säkerhet nås av information om vad teamet kommit överens om. Detta minskar förstås framförhållningen för agil systemtest ytterligare.

Slutsatsen för testledaren är att tiden för planering och förberedelser minskat drastiskt samt att behovet av information från scrum-teamen är av yttersta vikt. Testledaren måste därför sannolikt rikta sig utåt, från sin egen systemtestorganisation, mot scrumteamen i sin jakt på den senaste informationen snarare än att verka inåt mot systemtestarna. Planeringen behöver även göras mycket mer lättviktig och absolut inte göras i detalj för aktiviteter som gissningsvis ligger längre bort än en sprint. Dessutom kommer testledaren att behöva jobba med planering hela tiden.

För de testare som går från traditionell systemtest till agil systemtest blir skillnaderna minst påtagliga. Eventuellt försvinner några av testtyperna (tex. funktionstest på systemnivå) men det som är kvar genomförs ungefär på samma sätt som tidigare, även om man jobbar med kortare tidshorisonter. Möjligen kan man se en högre specialisering mot test av de (icke-funktionella) egenskaper som blir kvar i den agila systemtesten.

Slutsatsen för den agila systemtestaren är alltså att denna roll inte skiljer sig så mycket från traditionell systemtest.

Sammanfattningsvis kan vi konstatera att det traditionella upplägget med två testroller (testare och testledare) i och med ett scrum-upplägg förändras till tre testroller (sprinttestare, agil systemtestare och testledare). Där höga krav ställs på sprinttestarens kompetens, testledaren får jobba med planering mycket oftare och den agila systemtestaren eventuellt kan bli mer specialiserad mot egenskapstester.

Denna utgångspunkt leder till en rad intressanta frågeställningar till exempel:

• Hur blir man en bra sprinttestare, ska man börja som utvecklare, testare eller testledare? 
• Hur gör man för att koordinera testningen i sin helhet? 
• Hur maximerar man framförhållningen för systemtest?

Kom gärna med synpunkter och ideer!