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?