I början av november gick årets Agile Testing Days av stapeln i Potsdam. Ulrika Malmgren berättar mer och ger sina reflektioner kring de kunskapsfyllda dagarna i Tyskland.
För andra året i rad besökte jag i slutet av oktober konferensen Agile Testing Days i Potsdam utanför Berlin. Agile Testing Days startades 2010 och samlar varje år ett par hundra deltagare från runt om Europa som vill lära sig mer om testning.
Känslan nu strax efter konferensen är att mitt huvud har fullkomligt exploderat. Alla nya tankar, omvälvande nya sätt att se på saker och insikter om mina egna tillkortakommanden som bombarderat min hjärna i fyra dagar tar ut sin rätt. Vid matbordet försöker jag lappa ihop den med hjälp av mina anteckningar.
Det är svårt att summera en konferens som denna på grunden av bredden av ämnen. Mest påtagligt var kvaliteten på keynote-föreläsningarna. Att ha möjlighet att höra vad upphovsmannen till den populära tekniken Behavior Driven Development, Dan North, har att säga om mjukvaruutveckling är fascinerande. Vi fick också möjligheten att lyssna på J.B. Rainsberger, författaren till JUnit Recipes, som gav en underhållande och träffande bild om var vi som bransch i allmänhet kommer till korta. Om vi är så bra på mjukvaruutveckling, varför är vi inte rika än? Men de tekniska ämnena varvas också med teamdynamik när t.ex Mary Gorman, författare till Discover to deliver, pratar lugnt och självsäkert om förtroende och hur det påverkar våra team.
Istället för att gå igenom varje föreläsning i detalj vill jag på samma sätt som förra året skriva om de två starkaste trenderna jag kunde urskilja. Självklart blir detta färgat av de trender som jag tittar efter, men jag gör ett försök ändå!
Det ämne inom testning som hade störst närvaro var riskanalysen. Det tycks vara så att testare runt om i Europa har dammat av den gamla grafen med påverkan/impact på y-axeln och sannolikhet/likelihood på x-axeln och börjat använda den igen. Jag räknade till 6 sessioner under den fyra dagar långa konferensen som hade risk med i titeln. En som tog upp detta var Dan North, både under en endagskurs men även under sin keynote. Dan påpekade även att det finns en z-axel som motsvarar kontext och stakeholders. I den dimensionen skapas en känsla för för vem risken är viktig.
Så varför är risk så intressant? I vår värld med snabb releasetakt vill vi förstås lägga vår tid där det spelar mest roll. Om vi tittar på ett mätvärde såsom testtäckning går det fort att se att hög testtäckning för ett område som har låg risk är en miss i planeringen. Istället borde den tiden läggas på att säkerställa att området med hög risk är riktigt, ordentligt och helhjärtat testat. Kanske är det så att detta område med hög risk kan delas upp i flera områden så att risken sänks.
Det är också möjligt att ställa sig frågan om det område som har så låg risk (i alla dimensioner) verkligen är intressant för produkten? Om det varken är sannolikt att något blir fel eller om det händer så har det liten påverkan för användaren och dessutom bryr sig inte stakeholders märkbart, är det en komponent som vi verkligen behöver ha kvar?
Att tala om risk går alltså hand i hand med att tala om det som är värdefullt för systemet.
När ska vi då ta diskussionen om risk? Flera exempel dök upp under konferensen. Att spela risk poker på samma sätt som planing poker var ett förslag. Under en workshop presenterades ett mer avancerat ramverk för riskanalys. Personligen har jag god erfarenhet av att grovkornigt bygga upp en matris med områden och sedan ge dem en färg (grön, gul eller röd) beroende på vilken risk vi kunde se att sprintens user stories skulle innebära. Detta användes som underlag för hur mycket testning som behövdes för varje område.
Självklart är detta en diskussion som bör hållas med hela teamet och med produktägaren. Jag ser samtalet om riskerna som ytterligare ett sätt att öka förståelsen för syftet med en user story. Det är också en bra grund för att skapa fokusområden för testning.
Ett annat ämne som tog mycket plats var kommunikation. Dels i hur vi presenterar information (David Evans höll en utmärkt keynote om hur det är möjligt att öka kunskapen om ett ämne genom att använda grafik) men även i hur vi kommunicerar i teamet. Som testare har vi en viktig uppgift, att presentera informationen som vi utvunnit under testningen för dem som behöver den. Resultatet av vårt arbete är trygghet och det är därför intressant att lära sig hur denna information kan förmedlas på ett effektivt sätt.
Nu mår min trötta hjärna lite bättre igen, jag har lyckats koppla ihop några tanketrådar med varandra. För att summera kan jag rekommendera att åka på Agile Testing Days. Det är en konferens med en bra blandning av stora talare, bra tutorials och en vänlig känsla där det är lätt att lära känna nya människor. Potsdam är dessutom en vacker stad med element från sagovärlden. Jag vill också varmt rekommendera att lyssna på J.B. Rainsberger och Dan North för den som får möjligheten. Det är en upplevelse som får en att omvärdera sin bild av mjukvaruutveckling. Och som tvingar en att behöva lappa ihop sin hjärna vid matbordet en söndag morgon.
