Hur Scrum har utvecklat testrollen

2010-04-19 Artikelbanken Test Läst 16227 gånger

Med hjälp av Scrum har de agila metoderna under det gångna decenniet stärkt sin ställning hos utvecklingsorganisationer runt om i Sverige. Metoderna har gått från att ha varit smått kontroversiella till mer eller mindre standard. Men vilka skillnader har dessa metoder, i synnerhet Scrum, inneburit för testarens roll i utvecklingsorganisationen? I denna artikel kommer jag att belysa några av de mest framträdande förändringarna.

Test kryper närmare utveckling

Scrum förordar att teamen i största möjliga mån ska vara självförsörjande. Det innebär att all den kompetens som krävs för att färdigställa en uppgift ska finnas i teamet. För att en uppgift/funktion ska anses vara färdig måste den även vara testad, vilket oftast resulterar i att testare ingår i teamet. Detta är antagligen den faktor i metoden Scrum som har haft störst inverkan på testrollen. Jämfört med traditionella utvecklingsmetoder har test fått mandat att fysiskt såväl som arbetsmässigt flytta in i utvecklingsteamen.

Det har ofta funnits en organisatorisk gräns mellan utveckling och test med skilda avdelningar, vilket det fortfarande är hos många företag som anammat Scrum. Men genom att test och utvecklingsarbetet planeras och utförs i nära relation så börjar de organisatoriska gränserna sakta suddas ut. Testare har fått möjlighet att tidigare komma in i utvecklingsprocessen, ofta samtidigt som utvecklare. Från utveckling sett, har den traditionella testverksamheten varit en yttre instans som planerar, kontinuerligt genomför och rapporterar testresultat. Nu återfinns flertalet av testarna spridda i utvecklingsteamen, där respektive team gemensamt tar ansvar för en mjukvara som är utvecklad, testad och klar för leverans.

Vissa testinstanser kan givetvis fortsatt vara nödvändiga att hålla separerade från utvecklingen. Dels för att behålla en oberoende ställning, men även för att aktiviteterna ligger senare i kedjan så arbetet inte går att planera tillsammans.

Testarbetet påbörjas tidigare

Scrum involverar automatiskt test i utvecklingsprocessen så tidigt som möjligt, vilket är positivt och något de flesta organisationer vill uppnå. Test kan tidigt hjälpa till att granska verksamhetens krav och utifrån sina förutsättningar få möjlighet att påverka dess utformning. Bland annat öppnar det för att tidigt diskutera testbarhet innan koden börjat skrivas, vilket annars vanligen hamnar i skymundan. Det har givetvis funnits alla möjligheter till detta tidigare också, men test glöms tyvärr ofta bort under kravställnings- och designstadiet.

Ju tidigare felaktigheter upptäcks desto billigare blir de att rätta jämfört med om de hittas senare i utvecklingsprojektet. Med felaktigheter avses buggar, designfel eller liknande som skiljer sig från vad som förväntas. Sena rättningar av dessa fel kan resultera i merarbete såsom extra dokumentation, regressionstester och potentiellt kostsamma omleveranser till kund. Därmed finns det all anledning att introducera test direkt från startblocket för att försöka upptäcka dessa fel tidigare. Det finns många exempel när krav diskuterats på ett väldigt tidigt stadium och en testare ställt en fråga som fått beställaren eller utvecklaren att tänka till ytterligare en gång. Felet har således upptäckts redan i designstadiet och varit väldigt billigt att rätta jämfört med om det hittats först senare.

Arbetet bedrivs i iterationer

Då test och utveckling planerar arbetet gemensamt, i kombination med det förbättrade samarbetet som kommer naturligt med att arbeta tillsammans i ett team, möjliggör det för tätare leveranser från utveckling till test. Eftersom leveranserna kan ske informellt inom teamet behöver de inte omfattas av samma detaljerade dokumentation som normalt krävs. Förutsatt att det finns smidiga bygg- och installationsverktyg kan leveranser från utveckling till test ske oftare med väldigt små iterationer inne i sprinten (se bild).

Kontinuerliga leveransiterationer är värt att eftersträva av flera orsaker. Dels får test ta sig an en mjukvara där skillnaden från tidigare leverans är mindre och inte lika ”spretigt”. Utvecklare får tidigare feedback från test under pågående utveckling och möjlighet att omgående rätta buggar när de jobbar aktivt med koden. Nackdelen är dock risken att utvecklare inte tar samma förväntade ansvar för kvaliteten innan de levererar eftersom leveransen är inofficiell. Det är viktigt att man tillsammans kommer överens om en balans där mjukvaran är lagom utvecklartestad.

Med de upprepande sprintiterationerna får även produktägaren en naturlig feedback hur arbetet fortskrider. Genom att lägga till/ta bort/prioritera aktiviteter från product backlog kan produktägaren fortlöpande styra hur produkten växer fram.

I det nära samarbetet mellan utveckling och test skapas dessutom möjligheter för ett kontinuerligt lärande inom teamet. Test får en djupare teknisk kunskap om det som utvecklas och kan därmed vara effektivare, både avseende urval av tester och i analysen av de buggar som upptäcks. Samtidigt får utvecklarna en ökad förståelse hur test arbetar och kan enklare ta del av testmiljöer, testdata eller liknande som test förfogar över.

Testarens roll i teamet utvecklas

Den renaste formen av Scrum förordar att vem som helst i teamet ska kunna axla vilken roll som helst. I realiteten är det väldigt sällsynt i medelstora till stora organisationer eftersom man oftast är anställd som antingen utvecklare eller testare. Därför har teamen för det mesta även dedikerade testare. Det positiva med dedikerade testare är att det ger frihet att kunna ifrågasätta i en större utsträckning eftersom det är vad som förväntas, vilket inte var lika självklart för ett par år sedan när test inte var lika förankrat i utvecklingsprocessen.

Organisationer har traditionellt sett förväntat sig att test objektivt granskar de leveranser som tas emot och rapporterar hur kvaliteten faktiskt är. Även om det på sina håll riskerar att skapa motsträviga ”kvalitetspoliser” har det varit ett genuint oberoende. Testorganisationen har via olika ärendehanteringssystem kunnat rapportera in felaktigheter utan att behöva ta hänsyn till vem ärendet sedan hamnar hos. Med Scrum blir testaren en del av teamet och får i nära relation med utvecklare ge återkoppling på det som levereras. Detta är en av de nya stora utmaningar för testrollen som Scrum introducerat. Risken finns att testaren blir för mycket kompis med de övriga och inte fullt ut påtalar de eventuella brister som föreligger. Å andra sidan är det givetvis enklare att ansikte mot ansikte påvisa felaktigheter till någon man känner väl, än till en okänd person. Det är viktigt att testaren behåller en granskande inställning till det som Scrumteamet levererar, samtidigt som individen är en del av teamet såväl arbetsmässigt som socialt. I denna situation är det oerhört viktigt att kunna leverera feedback på ett konstruktivt sätt.

Testledarens uppgifter förändras

Testledarrollen har förändrats och är av mer koordinerande karaktär, snarare än ledande, där det är viktigt att strategiskt ”hålla ihop” testningen över de olika teamen. Uppgifter som planering, rapportering och dokumentation kan delvis göras av testarna i teamen och sammanställas av testledaren. Det är även viktigt att samordna hur olika typer av testaktiviteter ska hanteras för att inte få för stora skillnader mellan team. Testledaren är som tidigare navet i testaktiviteterna för projektet och samlar ihop testresultat på teamnivå och sammanställer det. I större projekt med parallella Scrumteam är det lätt hänt att teamen är fokuserade på den del i systemet som de själva bygger. Testledaren har en viktig uppgift att se systemets helhet, då integrationen av systemet ofta tenderar till att vara besvärlig.

Effektivisera genom automatisering

Med de agila metoderna skapas förutsättningar för att korta ner den tid det tar att utveckla en idé till färdig mjukvara. I Scrum förväntas det som produceras i en sprint (1-4 veckors utvecklingsperiod) hålla en kvalité som är tillräckligt bra för att leverera till en kund, produktion eller slutanvändare. Det ställer krav på att de genomförda testerna i sprinten dels omfattar nyutvecklade delar, men även befintlig mjukvara som kan vara påverkad. Beroende på den befintliga kodmassans storlek kan det kräva en hög grad av automatiserade regressionstester för att spara tid och möjliggöra att alla tester hinner genomföras. De manuella testerna bör dessutom fokuseras på nyutvecklade delar där de gör mest nytta och sannolikheten är störst för att upptäcka fel. Det finns stora resurser att spara om testaren i teamet har kompetensen, eventuellt med assistans av utvecklarna, att bygga upp automatiserade testsviter som kontinuerligt kan exekveras.

Värdeskapande aktiviteter sätts i centrum

Enligt Lean och de agila metoderna ska det kontinuerligt eftersträvas att eliminera slöseriet i organisationen. Det innebär att det arbete som inte tillför tillräckligt med värde inte heller ska utföras. Ur en testares perspektiv är den aspekten intressant då testare traditionellt hellre ser att projektet levererar liten mängd funktionalitet med lite buggar än motsatsen. Vid planeringen av arbetet så ställs buggarna på sin spets mot övriga uppgifter som teamet ska utföra. Testaren kan få tolerera att många buggar inte rättas för att aktiviteten helt enkelt inte skapar tillräckligt värde för verksamheten. Å andra sidan, små buggrättningar med väldigt litet värde kan vara mindre kostsamma för organisationen om utvecklaren helt enkelt utför dem på eget initiativ. Om buggarna istället ska dokumenteras, diskuteras och sedan prioriteras kan tidsåtgången växa till flera timmar innan arbetet ens har påbörjats. Detta förutsätter givetvis att projektet är i ett skede där fri buggrättning råder.

Scrum i framtiden?

Scrum är givetvis att betrakta som ett verktyg precis som andra metoder och passar definitivt inte i alla situationer. Det hanterar en mängd problem som uppstår i mjukvaruutveckling. Dock är det många problem som metoden inte har någon lösning på, samtidigt som den även introducerar nya. Man förväntas till exempel ha vetskap om vilka arbetsuppgifter som behöver utföras den närmsta tiden samt ha förmågan att estimera dess tidsåtgång relativt väl. Den informationen är inte alltid tillgänglig, till exempel vid förvaltningsarbete som i hög grad är incidentdrivet, och tillförlitligheten till planeringen blir väldigt låg. I dessa situationer finns mer passande agila metoder att använda som t.ex. Kanban.

Produktivitet och kvalitet inom mjukvaruutveckling är känt för att vara svårt att mäta. De agila metodernas breda inträde och påverkan är likaså svårt att mäta och utvärdera objektivt. Oavsett resultat finns det ingen uppenbar väg tillbaka till de traditionella metoderna. Vattenfallsmetoden har på många håll kastats ut, eftersom den inte passar i många utvecklingssammanhang. De agila metoderna tar bättre hänsyn till otillräckliga krav och en föränderlig omvärld.

Med Scrum i spetsen har de agila metoderna förändrat hur test förhåller sig till utveckling. Test kommer in tidigare i processen med den fundamentala skillnaden att tillsammans med utvecklare leverera ett resultat. Det blir extra viktigt att kunna kommunicera framgångsrikt och bygga en bra relation för att vara effektivare i testarbetet. Testaren behöver i större utsträckning ifrågasätta vilka tester som tillför mest värde och vad som kan vara aktuellt att automatisera. De nya arbetssätt som de agila metoderna introducerat kommer med all sannolikhet även att finnas kvar i början av nästa decennium. Säkerligen kommer Scrum inte att finnas kvar utan ha ersatts av någon ytterligare optimerad metod. Namnet är dock av mindre intresse så länge de lättrörliga formerna finns där. Förhoppningsvis kommer det då vara så självklart att arbeta agilt att det inte längre behöver vara uttalat.

Nästa steg

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln