Hej Agila Sverige!

I tisdags deltog jag i och drev ett s.k. Open-X under Agila Sveriges andra dag. Det hade fått namnet “Det är tufft att skriva test!” av mig. Jag föreslog det av två anledningar. Dels för att jag ville prata om varför jag tycker om att programmera för test och automatisering, något som ofta möts med förvåning och skepsis. Dels för att jag ville diskutera möjligheten att locka fler programmerare att ägna tid åt test och automatisering. Jag lovade återkomma med anteckningar, sammanfattning och foto. Allora.

Så, först mina ursprungliga punkter. Dvs varför tycker jag om att ägna mig åt test och testautomatisering:

Oberoende – När jag programmerar test eller automatiserar brukar jag generellt kunna välja mycket friare än annars (produktionsriktad programmering) bland programmeringsspråk, bibliotek och verktyg.

Möjliggörande – Jag ser test och automatisering som möjliggörare för vad jag (och andra?) egentligen vill pyssla med. Dvs skapa nya produkter, få prova nya idéer och framförallt, slippa lägga tid på sådant som är tråkigt.

Det är mitt jobb – Jag ser det som en del av mitt ansvar som programmerare att använda min kunskap om systemen jag utvecklar samt mina kunskaper i programmering för att påverka inte bara features utan hela min och mina kollegors arbetsvardag. Framför allt vill jag inte ge någon annan i mitt team en sämre eller tråkigare uppgift som resultat av att jag inte gjort mitt bästa för att förenkla den.

Svårt – Att skriva test är ofta svårt, av flera olika anledningar. Därför är det också intressant och något att vara stolt över.

  • Att skriva automatiska test är programvaruutveckling och precis som annars får man brottas med tydlighet, komplexitet, beroenden och buggar.
  • Att programmera tex asynkrona eller parallella system är svårt, att testa dem kan vara ännu knivigare, framförallt att veta att man verkligen fångat essensen i ett race condition och återskapat det så att det uppträder varje gång i ett testfall.
  • Ofta får man använda mycket fantasi och kunnande för att kunna återskapa verklighetsliknande situationer för programvaran genom att försätta den i farliga situationer eller genom att simulera dem. Alternativt kanske man får fundera ut om man verkligen behöver göra det.

Lärorikt – När jag skriver test, oavsett vilken sort, lär jag mig saker om programvaran jag testar. När jag enhetstestar lär jag mig saker om koden på minsta nivå; vilka beroenden har den, vilka sidoeffekter, hur är den att använda. Ju närmare slutgiltig produktionsmiljö vi kommer desto mer lär vi oss om våra systems verkliga beteenden och förhållanden. Jag lär mig hela tiden saker som:

  • Varför startar applikationen så långsamt?
  • Varför vet jag inte när den verkligen är ‘uppe’?
  • Varför går den här tredjepartsprodukten inte att fejka?
  • Varför går den här tredjepartsprodukten inte att manipulera programmatiskt?
  • Hur funkar egentligen vårt publika API?
  • Varför går det inte att få konfiguration och deployment att funka pålitligt eller portabelt?

Dessutom lär mig jag mig antagligen, tack vare de tidigare punkterna, mer om programmering i det programmeringsspråk jag valt. Jag lär mig mer om de verktyg och tekniker jag valt och de som används i produkten. Jag får, tack vare fantasin och desperationen som ibland måste tas till, dra lärdomar om programspråk, API:er och tredjepartsprodukter; lärdomar som man ibland nästan önskar man slapp lära sig. Allt detta lärdomar som bidrar till att välja bättre eller åtminstone annorlunda nästa gång jag får samma val, oavsett om det gäller produktionskod eller test.

Så inleddes Open-X:et som jag själv blev väldigt nöjd med och där jag tyckte att flera intressanta diskussioner uppstod. Tack vare de andra deltagarna kunde vi fylla på min lista med många fler punkter. Här kommer de som jag kommer ihåg och lyckats återskapa från min bild av anteckningarna. Alltså, argument för att övertyga fler att ägna sig åt test och automatisering:

  • Det är roligt. Bland annat på grund av argument som jag anfört tidigare, men också för allt annat man kan ägna sig åt. Jag tyckte dessutom att gruppen som samlats hade väldigt roligt – ett tecken, om inte annat, på att folk som brinner för test faktiskt är skojiga människor 🙂
  • Feedback, speciellt om de är av typen “fail-fast”. Nåt jag glömde. Tester ger oss snabb feedback, på många nivåer. De låter oss ta bättre och snabbare beslut. Möjliggör lärande.
  • Delat ägarskap. Team:et äger hela leveransen av produkten till produktion, via test om det är så man jobbar, tillsammans. Så enkla saker som att se över arbetsplatsen (sitter testarna med de andra i team:et?) eller hur man delar upp tasks (fundera på att bryta ned testarbetet, inte bara skriva en lapp med ‘test’ på).
  • Tävlan. Framförallt som ett startskott kanske tävlan, mellan team eller teammedlemmar, om att skriva fler test eller parprogrammera med testare osv vara en variant.
  • Switch, boktips
  • DONE definition, checklistor. Jobbar man med definition of done eller checklistor är de givetvis ett bra medium för att förmedla att test och automatisering är nödvändigt.
  • Visualisering. Här är ett ämne som jag försökt få mitt huvud kring på sistone. Hur visualiserar man kvalitét? Exempel jag kan tänka mig är testtäckning, test-effort, test-tid. Hur,  på ett enkelt, dynamiskt, översiktligt och tilltalande sätt? För team, produktägare och chefer? Vi nämnde Specification By Example, även om jag inte sett det ge snabb och tilltalande överblick eller relation till buggtäthet eller vad som just ändras eller lagts till. Med bra visualisering borde man kunna väcka nyfikenhet och förbättringsvilja. Vi pratade också om att kombinera med visualisering av kodtäckning och komplexitet för att visa på var förändring är lätt, svår, nödvändig eller irrellevant.

Tack för er uppmärksamhet och speciellt tack till alla som deltog i diskussionen!

Advertisements