Den agila testexplosionen

Det svåraste i agil testning är det ständigt växande testbehovet. Testbehovet ökar med varje utvecklingscykel då ny funktionalitet läggs till i systemet. För att göra saker värre så behöver ofta nya funktioner testas tillsammans gammal funktionalitet, vilket leder till en exponentiellt ökande testmängd. Det här problemet kan relateras till det väldefinierade begreppet ”entrophy death” inom programmering och några potentiella lösningar är gemensamma. Den agila testexplosionen behöver hanteras från första början i varje agilt projekt. Annars kommer den kombinatoriska explosionen göra att testbördan så småningom slår i taket. Utan förberedelser är det nästan omöjligt att bryta en negativ trend.

Föreställ er ett Scrumteam med konstant ”velocity” (så är oftast inte fallet eftersom ett Scrumteam alltid strävar efter att öka ”velocity” genom att minska ”waste”, men för testarens arbetsbelastning är detta ett idealiskt exempel). För varje sprint måste alla funktioner, nya såväl som gamla, testas. I värsta fall måste alla funktioner testas i kombination med varandra. I detta värsta fall ökar testbördan med fakultetsprodukten av alla implementerade funktioner. Vid den femte sprinten har testbördan ökat 125 gånger. Vid testning av den sjätte sprinten är ökningen 720 gånger. Trots att detta är ett extremt exempel så visar det på problemets omfattning. I vart fall ökar testbördan i det närmaste exponentiellt. Den agila testexplosionen kan därför inte lösas med fler resurser eller testautomatisering. För att hålla kontrollen behövs en strategi med fler angreppssätt samtidigt. Angreppssätten spänner över flera olika områden, såsom systemarkitektur, systemets testbarhet, test- och utvecklingsmetoder.

Modulär design

Den viktigaste aspekten för att förhindra en agil testexplosion är att ha en genomtänkt systemarkitektur. Sträva efter en modulär design med lösa kopplingar så att varje funktion kan utvecklas och testas var för sig. I det optimala fallet resulterar det i ett litet antal funktionella kombinationer att testa och en nästan linjär ökning av testbördan.

Testbarhet

Testbarhet är ett mått på den arbetsinsatts som behövs för att testa systemlösningen. Med dålig testbarhet kommer testarna att lida mer av den kombinatoriska explosionen och nå taket tidigare. För bättre testbarhet kan man ställa följande frågor:

• Hur lätt är det att kontrollera och observera systemet under test?
• Är det möjligt att testa isolerade funktioner för att undvika beroenden?
• Är det enkel att använda och förstå systemet?
• Can vanliga procedurer automatiseras för mer effektiv testning?

Test automatisering

Ett vanligt missförstånd är att den agila testexplosionen kan lösas med enbart testautomatisering. Anledning till att det inte går är ganska uppenbar. Eftersom testbördan ökar exponentiellt kommer implementation av nya testfall snart att vara ohanterbart. Det finns alltid en kostnad för utveckling och förvaltning av automatiserade tester och så småningom kommer teamet att använda alla resurser bara för automatisering. Testautomatisering spelar dock en viktig roll i den övergripande strategin för att hantera den agila testexplosionen. Implementerade regressionstester kommer att frigöra värdefulla testresurser som i sin tur kan förbättra manuell testning av komplexa funktioner. Testerna kan också göras mer effektiva med semi-automatisering av krävande testuppgifter. Det kan röra sig om uppsättning och nedtagning av tester, skapa testdata o.s.v.

Kontrollera förändringar

Genom att hålla kontroll på förändringar i kodbasen kan man fokusera testerna där de behövs. Det finns flera verktyg som kan spåra förändringar på detaljerad nivå. Diskutera med utvecklarna hur ändringar påverkar implementerad funktionalitet och föreslår goda lösningar.

Testa smartare

Slösa inte bort dyrbar testtid på onödigt stelbenta testprocedurer eller dokumentation. Ett Scrumteam strävar alltid mot att minimera ”waste” och öka ”velocity”. Testare i ett Scrumteam bör göra detsamma. Är det möjligt att välja bort en del regressionstester eller köra olika regressionstester vid olika tillfällen? Är det möjligt att testa flera funktioner samtidigt? Använder testteamet alla resurser effektivt eller saknas det någonting? Finns det nya verktyg eller idéer därute som kan vara tillämpbara? Vad kan resten av Scrumteamet göra för att stödja testarna på ett bättre sätt?

Agil testledare

En vanlig missuppfattning är att samtliga i ett agilt team ska jobba med utveckling och göra ungefär samma saker. Det är förstås inte sant. Samtliga medlemmar har ett gemensamt ansvar för för utveckling och kvalité men man kan bidra till det övergripande målet utifrån olika roller. Ifall du har någon i teamet som ansvarar för testplanering, testrapportering, testmiljöer /-verktyg /-data (formellt eller informellt), så är det förmodligen en testledare. Testledaren hör hemma i det agila teamet. Det behövs någon som har övergripande kontroll över vilka tester som görs, systemets kvalité och vidareutvecklar testarbetet.

En testledare är oftast väl insatt i mjukvarutestning och kvalitetsarbetet. Förutom detta behöver en testledare i ett agilt team också känna till agila och lättviktiga utvecklingsmetoder samt hur man anpassar testprocessen till en agil utvecklingsmodell. Det är viktigt att kunna hörnstenarna i agil testning, såsom utforskande testning, kontextdrivna tekniker och testautomatisering. En annan viktig uppgift är att verka för kvalitetstänkande hos utvecklarna genom att att införa bra arbetssätt, såsom testdriven utveckling och continuous integration. Det finns oftast inte tillräckligt med testledaruppgifter för att hålla en testledare igång på heltid. Därför jobbar ofta testledaren även som testare. Praktiskt testarbete är nödvändigt för att få insikt om systemet kvalité, testmiljö, /-data, /-verktyg samt testarnas förmåga.

Testledarens arbete kan delas upp i tre huvudkategorier: planering, kontroll och rapportering. Övergripande planering görs för hela projektet. Planen uppdateras och utökas per utvecklingsiteration. Planen ska hållas enkel och fokusera på  teststrategi, testområden, testmiljöer, /-data, /-verktyg, tid och resurser. Kontrollaktiviteter ska också hållas enkla och kan utföras effektivt med få mätetal t.ex.: testtäckning, fel i olika delar av systemet och testarnas arbetsbelastning. Skrivna rapporter är oftast inte nödvändiga eftersom testledaren deltar på sprintdemo, "go/no go" och liknande.

Rena testledaraktiviteter utförs ofta utanför ordinarie arbete i utvecklingscykeln. En testledare måste ofta planera flera cykler framåt och utifrån hela projektet. Vissa testaktiviteter, t.ex. prestandatest och systemintegrationstest, kan ej kopplas till funktioner i en speciell utvecklingscykel. Det är då upp till testledaren att planera när det sådana uppgifter ska genomföras.

Typiska uppgifter för testledare är planering, kontroll och rapportering. Detta sker oberoende av testcykeln då testledaren ofta måste planera för flera utvecklingsiterationer framåt.