Continuous Delivery handlar inte bara om verktyg

När vi pratar om Continuous Delivery är det lätt att börja diskutera den tekniska implementationen av en Deployment Pipeline. Det finns flera förklaringar till att det är så, inte minst så är det en rolig teknisk utmaning där det finns en stor verktygsflora att välja mellan för att hitta lösningar. Problemet med att vi ofta börjar med att diskutera verktyg är en ökad risk för att, helt eller delvis, missa betydelsen av de underliggande principerna som Continuous Delivery bygger på. Det är lika viktigt, kanske viktigare, att kunna svara på varför man gör något än att kunna svara på hur man gör något.

Varför?

Det finns många fördelar med Continuous Delivery och det gör att det väldigt lätt att glömma det viktigaste målet. Genom att leverera mjukvara till produktion ofta så lär vi oss att leverera på ett säkert och effektivt sätt. Vi får även snabbare återkoppling från våra kunder. Återkopplingen visar om vi gör rätt saker, saker som tillför värde för våra kunder.

När vi automatiserar vår leveransprocess blir den så robust och så snabb som det bara är möjligt. Det resulterar i att utveckling och leverans av mjukvara inte längre är en flaskhals. Tillsammans med agila metoder som mäter hur mycket arbete som hinns med per tidsenhet, flyttas fokus till att affärssidan måste prioritera vad som ska utvecklas först. Drar vi det ett steg längre så begränsas vi därför snarare av hur många förändringar organisationen och dess kunder kan hantera samtidigt.

Eftersom vi versionshanterar allt som påverkar vårt system så åstadkommer vi spårbarhet och vi vet alltid vem som ändrade något och när den ändringen gjordes. Det gör att vi lättare kan se vad som orsakade att något gick sönder. Vi bygger också in robusthet eftersom vi kan återskapa vårt system om något oförutsägbart skulle hända. På så sätt minimerar vi risken för att våra kunder ska råka illa ut vid eventuell nedtid. 

Slutligen

Visst är Continuous Delivery en intressant teknisk utmaning, det är dock viktigt att komma ihåg att vi gör det för att förbättra livet för de som använder våra system. Det är kunderna som berättigar existensen av en utvecklingsavdelning och därmed får vi inte tappa målet när vi inför tekniska lösingar.

 

Martin Johansson
martin.johansson@metrical.se

Testautomation som förutsättning för Continuous Delivery

När man arbetar enligt Continuous Delivery blir testautomation en förutsättning för att leverera hög kvalitet över tid. Det beror på att testautomation blir den sista utposten för att hitta regressioner och bevisa att systemet fungerar som förväntat. Utan väl fungerande testautomation blir systemets kvalitet därför lidande och företagets förtroendekapital riskerar att ta skada. Att lyckas med testautomation är inte trivialt men det finns flera orsaker som vi kan påverka för att öka chanserna att lyckas.

I den här artikeln behandlar jag en av orsakerna, den styvmoderliga hanteringen av arkitekturen på testautomationslösningar.

På testautomationsfronten intet nytt

Viljan att arbeta med testautomation fanns redan innan Continuous Delivery myntades som begrepp och fick ett uppsving med de agila metodernas intåg. Det som förändrats sedan Continuous Delivery kommit fram som ytterligare ett steg för att bli mer agil, är att testautomation har gått från nice-to-have till must-have. En Deployment Pipeline utan fungerande testautomation resulterar i falsk säkerhet vad gäller release-kandidatens kvalitet och är därför att betrakta som en stor kvalitetsrisk.

Arkitekturera mera

Kravet på en automatiserad lösning bär stora likheter med produktionskod. Det måste gå att skapa nya värdefulla tester på ett enkelt sätt, samtidigt som kostnaden för underhållet av befintliga tester måste hållas på en minimal nivå. Eftersom testautomation med få undantag resulterar i kod, måste vi börja hantera det på sätt som vi vet passar för kod. Därför krävs det kontinuerligt arktiekturellt arbete, kodstandard, enhetstester, versionshantering och andra hygienfaktorer som hör kod till. 

I mjukvaruindustrin högaktar vi de personer som kan konstruera system, system som uppfyller kundernas krav, men som också är elegant konstruerade. System som håller över tid, är lätta att förvalta och vidareutveckla kan vara en stor konkurrensfördel.

Tyvärr har angreppssättet för att bygga testautomatiseringslösningar inte fått samma arktiekturella uppmärksamhet, utan snarare fått en styvmoderlig behandling. För att lyckas med testautomation så krävs att lösningens kodbas behandlas som produktionskod och att arbetet med testautomation får högre status inom organisationerna.

Utan ett sådant arbete kommer vi sannolikt inte se fler lyckade testautomationslösningar än vad vi har idag och därmed ha stora svårigheter att framgångsrikt arbeta med Continuous Delivery.

 

Martin Johansson
martin.johansson@metrical.se

Ersätt krav med hypotestestning

Krav beskriver en egenskap eller funktion som en användare behöver för att åstadkomma något specifikt och är ett vanligt sätt att beskriva företagets och projektets mål. Det är ett angreppssätt som kan verka logiskt eftersom man på förhand försöker beskriva vad som ska uppnås. För vem kan arbeta mot något som är okänt? I den här artikeln ska jag redogöra för ett konkurrerande (bättre) angreppssätt där man faktiskt erkänner att de flesta mål, dvs krav, är okända. Metoden kallas för hypotestestning och har sin grund i forskningsvärlden.

En hypotes är är något vi tror (och hoppas) ska stämma, men som vi ännu inte har bevisat är sant.

"Vi tror att att kunder kommer att registrera sig på vår nya spelsajt om vi erbjuder nya spelare 100 kr att spela för"

En hypotes måste också vara testbar:

“Vi vet att vårt antagande är korrekt när tusen nya spelare har registrerat sig inom en vecka”

Hypotestestning handlar i huvudsak om två saker; att ställa de frågor som man är intresserad av att få bekräftade och att hitta på sätt att bekräfta dem. En fördel med att använda hypotestestning i stället för krav är att man “tvingar” hela teamet till samarbete och kollaboration. När man ger ett team ett problem att lösa, till skillnad från en redan uttänkt lösning i vilken man har låst fast sig i, så engageras teamets kreativa sida.

Att specificera krav är egentligen att formulera hypoteser men där man på förhand betraktar dem som sanna utan bevisföring. I de projekt där man är helt säker på vad man håller på med, vilket problem som ska lösas och hur det ska lösas, fungerar krav bra. Men i hur många projekt som du har jobbat i har man varit helt säker på vad man håller på med?

De flesta mjuvaruprojekt lever under extrem ovisshet, dvs man är inte bara osäker på lösningen utan man är lika osäker på vilket problem som ska lösas. I den typen av projekt är hypoteser bättre än krav. 

Hypoteser är svar formulerade som frågor och är per definition testbara. Genom att söka svar på frågor lär man sig sådant man annars inte skulle ha vetskap om. Låt oss definiera en enkel process för hypotestestning:

  1. Identifiera dina antaganden
  2. Formulera antagandena som hypoteser
  3. Prioritera de antaganden som bär störst risk utifrån en affärssynvinkel
  4. Bryt ner hypoteserna i testbara delar
  5. Bygg den minsta möjliga mjukvara som kan testa och bekräfta hypotesen
  6. Är den bekräftad, gå vidare med nästa hypotes. Om inte, justera antagandet, hypotesen och upprepa eller inse att det var en dålig idé från början.

 Framsteg ska inte mätas utifrån om mjukvaran fungerar eller ej, utan vad man har lärt sig om vad dess användare vill ha. Till syvende och sist kommer marknaden att återkoppla och avgöra dess öde. Den enda frågan är hur lång tid det kommer att ta innan återkopplingen sker och hur mycket pengar som har spenderats innan det sker.

En förutsättning för hypotestestning är att man jobbar med frekvent och kontinuerlig produktionssättning, vad vi vanligen kallar för Continuous Delivery. Med en releasestrategi som hela tiden pumpar ut nya förändrade och förbättrade versioner kan man på ett strukturerat sätt "zooma in" på problem och lösning på samma gång.

Mats Wessberg
mats.wessberg@metrical.se

Testdrivet arbete - en förutsättning för Continuous Delivery

En av de tekniker som jag anser vara absolut nödvändig att behärska för att lyckas med Continuous Delivery är att arbeta testdrivet. Beroende på vilken nivå testerna skrivs så bidrar de på olika sätt. De nivåer som man brukar tala om är enhetstestnivå, komponenttestnivå och acceptanstestnivå. I den här artikeln kommer jag främst att inrikta mig på accpetanstestnivån, även om delar av argumenten kan appliceras på de andra nivåerna.

Continuous Delivery

Continuous Delivery är något som konstant ökat i popularitet de senaste åren och har blivit ett etablerat begrepp när Jez Humble och David Farley publicerade boken Continuous Delivery. I takt med att fördelarna blir kända ökar även nyfikenheten att som organisation själv implementera Continuous Delivery. Det är förståeligt då Continuous Delivery,  om införandet är utfört på ett bra sätt, kan öka produktiviteten markant, samtidigt som ledtiden att få ut ny funktionalitet minskar och kvaliteten på det arbete som produceras hålls på en hög nivå. Självklart att Continuous Delivery blir intressant när det erbjuder sådana fördelar!

Acceptanstestdrivet arbete

Specification by Example, Behaviour Driven Development (BDD) och Acceptance Test Driven Development (ATDD), försöker alla beskriva ett arbetssätt där ett systems beteende specificeras på ett visst format i syfte att kunna användas som både dokumentation och exekverbara test. Det är viktigt att lejonparten av specifikationerna skrivs innan den nya funktionaliteten börjar utvecklas då det bidrar till att lyckas med Continuous Delivery

Det ovärdeliga bidraget som testdrivet arbete ger till Continuous Delivery  har flera fördeler.

  • Den samlade massan av exekverbara specifikationer fungerar som en regressionstestsvit vilket gör att vi utan nervositet kan produktionssätta nya funktioner snabbare.
  • För att kunna använda specifikationen som automatiskt test måste den vara tydlig vilket gör att vi lättare vet när vi är klara.
  • Eftersom de exekverbara specifikationerna skrivs innan funktionaliteten utvecklas är risken minimal att otestad kod existerar under någon längre tid.
  • De exekverbara specifikationerna dokumenterar systemets beteende och gör att vi lätt kan kommunicera hur systemet fungerar.

Fördelarna som finns att hämta från acceptanstestdrivet arbete är också förutsättningar för att lyckas med Continuous Delivery. För att fördelarna av acceptanstestdrivet arbete ska bli framträdande krävs diciplinerat arbete. Den samling tekniker och arbetssätt som ryms inom Continuous Delivery är just bara tekniker och arbetssätt.  För att lyckas med ett införande krävs det förutom de tekniska aspekten en stark kultur, processer som stödjer arbetet och kompetens.

Sammanfattning

När en organisation valt att börja arbete enligt Continuous Delivery är det viktigt att man arbetar testdrivet med automatiska acceptanstester. Om de automatiska acceptanstesterna inte är på plats innan ny funktionalitet utvecklas riskerar man att den är otestad under en tid. Uppenbara risker med detta är bland annat att felaktig funktionalitet hamnar i produktion, och att framtida förändringar tar sönder den otestade funktionaliteten. Samtidigt försvinner spårbarheten och pålitligheten som gör det möjligt att få de riktigt stora fördelarna med Continuous Delivery.  Risken är då stor att missa det stora målet med Continuous Delivery - alltså att leverera högkvalitativ mjukvara på ett reproducerbart sätt över tid.

Det är inte alltid enkelt - som tur är finns det mönster att använda som ökar chansen att lyckas. Mer om det i en framtida artikel.

Martin Johansson
martin.johansson@metrical.se