Scrumövning med Lego Creationary

När vi ändå är på lekhumör så tänkte jag tipsa om Lego Creationary som en metod att demonstrera utveckling med Scrum. Creationary är en byggsats/spel från Lego Group och innehåller faktiskt allt du behöver för att simulera Scrum enligt förslaget nedan. En övning på två sprintar tar ungefär tio minuter.

Material: Lego Creationary, timer

Roller: 1 product owner (som också faciliterar övningen, 1-3 teammedlemmar

Övningen:

1. Product owner tar ett kort som utgör product backlog (varje kort har fyra user stories, eller modeller som ska byggas).
2. Product owner bestämmer prioritering genom att slå med tärningen...
• Bild (hus, bil, träd, skiftnyckel) = bilden med denna symbol är det högst prioriterade behovet.
• ? = product owner bestämmer själv prioriteringen.
• x2 = product owner väljer två bilder som prioriteras.
3. Sprintplanning: Teamet ställer frågor om detaljerna. Vad är det egentligen product owner behöver, hur ska modellen se ut? Teamet gör en sprintplanering. Vad ska vi bygga och hur, vad hinenr vi på två minuter?
4. Sprint: Teamet bygger utifrån sprintplanen. Sprinten pågår i två minuter.
5. Sprintdemo: Teamet demonstrerar modellen för kravsamordnaren som ger feedback.
6. Sprintretro: Kort retrospektiv i teamet. Hur gick det, vad kan vi förbättra till nästa sprint?

Kör minst två sprintar. Om modellen är färdigutvecklad efter första sprinten så väljer kravsamordnaden en ny modell med hjälp av tärningen.

Creationary, Lego Group (c)

Behöver du bra idéer?

Står ditt team inför någon sorts utmaning där det behövs kreativa och nyskapande lösningar? I denna situation har jag använt mig av kombinationen ”Six thinking hats” och ”Now, how, wow” med bra resultat. Hela övningen tar en halvdag så se till att deltagarna är avspända och närvarande.

”Six thinking hats” är en metod av Edward de Bono för att belysa en frågeställning från olika håll. Sex olika ståndpunkter representeras av sex olikfärgade hattar. Här är en övergripande förklaring men mer information kan enkelt googlas fram.

·         Fakta (vit hatt): fakta, neutral, objektiv, information
·         Känsla (röd hatt): intuition, magkänsla, känslor
·         Negativ (svart hatt): kritisk, analytisk, logiskt negativ
·         Positiv (gul hatt): optimistisk, solsken, logiskt positiv
·         Kreativ (grön hatt): idéer, möjligheter
·         Organisatör (blå hatt): agenda, process, överblick, beslut

Steg 1: Använd gruppen för att presentera och samla in tillgänglig relevant fakta (vit hatt)

Steg 2: Fundera kring känslor, obekräftade rykten, dolda agendor o.s.v. (röd hatt)

Steg 3: Tillåt gruppen att vara riktigt negativ, måla fan på väggen utifrån värsta tänkbara scenario (svart hatt)

Steg 4: Byt läge totalt och försökt nu att få gruppen att tänka så positivt som möjligt (gul hatt)

Steg 5: Utifrån alla insamlade fakta, känslor, positiva och negativa aspekter, släpp lös en brainstorm där gruppen utmanas dela med sig av sina mest kreativa och nyskapande idéer (grön hatt)

Steg 6: Den blå hatten används för att facilitera och styra mötet, växla mellan hattar och driva processen framåt. Den är din i egenskap av organisatör

Nästa steg i processen är att värdera de olika idéerna från sessionen med den gröna hatten. Det kan göras med en teknik som heter ”Now, how, wow”. Rita upp en kvadrant enligt grafiken nedan. Läs upp de insamlade idéerna och placera dem i rätt ruta med hjälp av gruppen.

Idéer som hamnar i första rutan är av typen ”lågt hängande frukt” de är lätta att införa, men kommer troligen inte att leda till exceptionella resultat. Idéer i tredje rutan är av typen ”framtida mål”, originella och nyskapande men svåra att genomföra i nuläget. Idéer i fjärde rutan är varken nyskapande eller lätta att genomföra. Dessa ägnar vi ingen mer uppmärksamhet åt.

Det vi är ute efter är idéer som kan placeras i den andra rutan. Här är originella idéer som dessutom är lätta att genomföra. Idéer med stort genomslag som kommer att göra verklig skillnad. Ifall gruppen får ihop ett par tre idéer i denna åtråvärda ruta, har det varit en mycket välspenderad aktivitet.

Testare och utvecklare, kärlek och hat...

Har du någon gång varit med om att du som testare har hittat en riktigt skön bugg? En riktig goding som varit tillfredställande komplicerad att rota fram men som är tillräckligt allvarlig för att sänka hela releasen. Låt oss anta att du har gjort det och, uppfylld av vetskapen av att ha gjort ett riktigt bra jobb, ivrigt registrerar den i ditt ärendehanteringssystem. Efter att ha lagt till komplett med steg-för-steg beskrivning, skärmdump, prioritet, testområde och sjuttio-elva andra saker enligt IEEE 829 känner du dig riktigt nöjd med dig själv. Det är då som du får ett surt ”rejected” tillbaka med enda kommentaren - ”works as designed”. I det läget ligger det nära till hands att förbanna den tröga utvecklaren och påbörja en rejäl bug advocacy. Följaktligen går du på ännu hårdare, återupprepar buggen tio gånger, beskriver i ännu mer detalj, gör en konsekvensanalys, en egen spontan felsökning och är nittio procent säker på vad som orsakar felet! Tio minuter efter återöppnat ärende kommer svaret - ”rejected, works for me”. Vad är det som händer? Det är ju helt absurt? Hatar utvecklare testare?

Det påstås ofta att utvecklare och testare bör hålla sig lite ifrån varandra. Hålla sig på sin egen kant av utvecklingsspektrat och inte beblanda sig alltför mycket. T.ex. står det i ISTQB att ”oberoende leder till bättre tester”. Andra vill dra detta ännu längre och ser till att placera utvecklare och testare i skilda rum, avdelningar, kontor eller kontinenter. Allt detta leder till färre kommunikationsmöjligheter, mindre sammarbete och sämre tester. Hur ska man kunna testa något om man inte vet hur det är uppbyggt och är tänkt att fungera? Ju mer information som finns tillgänglig, desto mer relevanta tester kan göras. Vi pratar mycket om vikten av testtäckning samt spårbarhet mellan krav och testfall. Är inte den tekniska systemlösningen en lika viktig komponent i teststrategin? Istället ser vi att testare och utvecklare hålls isär rent organisatoriskt. De placeras ofta i olika avdelningar under olika chefer. Formella processer stryper kommunikationen och tvingar folk att skriva ärenden i ärendehanteringssystem, istället för att prata med varandra. Jag anser att detta leder till sämre arbetsklimat, dåliga leveranser och dålig systemkvalité.

De flesta utvecklare tycker om att få sin kod testad. Seriösa utvecklare, som vill göra ett bra jobb, tycker det är jobbigt när deras misstag eller missuppfattningar får konsekvenser i produktion. De flesta utvecklare uppskattar en klåfingrig testare som utmanar lösningen med kreativa testuppslag. En testare som har en god uppfattning om kravbilden, verksamhetens förutsättningar och produktionssituationen. En testare som kliar på eventuella sårskorpor tills de blöder och tillsammans med utvecklaren kan bygga en bra lösning. Seriösa utvecklare ser det som en utmaning och en hjälp i arbetet. Testare kan vara extremt nyttig för utvecklaren. Testaren har ofta unik kunskap om hur systemlösningen används i praktiken och kan se hur en isolerad funktion passar ihop med systemet i övrigt. Testaren vet hur kraven ska tolkas, vad som krävs av lösningen i en produktionssituation, vilka som använder systemet och hur. Utvecklare kan ge testaren viktig kunskap om hur lösningen är byggd, vilka svagheter som finns och hur lösningen kan testas. Utvecklaren kan också göra jobbet lättare för testaren genom att bygga in testbarhet, hjälpa med testmiljöer, testverktyg och liknande.

Men ofta ser det ju inte ut så. Testaren får ofta sin leverans långt efter att utvecklaren är klar. Ett specifikt krav kanske inte testas förrän en månad efter funktionen har utvecklats. När fel uppstår ska alltså utvecklaren sätta sig in i och svara för fel som gjordes för en månad sedan. För att förvärra det hela så utgår testaren från en kravspecifikation som kanske är uppemot ett år gammal. Mycket är irrelevant, medan annat har ändrats under resans gång, viktiga saker kan ha tillkommit och det finns säkert ett antal viktiga krav som inte beskrivits alls. Inte konstigt att utvecklare har en tendens att bli irriterade när testare dyker upp med sina fynd. Lyckligtvis kan man ganska enkelt förändra den här situationen.

Sök upp de utvecklare som bygger koden som du ska testa. Ta med dig glass eller bullar och be att få sitta tillsammans med dem. Luncha med dem, lyssna och delta i deras diskussioner. Se till att bli upptagen i gruppen och börja arbeta tillsammans.

Om du är en teknisk testare så ta reda på vilka verktyg utvecklarna använder och lär dig använda dem. Ta reda på hur du kan komma igång och testa effektivt redan i början av utvecklingsperioden istället för att vänta på kompletta leveranser mot slutet. Skaffa en egen utvecklingsmiljö och ta emot de senaste kodversionerna. Använd utforskande testning för att komma igång snabbt utan testfall. Undersök möjligheter att effektivisera tester genom smarta tekniska lösningar och automatisering.

Om du är en verksamhetsorienterad testare, ta reda på så mycket som möjligt om verksamheten och den omgivning som systemlösningen ska verka i. Bli en expert på hur kraven ska tolkas, vilka outsagda krav som finns och vad verksamheten förväntar sig.

Fyra hörnstenar i agil testning

Den här bloggposten beskriver vad jag tycker är de fyra mest viktiga förutsättningarna, eller hörnstenarna, för framgångsrik agil testning. De fyra hörnstenarna är: continuous integration, testare i teamet, context driven test och testautomatisering. Alla dessa områden behöver identifieras, undersökas och hanteras för framgångsrik agil testning. De fyra hörnstenarna är alla vanliga arbetssätt inom den agila världen och i den context drivna testskolan, men oftast inte ihopsamlade som förutsättningar för agil testning och kombinerade med varandra.

I den här illustrationen är de fyra hörnstenarna mappade till berörda områden i min metod för agil testning. Metoden beskrivs i mitt white paper ”JAM & ACT”



Testare inom teamet



Min definition på agil testning är när systemtestaktiviteter utförs inuti ett agilt utvecklingsteam. Både utvecklare och testare ska arbeta på samma utvecklingsiteration, och kodbas, och ”definition of done” ska innefatta systemtest. Både testare och utvecklare har gemensamt ansvar för systemets kvalité.

Uppmana till arbete mellan testare och utvecklare! Utvecklare kan ge värdefulla insikter om systemets arkitektur och potentiella svagheter. Testare kan hjälpa utvecklare med att hitta fel, föreslå lösningar och därmed förbättra systemets kvalité redan under utvecklingsfasen. Testare har oftast god kunskap om systemkrav, driftsituationen och systemet i dess sammanhang. Den här informationen är väldigt viktig för att ta rätt implementationsbeslut. Dessutom kommer tiden för att leverans till test, testexekvering samt rapportering, att minska med testare i teamet.

Att låta testare arbeta på separata testleveranser efter utvecklingsiterationen främjar inte samarbete, omöjliggör den agila processen och är i praktiken ett vattenfall.

Context driven test
Traditionella systemtesttekniker fungerar dåligt i agila sammanhang. Traditionell testning är för dokumentorienterad och rigid. När en testprocess, såsom IEEE 829, kräver fem omfattande dokument samt detaljerade kravspecifikationer bara för inledningsfasen, så är det inte rätt metod för agil testning.
I agil testning ligger fokus på produktivt arbete istället för rapportering, verktyg istället för dokumentation, snabbhet och flexibilitet istället för perfekta planer och processer.

Metoder som används inom context driven passar bättre än traditionell testning. Den kontextdrivna testaren tror inte på best practises, utan istället på anpassning utifrån förutsättningarna. Exempel på context driven är utforskande testning, session based-/thread based testing, just-in-time testing, modelbaserad testning o.s.v. Kunskap om dessa tekniker gör testteamet förberett inför den agila utmaningen.

Continuous integration
Målet med continuous integration är att implementera och bygga systemet i små steg för att förhindra svårigheter med integration och mergning. Små kodsnuttar utvecklas regelbundet och checkas in i ett gemensamt repository. Det triggar ett automatiserat kodbygge, ofta med automatiserade tester och deploy. Det märks snabbt ifall kodförändringar är korrekta och eventuella rättningar kan göras på ett tidigt stadium
.
Continuous integration är en utmärkt bas för automatiserad testning samt version och releasehantering. Det är också en bra utvecklingsmetodik som förhindrar ”happy hacking” och ”trial and error”-programmering. Continuous integration är först och främst utvecklarnas ansvar men en erfaren agil testare borde vara kapabel att bidra med goda exempel och synpunkter utifrån testarnas behov.

Testautomatisering
En vanlig källa till problem inom agil testning är de frekventa kodbyggena och testreleaserna som skapas med continuous integration.  Korta utvecklingsiterationer med sprintreleaser spär på problemen. Testautomatisering är nödvändigt för att förhindra att den agila testaren drunknar i återkommande regressionstestning. Det är inte effektivt att automatisera alla tester utan de oftast använda och tidskrävande testerna bör automatiseras först. Kostnaden för automatisering är oftast högre än vad som först uppskattats.

Semiautomatisering, såsom stöd för test uppsättning och nedtagning, datagenerering, intelligenta mockar och automatiserade batchkörningar kan också vara mycket effektivt. Ansvaret för testautomatisering ligger både hos utvecklare (komponenttester i byggen) och testare (automatiserade system- och regressionstester). Det är bra att använda verktyg och ramverk som passar både utvecklare och testare. Stöd samarbete och håll det hela enkelt. En dedikerad verktygssmed kan vara behjälplig med teknisk expertis om verktyg, mockar, ramverk och miljöer.

Talentum testkonferens

I början av veckan deltog jag på testkonferens i Stockholm arrangerad av NFI/Talentum. Konferensen bjöd på ett antal föreläsningar främst inom områdena agil test och testautomatisering. I slutet av konferensen samlades tiotalet deltagare i en workshop om testautomatisering. Denna workshop lotsades av Jonas Hermansson med sedvanlig säker hand och det var synd att inte flera personer deltog då det bjöds på många bra insikter och aha-upplevelser. Här är några punkter som jag tar med mig...

• Automatiseringskod är lika viktig som resten av kodbasen och ska versionshanteras och förvaltas på samma sätt av samma organisation.
• Automatiserade testfall är en del av förvaltningsobjektet och bör ligga hos berörd förvaltningsorganisation.
• Det är viktigt med en välgenomtänkt arkitektur och lämpliga abstraktionsnivåer för att inte bygga fast sig.
• Ett lämpligt automatiseringteam består av utvecklare som kan systemet, testare som kan domänen och en expert som kan automatisering.
• Börja enkelt med sånt som ger stor effekt, samt kan återanvändas och ge vinster för de manuella testerna.
• Man tjänar inte pengar på testautomatisering men däremot frigörs resurser för komplex manuell testning samt att man kan hålla ett högre releasetempo.

Insikter om ISTQB

Det går en skiljelinje idag mellan de testare som förespråkar traditionell testning och de som föredrar kontextdriven testning. Mitt i skottlinjen ligger ISTQB-certifikaten, som många av oss testare har och många organisationer efterfrågar. ISTQB-certifikaten har blivit en de-facto standard för testarbetet men det förenklade och smula dogmatiska innehållet gör att det ifrågasätts, främst av den kontextdrivna skolan. Eftersom det var ganska länge sen som jag tog min certifiering så satte jag mig ner för att fräscha upp minnet om vad ISQTB-syllabus verkligen innehåller.

Jag håller med om att ISTQB är skriven med ett genomgående självsäkert tonfall som får innehållet av verka mer vedertaget än vad som är fallet. Det är en teoretisering av samma typ man lär sig i skolan innan man förstår att den verkliga världen är mer komplex än vad lektionerna ger utrymme för. Det som jag tycker är mest graverande är dock tyngdpunkten vid traditionell testning och obskyra standarder. Många testare är påväg ifrån sådana begränsningar och om ISTQB ska vara relevant så borde man lämna utrymme även för kontextdrivna förhållningssätt.

Lite fler tveksamheter följer här:

• ISTQB gör ett stor nummer av skillnaden mellan "error", "defect", "fault", "failure" och "bug". Jag har aldrig förstått varför alla dessa distinktioner och nöjer mig med Rob Sabourins definition "To make our job more fun, whenever we have a concern with software, we call it a "bug".
• Att dela upp testarbetet i fem olika faser, varav en innehåller faktiskt testgenomförande till hälften, är inte bara vattenfall utan nedgradering av testarens viktigaste arbetsuppgift till förmån för administration. ISTQB's testprocess definieras såsom (planning and control, analysis and design, implementation and execution, evaluating exit criteria and reporting, test closure activities.
• ISTQB menar att oberoende leder till bättre tester. Jag tror att ett gemensamt ansvar för leverans och kvalité med testare som jobbar nära utvecklarna leder till oslagbara resultat.
• Integrationstester beskrivs som att systemkomponenter kopplas ihop och testas tillsammans innan systemtester tas vid. Systemintegrationstester nämns inte alls.
• Att ta upp "test design specification", "test case specification" och "test procedure specification" samt jämföra skillnader dem emellan är hårklyverier. Finns det organisationer som använder sig av alla dessa specifikationer och dokument. På samma sätt gör man en stor sak av skillnanden mellan "test policy", "test strategy", "master test plan" och "level test plan".
• ISTQB verkar närmast fixerad vid olika standarder och nämner IEEE-829, IEEE-1044, IEEE-1028, CMM, CMMi, TMM, TMMi och TPI. Jag har rätt ingående studerat IEEE-829 samt TPI och anser att det läggs alldeles för stor vikt vid dokumentation och frågan är om det gör att testerna blir så mycket bättre.

Trendspaning Testing Forum 2012

Kunde inte låta bli att publicera några synpunkter från talarna på kommande Testing Forum 2012. Det är måhända ursäktat eftersom jag ändå är en av dem som är med och tycker till...


Vilka trender och vilken utveckling ser du inom testing-området det kommande året?

Örjan Bjermert, Test Manager, Omegapoint:
Jag tror på flitigare användande av verktyg, automatisering och tekniknära tester. Till viss del kommer testprovisionen att delas upp mellan de som förordar kontextdrivna tester och de som föredrar mer traditionella testmetoder.

Anders Claesson, Senior Test Specialist, xdin:
Att nästan alla går över till att jobba i Agila projekt, även de stora företagen. För testningens del kommer erfarenhetsbaserade testtekniker att användas allt mer, t.ex. exploratory testing, riskbaserad test, m.fl.

Günter Lenhardt, Testspecialist, Wasa Kredit:
Testautomatisering och outsourcing kommer att spela en allt viktigare roll inom test.

Jagannath Tammeleht, OnTrax:
Jag tror att testområdet kommer fortsätta växa även om vi kan se en tydligare personalbrist. Vi kommer även se fler specialist inriktningar så som agilt, prestanda testning, automatisering, testledning, användartestning osv

Kristian Karl, Testchef, Spotify:
Ökad grad av testautomation

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
Agil utveckling sätter definitivt sina spår i testplanering. Om man inte ser upp, finns dock stora risker, att det påverkar grundtänkandet i test (att ha väl utvecklat tänkande för att hitta fel)

    
På vilket sätt har kraven på kvalitet ökat de senaste åren?

Örjan Bjermert, Test Manager, Omegapoint:
Förutom möjligen mindre överseende med teknikstrul så ser jag inte att kvalitetskraven har ökat. Det som däremot sker är att testobjekten blir allt mer komplexa och utvecklas under kortare tid.

Anders Claesson, Senior Test Specialist, xdin:   
En ökad användning av Agila arbetssätt ställer högre krav på kvaliteten i och med att man ska ta fram potentiellt release-bar kod i varje inkrement.

Günter Lenhardt, Testspecialist, Wasa Kredit:
Kraven på kvalitet har inte ökat, utan det som har ökat är leveranshastigheten och därmed kraven på att få ut produkter med samma kvalitet som tidigare, dvs. vi måste kunna testa snabbare.

Jagannath Tammeleht, OnTrax:   
Den globala konkurrensen inom de flesta branscher har gjort att företag idag inte har ”råd” att skapa mjukvara med dålig kvalitet. Dålig kvalitet kostar pengar både i goodwill, förlorade kunder och misslyckade projekt. Idag så är även kraven på time to market betydligt högre, det är inte möjligt att avvakta för länge för då har konkurrenterna redan tagit den delen av marknaden. Snabba kontinuerliga releaser kräver en hög kvalitet på produkten under hela utvecklinsarbetet för att inte riskera misslyckade releaser.

Kristian Karl, Testchef, Spotify:   
Jag är inte så säker på att kraven på kvalitet har ökat, snarare att leverera 'just-in-time' med 'lagom' kvalitet.

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
- Ökad verksamhets- och behovförståelse
- Insikt att testningen som är utförd på rätt sätt, kan bidra till ökad kvalitet


Vilka är dina tre bästa tips för att ligga i framkant vad det gäller kvalitet och säkerhet?

Örjan Bjermert, Test Manager, Omegapoint:
Våga se bortanför de traditionella testmetoderna. Ta alltid fasta på det sammanhang och kontext som gäller för testobjektet. Var kritisk, och självkritisk, både gällande testobjektet och dina arbetsmetoder.

Anders Claesson, Senior Test Specialist, xdin:
Att ha en helhetssyn på systemutveckling, test och kvalitet. Det är inte test som är ansvariga för kvaliteten på systemet utan alla i projektet. Att lära sig hur man bäst använder erfarenhetsbaserade testmetoder.

Günter Lenhardt, Testspecialist, Wasa Kredit:   
1. Automatisera allt som går att automatisera
2. Använd den mänskliga kreativiteten på rätt sätt
3. Bevaka din omvärld inom test

Jagannath Tammeleht, OnTrax:
Kompetenta medarbetare är A och O. Utan kompetenta medarbetare spelare det ingen roll hur mycket du försöker förbättra, du kommer ändå inte nå önskat resultat.

En bra och tydlig strategi/process för utvecklingsarbetet, om det saknas så blir även kvalitén lidande. Ofta så vet man inte riktigt vad man menar med exempelvis kvalitet, ska man mäta kvalitet behöver man först förstå vad som menas med det inom organisationen.

En arbetsmiljö som strävar efter att ständigt förbättra och optimera arbetet på alla nivåer. Det är viktigt att våga försöka förbättra och våga misslyckas, kan man skapa denna kultur inom organisationen så har man kommit långt när det gäller kvalitet och säkerhet.

Kristian Karl, Testchef, Spotify:
Förstå produkten och kunden! Ha koll på utvecklingsprocessen, och var beredd att ständigt förbättra den.

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
- Kompetens i test och kravhantering
- Analys och förståelse av kundensbehov och vad som skapar kvalitet för kunden
- Ett managementinitiativ (eller förståelse) att i längden kan kvalitet vara viktigare än tidsplan


Vad har du för förväntningar på konferensen Testing Forum och vad kommer deltagarna få med sig från din föreläsning?

Örjan Bjermert, Test Manager, Omegapoint:
Att ta del av alla spännande testidéer och arbetssätt därute. Jag hoppas bidra med praktiska exempel på hur man kan lyckas med testning inom agila team

Anders Claesson, Senior Test Specialist, xdin:
Att får nya idéer hur man effektiviserar sin testning.

Günter Lenhardt, Testspecialist, Wasa Kredit:   
Jag förväntar mig höra om de nyaste utvecklingarna inom test och träffa kreativa kollegor inom området. Från min föreläsning får man med sig hur man gör för att sätta upp och genomföra en framgångsrik testautomatisering som ger många vinster och en lyckad förvaltning.

Jagannath Tammeleht, OnTrax:   
Mina förväntningar är som alltid att lära mig något nytt, se vilka trender som kommer under 2012-2013. Jag hoppas kunna ge en liten annan ovanligare bild av agilt och test som har mer fokus på mjukare värden och organisationsförändring. Där många föreläsningar fastnar i test automatisering och verktyg så glömmer man ofta det viktigaste och det är den inställning som genomsyrar organisationen. Är den fel så blir det svårt att lyckas övergå till ett agilt arbetssätt.

Kristian Karl, Testchef, Spotify:   
Bli inspirerade.

Ingvar Nordström, ordförande SSTB, vice ordförande SQEB och Beata Karpinska, ordförande SQEB, vice ordförande SST:   
- Från vår föreläsning: Att testkompetens är oerhört viktigt inför den krävande agila verkligheten

Agila testnivåer

Testnivåer används för att fokusera testarbetet och testa utifrån olika egenskaper hos systemlösningen. Vid olika testnivåer upptäckts olika typer av fel samt att de olika testerna skiljer sig i hur lång tid genomförandet tar. Man börjar med basala tester av arkitektur och grundläggande funktioner. Då får man snabb återkoppling om utvecklarna är på rätt spår. De övre testnivåerna handlar om komplexa tester av komplicerade användarfall och systemsamband. I den här bloggposten visar jag hur olika testnivåer kan kopplas till den agila utvecklingscykeln.

Ett vanligt synsätt är att man ska sträva efter att hitta alla fel så tidigt som möjligt vilket beror på ett antagande att kostnaden för att åtgärda buggar ökar med tiden. Jag anser att det inte nödvändigtvis är sant. T.ex. är det kostsamt att hitta och rätta obskyra integrationsfel vid tidiga testnivåer, utan tillgång till angränsande system. Sträva istället efter att testa ekonomiskt och vänta med de komplexa testerna till senare faser. Ifall de basala funktionerna åtgärdas tidigt, så kommer antagligen de felaktigheter som upptäck senare att kunna åtgärdas relativt enkelt.

Några ryska matrushka-dockor får symbolisera olika testnivåer. Varje testnivå har olika syften och tid för återkoppling till utvecklarna skiljer sig åt.

TDD och parprogrammering

Testerna börjar redan medan utvecklarna skriver sin kod. Med bra utvecklardiciplin kan många fel hittas redan från början. De fel som hittas kan åtgärdas omgående och dessa typer av utvecklingsnära tester kan alltså bli mycket effektiva. Ge utvecklarna tid för att experimentera med parprogrammering och testdriven utveckling. Även testare och utvecklare kan arbeta i par och bidra med respektive kompetens.

Continuous integration

Här handlar det om att implementera och integrera små utvecklingsdelar i taget. När utvecklarna är klara med en delfunktion adderas koden till den gemensamma kodbasen. Därefter följer ett automatiserat kodbygge med ev. automatiserade modultester. Kodbygget kan även innehålla enklare regressionstester, deploy till testmiljöer och liknande. Genom täta incheckningar och kontroller av hur ny kod fungerar i systemet så kan avvikelser åtgärdas tidigt. En annan fördel är att med continuous integration får man ett bra ramverk för versionshantering, releasehantering och testautomatisering.

JAM-test

I det agila projektet finns behov av proaktiv testning av utvecklingsaktiveter allt eftersom dessa blir klara. Eftersom utvecklingsaktiviteterna ej är entydiga med användarfall eller testscenarier så kan man inte tala om regelrätta systemtester. Syftet är istället för testarna att ge så effektiv återkoppling som möjligt på de nyutvecklade funktionerna, gärna med utforskande testtekniker. Jag kallar detta för JAM-test och redogör för detta i tidigare blogginlägg.

ACT-test

I slutet av en agil utvecklingscykel ser jag ofta behovet att göra systemtester och regressionstester på hela levererade kodbasen efter kodfrys. Eftersom tidigare tester gjorts på delar av funktioner utifrån delleveranser från utvecklarna så är detta kanske första gången som användarfall kan köras i sin helhet. Det är också första gången som alla funktioner finns med i en potentiell releasekandidat. Jag kallar detta för ACT-test och ser det som ett koncentrerat hypereffektivt systemtest. Testerna är nu mer formella än tidigare testnivåer och veriferar de användarfall som ska levereras utifrån de testscenarier som skapats av testerna. Jag berättar mer om ACT i ett tidigare bloginlägg.

Systemintegrationstest och acceptanstest

Systemintegrationstest och acceptanstest är väsenskilda de övriga testnivåerna eftersom de ofta görs utanför den agila utvecklingscykeln. Dessa tester innefattar angränsande system och organisationer utanför det agila teamets kontroll. Man kan därmed inte ställa samma höga krav på effektivitet i genomförande och återkoppling. Se till att planera för nödvändiga testaktivteter och åsidosätt resurser i lämpliga sprintar så att teamets övriga arbete inte blir lidande när systemintegrationstester och acceptanstester pågår samtidigt som ordinarie utvecklingsarbete.

Agila proaktiv testning och traditionell testexpertis

För en testare i ett agilt team, upptagen med ett oändligt antal testaktiviteter, finns det alltid en risk att bli alltför utvecklingsorienterad. Trots att man blir avbruten med nya testreleaser varje dag så är det fortfarande viktigt att fokusera på helheten, testtäckning och kravuppfyllnad. Mitt upp i det hela, när man frågar sig hur en funktion verkligen ska fungera, så är det förförande enkelt att ta till sig utvecklarens uppfattning. Resultatet blir att en oerfaren testare börjar fokusera på ”vad som finns” när ”vad som saknas” förstås är lika viktigt. Det är nödvändigt att den agila testaren ibland tar några steg tillbaka och tänker på testaktiviteterna utifrån testtäckning, testscenarier och testidéer. Att kombinera teknisk proaktiv testning med kravbaserade traditionella tester, utan att låta någon av dessa stå tillbaka, är en riktig utmaning för den agile testaren.

Det första som sker när ett agilt team startar en ny utvecklingscykel är att den aktuella kravmassan bryts ner till underuppgifter inför utveckling. Det är väldigt viktigt att testarna är med på dessa aktiviteter. Att bryta ner krav till utvecklingsuppgifter hjälper testaren att förstå funktionerna och låter testaren bidra med kunskap om testbarhet, användbarhet och allmän systemkunskap. Vissa krav kan resultera i rena testaktiviteter. Exempel är icke-funktionella tester (såsom prestanda, säkerhet, användbarhet, förvaltningsbarhet et.c.) eller rena testaktiveter (t.ex. hantera testmiljöer och arbeta med regressionstester). Testuppgifterna utförs och följs upp precis som vanliga utvecklingsaktivteter. Kom bara ihåg att uppmärksamma tidsaspekten så att testarna har tillräckligt med tid att utföra dessa uppgifter och samtidigt kunna genomföra ordinarie testaktiviteter. Det är viktigt att införliva testaktiviteterna i mängden av uppgifter i utvecklingscykeln, likväl som rena utvecklingsaktiviteter.

I ett agilt team är det oftast fråga om ett par dagar innan utvecklarna har funktioner implementerade och klara för test. Än kan man inte förvänta sig att alla funktioner har grafiskt gränssnitt eller är fullständigt integrerade. Till en början får man som testare oftast nöja sig med databasscheman, fristående funktionslogik och liknande. Med lite teknisk systemkunskap bör det inte vara något större problem att testa småbitar av funktioner såsom de levereras. Ibland kan det vara en bra idé att låta testare och utvecklare arbeta i par och nyttja varandras kunskaper för testning och utveckling. När det inte finns några nya funktioner att testa finns det fortfarande mycket att göra. Testare kan arbeta på nya testscenarier eller testidéer utifrån krav och annan tillgänglig information. Testmiljöer, testdata och testverktyg behöver sättas upp. Kanske finns det testautomatisering som behöver utföras eller nya testmetoder och verktyg som är intressanta och behöver utvärderas? Det är viktigt att testarna kan bidra med allt detta och samtidigt fokusera på proaktiv testning.

En vanlig missuppfattning är att samtliga i ett agilt team ska jobba med utveckling och göra ungefär samma saker. Det är förstås inte sant. Alla har ett gemensamt ansvar för utveckling och kvalité men man kan bidra till det övergripande målet utifrån olika roller. Ifall det finns någon i teamet med ansvar för testplanering, testrapportering, testmiljöer/-verktyg/-data (formellt eller informellt), så är det förmodligen en testledare. Testledaren hör hemma i det agila teamet men eftersom det knappast finns uppgifter för en testledare på heltid så funkar det jättebra att komplettera med vanligt testarbete . Det behövs någon som har övergripande kontroll över vilka tester som görs, systemets kvalité och vidareutvecklar testarbetet. Ytterst är det testledarens ansvar att testarbetet skrider framåt. Det är också viktigt att testningen sker så effektivt som möjligt och alltid sträva efter förbättringar, antingen i testprocessen eller med hjälp av förbättrat tekniskt stöd.

Med alla utvecklingsaktiviteter levererade och alla delfunktioner individuellt testade, finns det en skaplig chans att också den kompletta levererade funktionen kommer att fungera väl. Det är nu som testaren måste byta fokus och verkligen verifiera funktionen utifrån krav, användarfall, systemets kontext eller annan tillgänglig information. Ett bra sätt att göra detta är att utgå från skrivna testscenarier eller checklistor. Testscenarier behöver inte vara särskilt detaljerade så länge som de hjälper testaren att se helheten och jämföra med vad som levererats. Nu testas hela användarfall snarare än enskilda små funktioner. Väl beprövade traditionella testtekniker är viktiga i vad som liknar ett traditionell systemtest, fast i kondenserad form.

Utvecklingscykeln avslutas vanligen med en sprintdemo, ”go/no go”-möte eller liknande. Där beslutas det om implementerade funktioner är tillräckligt bra för release. Testarna demonstrerar de viktigaste funktionerna och kravställarna uppmuntras att pröva egna testidéer. Testarna delar med sig av sin syn på systemets kvalité och det bestäms ifall systemet är tillräckligt bra för en release. En release kan sen göras till acceptanstestmiljö, för ytterligare tester utanför teamet, eller direkt till produktion.

1. Six development activities are being developed.	2. Four of them are finished and some successfully tested.
3. The rest of them are finished and some more successfully tested.	4. When all of them are finished and individually tested, chances are that the whole test case will be successful even though it has not been run in its full extent before.

Den agila testexplosionen

Det svåraste i agil testning är det ständigt växande testbehovet. Testbehovet ökar med varje utvecklingscykel då ny funktionalitet läggs till i systemet. För att göra saker värre så behöver ofta nya funktioner testas tillsammans gammal funktionalitet, vilket leder till en exponentiellt ökande testmängd. Det här problemet kan relateras till det väldefinierade begreppet ”entrophy death” inom programmering och några potentiella lösningar är gemensamma. Den agila testexplosionen behöver hanteras från första början i varje agilt projekt. Annars kommer den kombinatoriska explosionen göra att testbördan så småningom slår i taket. Utan förberedelser är det nästan omöjligt att bryta en negativ trend.

Föreställ er ett Scrumteam med konstant ”velocity” (så är oftast inte fallet eftersom ett Scrumteam alltid strävar efter att öka ”velocity” genom att minska ”waste”, men för testarens arbetsbelastning är detta ett idealiskt exempel). För varje sprint måste alla funktioner, nya såväl som gamla, testas. I värsta fall måste alla funktioner testas i kombination med varandra. I detta värsta fall ökar testbördan med fakultetsprodukten av alla implementerade funktioner. Vid den femte sprinten har testbördan ökat 125 gånger. Vid testning av den sjätte sprinten är ökningen 720 gånger. Trots att detta är ett extremt exempel så visar det på problemets omfattning. I vart fall ökar testbördan i det närmaste exponentiellt. Den agila testexplosionen kan därför inte lösas med fler resurser eller testautomatisering. För att hålla kontrollen behövs en strategi med fler angreppssätt samtidigt. Angreppssätten spänner över flera olika områden, såsom systemarkitektur, systemets testbarhet, test- och utvecklingsmetoder.

Modulär design

Den viktigaste aspekten för att förhindra en agil testexplosion är att ha en genomtänkt systemarkitektur. Sträva efter en modulär design med lösa kopplingar så att varje funktion kan utvecklas och testas var för sig. I det optimala fallet resulterar det i ett litet antal funktionella kombinationer att testa och en nästan linjär ökning av testbördan.

Testbarhet

Testbarhet är ett mått på den arbetsinsatts som behövs för att testa systemlösningen. Med dålig testbarhet kommer testarna att lida mer av den kombinatoriska explosionen och nå taket tidigare. För bättre testbarhet kan man ställa följande frågor:

• Hur lätt är det att kontrollera och observera systemet under test?
• Är det möjligt att testa isolerade funktioner för att undvika beroenden?
• Är det enkel att använda och förstå systemet?
• Can vanliga procedurer automatiseras för mer effektiv testning?

Test automatisering

Ett vanligt missförstånd är att den agila testexplosionen kan lösas med enbart testautomatisering. Anledning till att det inte går är ganska uppenbar. Eftersom testbördan ökar exponentiellt kommer implementation av nya testfall snart att vara ohanterbart. Det finns alltid en kostnad för utveckling och förvaltning av automatiserade tester och så småningom kommer teamet att använda alla resurser bara för automatisering. Testautomatisering spelar dock en viktig roll i den övergripande strategin för att hantera den agila testexplosionen. Implementerade regressionstester kommer att frigöra värdefulla testresurser som i sin tur kan förbättra manuell testning av komplexa funktioner. Testerna kan också göras mer effektiva med semi-automatisering av krävande testuppgifter. Det kan röra sig om uppsättning och nedtagning av tester, skapa testdata o.s.v.

Kontrollera förändringar

Genom att hålla kontroll på förändringar i kodbasen kan man fokusera testerna där de behövs. Det finns flera verktyg som kan spåra förändringar på detaljerad nivå. Diskutera med utvecklarna hur ändringar påverkar implementerad funktionalitet och föreslår goda lösningar.

Testa smartare

Slösa inte bort dyrbar testtid på onödigt stelbenta testprocedurer eller dokumentation. Ett Scrumteam strävar alltid mot att minimera ”waste” och öka ”velocity”. Testare i ett Scrumteam bör göra detsamma. Är det möjligt att välja bort en del regressionstester eller köra olika regressionstester vid olika tillfällen? Är det möjligt att testa flera funktioner samtidigt? Använder testteamet alla resurser effektivt eller saknas det någonting? Finns det nya verktyg eller idéer därute som kan vara tillämpbara? Vad kan resten av Scrumteamet göra för att stödja testarna på ett bättre sätt?

Agil testledare

En vanlig missuppfattning är att samtliga i ett agilt team ska jobba med utveckling och göra ungefär samma saker. Det är förstås inte sant. Samtliga medlemmar har ett gemensamt ansvar för för utveckling och kvalité men man kan bidra till det övergripande målet utifrån olika roller. Ifall du har någon i teamet som ansvarar för testplanering, testrapportering, testmiljöer /-verktyg /-data (formellt eller informellt), så är det förmodligen en testledare. Testledaren hör hemma i det agila teamet. Det behövs någon som har övergripande kontroll över vilka tester som görs, systemets kvalité och vidareutvecklar testarbetet.

En testledare är oftast väl insatt i mjukvarutestning och kvalitetsarbetet. Förutom detta behöver en testledare i ett agilt team också känna till agila och lättviktiga utvecklingsmetoder samt hur man anpassar testprocessen till en agil utvecklingsmodell. Det är viktigt att kunna hörnstenarna i agil testning, såsom utforskande testning, kontextdrivna tekniker och testautomatisering. En annan viktig uppgift är att verka för kvalitetstänkande hos utvecklarna genom att att införa bra arbetssätt, såsom testdriven utveckling och continuous integration. Det finns oftast inte tillräckligt med testledaruppgifter för att hålla en testledare igång på heltid. Därför jobbar ofta testledaren även som testare. Praktiskt testarbete är nödvändigt för att få insikt om systemet kvalité, testmiljö, /-data, /-verktyg samt testarnas förmåga.

Testledarens arbete kan delas upp i tre huvudkategorier: planering, kontroll och rapportering. Övergripande planering görs för hela projektet. Planen uppdateras och utökas per utvecklingsiteration. Planen ska hållas enkel och fokusera på  teststrategi, testområden, testmiljöer, /-data, /-verktyg, tid och resurser. Kontrollaktiviteter ska också hållas enkla och kan utföras effektivt med få mätetal t.ex.: testtäckning, fel i olika delar av systemet och testarnas arbetsbelastning. Skrivna rapporter är oftast inte nödvändiga eftersom testledaren deltar på sprintdemo, "go/no go" och liknande.

Rena testledaraktiviteter utförs ofta utanför ordinarie arbete i utvecklingscykeln. En testledare måste ofta planera flera cykler framåt och utifrån hela projektet. Vissa testaktiviteter, t.ex. prestandatest och systemintegrationstest, kan ej kopplas till funktioner i en speciell utvecklingscykel. Det är då upp till testledaren att planera när det sådana uppgifter ska genomföras.

Typiska uppgifter för testledare är planering, kontroll och rapportering. Detta sker oberoende av testcykeln då testledaren ofta måste planera för flera utvecklingsiterationer framåt.