Automatiserade tester i det agila teamet

Tänkte helt kort dela med mig av några erfarenheter vi gjort när det gäller automatiserade tester i
våra agila utvecklingsmiljöer. Agil utveckling och automatiserade tester har visat sig vara en lyckad kombination. Jag vill påstå att det finns en ömsesidigt beroende mellan agil utveckling och väl fungerande automattester. Manuella tester behövs naturligtvis också, men är inte om dem just denna artikel handlar .

Vi har introducerat den tekniska testaren som en kompetens i utvecklingsteamen. Termen “teknisk testare” är ju rätt fluffig och kan, som vi alla märkt, betyda lite av varje beroende på vem vi frågar. För oss är det en hybridkompetens som behöver ”skills” från två olika håll: test och utveckling. Hen ska vara en hyggligt bra testare OCH en hyggligt bra utvecklare. Det sägs förresten att “teknisk testare” är ett fornnordiskt uttryck som betyder “medioker programmerare” .

Den tekniska testaren förhåller sig till testare och utvecklare på samma sätt som varulvar förhåller sig till vargar och människor: en unik varelse som ärvt egenskaper från två andra unika varelser.

Den tekniska testaren innebär inte en ny roll i teamet – utan om en att tillföra teamet kompetens om automatiserade tester. Detta är inte (endast) semantiskt hårklyveri – utan en viktig distinktion.

Varför?

Jo, vi har noterat att automatiserade tester fungerar bäst när de bedrivs som lagsport och involverar flera discipliner. Den tekniska testaren kan inte (och ska inte) dra hela autotest-lasset själv. Det är bevisligen en framgångsfaktor att teamet tillsammans har ansvar för att de automatiserade testerna utvecklas, underhålls och används .

När våra team ställs inför krav för ny eller förändrad funktionalitet genomförs en testanalys, där en viktig leverabel är beslut om kraven ska verifieras manuellt eller med automatiserade tester. Om beslutet är manuell test, förbereds skriptade eller utforskande manuella testaktiviteter.

Om vi beslutar oss för automatisering gör den tekniska testaren – på samma sätt som vid teamets övriga utvecklingsaktiviteter – en övergripande design. Denna design bryts ned till ett antal backlog-items som teamet tidsestimerar, exempelvis med hjälp av planeringspoker. Dessa tidsestimerade backlog-items hamnar slutligen som lappar på scrumtavlan, varpå en teknisk testare och/eller en utvecklare kan implementera autotesten.

Det är centralt att odla en kultur av gemensamt ansvar för:

• Utveckling av testerna
• Underhåll av testerna
• Uppföljning av testexekveringen

Det är teamets ansvar att de automatiserade testerna går ”gröna”. Tester som går ”röda” måste analyseras snabbt, eftersom ”failande” tester utan åtgärd leder till frustration snarare än att vara till hjälp.

Ju bättre vi fått det gemensamma ansvartagandet att fungera – desto bättre har de automatiserade testerna uppfyllt sitt primära syfte: snabb och korrekt återkoppling till teamet och projektet.