Sprintfokus på burk

På fjället eller i skärgården åker ofta burkmaten fram. Burkmat är praktiskt såtillvida att den ger snabb bukfylla och kräver minimal ansträngning. Nackdelen är att man tröttnar ganska snabbt och börjar längta efter mer vällagad föda. Lite på samma sätt är det med detta blogginlägg om sprintfokus på burk. Här samlar jag ett par enkla tips som är ganska lätta att komma igång med och brukar ge bra resultat. Det är vad jag brukar börja med i utvecklingsteam som jag har arbetat med. Min sprintfokus på burk räcker på bara en bit på vägen och rätt snart är det dags att börja med mer anpassade och genomarbetade åtgärder, men då har teamet säkert hunnit igång med retrospektiv och egna förbättringsförslag.

Fokustavla och fokusmöte
Jag brukar alltid starta med att bygga en fokustavla och det finns bra skäl för detta. Att använda en fokustavla är enkelt att införa och ger ofta bra resultat. Tavlan används för visualisering, kommunikation och självorganisering. Även utan andra förändringar så gör fokustavlan att gruppen för en enad bild över leverans och kvalité. Fokustavlan kompletteras gärna med ett dagligt fokusmöte för att ytterligare hålla ihop gruppen.

Grundarbete inför sprint
Grundarbetet, som görs innan utvecklingsarbetet tar vid, utgör hela skillnaden mellan en lyckad sprintstart och en mindre bra inledning. En prioriterad produktbehovslista med ett tiotal sprintredo krav är det bästa sättet att starta en sprint på och här kan en kravanalytiker, i sammarbete med produktägare och utvecklingsteam, genomföra storverk. Kravjobbet är ett fotarbete och ett iterativt hamsterhjul av möten med beställare, produktägare, utvecklare, arkitekter, testare o.s.v. En engagerad kravanalytiker som faciliterar produktbehovsprioriteringssessioner och detaljerar kraven är en verklig tillgång för utvecklingsteamet.

Sprintplanering
Återigen är det grundarbetet som gör hela skillnaden. Se till att (hela/delar av) teamet har fått tagit del av kraven i förväg så att de har haft möjlighet att tänka till. Produktägare och kravanalytiker ska vara pålästa så att de kan svara på frågor. Krav ska vara så pass väldefinierade att ev. frågeställningar bara rör detaljer. Låt hela teamet komma till tals, låt hela teamet bestämma sprintens omfattning. En väl genomförd sprintplanering ger en positiv känsla inför och en bra start på sprinten!

Färdigkriterier
Teamet kommer överens om vad som gäller för att en aktivitet ska vara färdig (incheckad, automattestad, färdigtestad, dokumenterad o.s.v.). Färdigkriterierna gäller utan undantag. En aktivitet är antingen oklar eller helt klar (och detta ska ha genomslag i burndown och leveranser). Det är viktigare att göra klart påbörjade aktiviteter än att starta nya. Ifall det finns oklara aktiviteter, fråga alltid vad du kan hjälpa till med för att få klart dessa, innan du tar på dig nya arbetsuppgifter.

Sprintpuls
Utvecklingsaktiviteter ska göras klart löpande under hela sprinten eftersom vi strävar efter att minimera risker. Varje gång vi sitter med utcheckad kod och filar på nya funktioner så finns det en risk att vi bygger fel funktioner, introducerar buggar, att vår kod divergerar mot övrig kodbas o.s.v.. Genom att hela tiden utveckla mindre delar minskar riskdeltat och vi undvikar ”merge”-problem i slutet av sprinten. Vi har också möjligheten att verifiera kvalité och leverans under hela sprinten, hela tiden. Sträva efter små väldefinierade användarberättelser, tillräcklig nedbrytning av utvecklingsaktiviteter som är testbara, täta incheckningar och kontinuerlig integration.

Aktivt deltagande
Aktivt deltagande av alla i teamet och ett gemensamt ansvar för leverans och kvalité. Alla ska känna delaktighet och hjälpa varandra utifrån kompetens och förmåga. Alla kan förstås inte göra allt, men alla kan hjälpa och stödja den som kan göra jobbet. Rekommenderar att även verksamheten deltar aktivt i utvecklingsarbetet under sprint. Ofta krävs det en eller annan krissituation innan teamet är helt sammansvetsat. En tuff deadline eller kritiska kvalitétsproblem är alltså inte enbart av ondo.

Tillåt teamet att fokusera
Kompetenta människor klarar sig alldeles utmärkt utan ledning och kan organisera sig själva. En ledares viktigaste uppgift är att låta teamet fokusera på sina uppgifter genom att skydda teamet från allt ovidkommande och att undanröja hinder. I ett team finns det utförare och möjliggörare. Som möjliggörare kanske man inte levererar konkreta arbetsresultat men genom att du låter andra fokusera på utförandet så är du mycket viktigt i din roll.

En introduktion till mjukvarutestning

Tänk ett tag på påståendet ovan. För mig innefattar detta den centrala meningen med mjukvarutestning. Till synes en enkel uppgift men så svår att utföra i praktiken. Testning handlar om kommunikation, information och att ställa frågor. Testning befinner sig i gränslandet mellan krav, utveckling och de verkliga behoven. Testning är den hubb där informationen från dessa tre världar möts och det ger testområdet en särställning inom systemutveckling.

…att jämföra med förväntat resultat

Testning handlar om att jämföra, men hur vet man vad man ska jämföra med och vad som är rätt beteende? Vilka informationskällor finns det att luta sig emot och hur värderar man dessa källor? Kravspecifikationen är förstås en given informationskälla och ett bra och ofta lättillgängligt sätt att ta del av förväntningarna på systemlösningen. Den ofta favoriserade kravspecifikationen är dock inte den enda informationskällan och den är sällan heltäckande. Krav kan vara felaktiga, krav kan ha ändrats, krav kan vara otydliga, krav kan ha glömts bort, krav kan ha kommit till. Som testare måste man ifrågasätta kravställningen och göra egna bedömningar utifrån all tillgänglig information. Förutom kravspecifikationen finns mycket information att hämta i den verklighet där systemlösningen används. Prata med folk, gör studiebesök eller låt användarna vara med i testerna. Var vetgirig och ställ frågor.

Ytterligare en källa till information är hur systemlösningen är utformad. Vilka tekniska val har gjorts? Vilka möjligheter och begräsningar medför de tekniska valen? Finns det områden som behöver testas extra noga? Vilka är de angränsande systement och hur ser integrationerna ut? De icke-funktionella kraven, såsom prestanda, säkerhet, användbarhet o.s.v. är områden som ofta är eftersatta i kravspecifikationen. Vad verkar rimligt, finns det luckor? Egen erfarenhet och intuition är ytterligare ett viktigt redskap. Hur borde systemlösningen fungera? Ger systemlösningen ett ostabilt intryck eller en skev känsla? Vad som utgör en bugg ligger i betraktarens öga. ”A bug is something that bugs me”, tycker jag är en bra utgångspunkt.

…för kreativa utmaningar…

Under själva testandet utgår man ofta från ett testfall, testscenario eller någon annan beskrivning för att fokusera testandet på den aktuella funktionen. I vissa fall kan det finnas skäl till att använda en väldigt detaljerad beskrivning och vid andra tillfällen kanske man helt enkelt improviserar fram tester. Ofta befinner man sig någonstans mittemellan, struktur för att testa effektivt men med möjlighet att släppa ledstången för kreativa infall. Även vid uttrycklig uppmaning att följa testprotokollet så finns det skäl att pröva infall vid sidan av. Testning är ett kreativt arbete och en detaljerad testspecifikation säger inte allt. Uppslag till nya tester kan ske under arbetets gång och buggar kan finnas i områden som ingen hittills förutsätt. Vilka erfarenheter har du själv av vad som kan gå fel? Svenska tecken, division med noll, olika webbläsare, köade transaktioner? Använd ditt eget omdöme och kunskap om systemlösningen både ur tekniskt perspektiv och i produktionssituationen. Vid en misstänkt bugg är det ofta till hjälp att zooma in runt det specifika området. Uteslut parametrar, börja testa från ett känt läge och förenkla testfallen. När man tvärtom vill undersöka förekomsten av buggar kan det hjälpa att zooma ut och köra långa komplicerade testsekvenser med utmanande uppgifter.

En annan dimension är skalan tekniknära respektive användarcentrerade tester. Vi har alla olika kunskap och fallenhet. En del är experter på verksamheten och hur systemlösningen fungerar i produktionssituationer medan andra har omfattande teknisk kunskap och nyttjar detta för riktigt utmanande tester. Båda aspekterna är nödvändiga men välj din personliga infallsvinkel utifrån var du befinner dig på skalan.

...att utsätta en systemlösning…

Det finns mängder av tester att utsätta systemlösningen för. Det kanske vanligaste är enkla funktionella tester i någon form av gränssnitt men det är synd att bara begränsa sig till detta. Populera databasen med inkonsekvent data, läs in korrupta filer, stäng ner batchkörningar vid oväntade tillfällen, ställ om systemklockor och ryck nätverkssladdar! Simulera samtidigt användande, omfattande last, intrång och systemkrascher. Testning är ett kreativt och en smula destruktivt arbete. Ifall du anar något oväntat, fortsätt att provocera systemet ytterligare.

Man behöver inte begränsa sig till testning vid enstaka faser eller leveranstillfällen, utan tester kan göras löpande under hela utvecklingsperioden. Sätt upp en egen utvecklingsmiljö för att kunna köra kodbyggena allteftersom de blir klara eller sitt tillsammans med en utvecklare för att få en inblick i hur systemlösningen växer fram. Ju tidigare som problem upptäcks, desto enklare är det i regel att åtgärda dessa. Ifall tester sker tillräckligt tidigt i samband med utveckling kan man tala om att tester hjälper till och driver utveckling, istället för att passivt mäta kvalité i efterhand. Då blir testning en integrerad del av utvecklingsarbetet och ger maximal nytta under systemlösningens hela framväxt.