Agil test på Agical

Agil test har en lockelse sv år att motstå, grundad i en viss mystik och allmän förundran, kanske förvirring. Så när jag fick en inbjudan av en arbetskamrat att följa med till Agical för ett kvällssemiarie om Agil test var det inte svårt att bestämma mig för att tacka ja, trots att kvällen var en måndag. Och förväntingarna var höga. Äntligen skulle jag få höra någon prata om agil test så att jag äntligen kunde förstå varför det är sådant ’buzz’ kring det!

Jag var den enda testaren i rummet, förutom seminariehållaren. Resterande publik en skara som till större delen utgjordes av utvecklare i en eller annan form, jag vet det eftersom en snabb handuppräckning avslöjande fördelningen. Det visade sig också att seminariet främst riktade sig till den stora publiken, vilket man ju inte kan klaga på men också innebär att för mig var innehållet något klent.

Själva seminariet visade sig ha vissa poänger men skyndade i min mening lite väl snabbt förbi själva huvudämnet för att diskutera test i allmänhet och automation som hastigast.

– Jaha, så det innebär att det pratades om agil test utan att fokusera på automation?

– Precis!

De två är inte nödvändigtvis likställda, det ena kräver inte det andra. Istället handlade det om att involvera testaren under hela utvecklingsfasen, till exempel genom att sitta bredvid en utvecklare och bidra med kritiskt tänkade och testfallsgenerering i stunden. Det kräver dock viss flexibilitet i budget.

Det pratades också om att testa tidigt, att testa små delleveranser.

Är bara ett inputfält klart så kan jag testa det

En idé som inte är ny men är svår att få att fungera praktiskt. Ett krav för att kunna arbeta så är dock att planeringen av kommande arbete tänker i testbarhet. Hur ska vi planera uppgifter för att tillåta test så tidigt som möjligt? En tanke som diskuterats i vissa projekt jag varit delaktig i men som jag inte fått att flyga. Främst för att de tidiga testerna inte gett tillräcklig utdelning utifrån den extra insats som krävts. Men det är helt klart något värt att fundera vidare kring, det kan vara nyttigt för ett team att planera på det sättet. Dessvärre missade jag chansen att fråga efter konkreta exempel.

Jag gillade också verkligen att idén togs upp att aktivt medverka under sprintplaneringar och inledande utveckling genom att bistå med testfallsplanering och en frågande attityd. I många fall är det förmodligen det som saknas.

Över huvudtaget tror jag att testarbetets ”runtomkring-funktioner” underskattas. Mycket av det arbete en testare utför behöver inte nödvändigtvis vara av testfallsexekveringsart. I ett team tillförs mycket genom att någon ställer de obekväma frågorna, granskar funktioner med ytterligare en vinkel, ställer krav som mer syftar till ett, i stunden, internt intresse; vi måste ha en testmiljö, vi måste ha ordning på vår versionshantering, vi måste tänka på att bygga testbart.. osv.

Sen hade seminariet vissa svaga punkter. Det märktes att automation mest presenterades för att publiken ville höra det, ingen egentlig erfarenhet eller poänger låg bakom. Och det var också den delen som väckte mest frågor, föga förvånande.

Det dök också upp en fråga kring skalbarhet i test. Jag hade lite svårt att förstå vad frågan egentligen var men kommer förmodligen få komma tillbaka till det senare eftersom jag var tvungen att haspla ur mig ett något aggressivt svar: dubbelt så mycket kod betyder inte så många testfall!