Ibland kan det hända att ett team som vill anamma agil testning börjar fundera på hur man förbättrar kvalitén på en produkt så tidigt som möjligt och startar med att lista testtyper som de vill införa men fastnar sedan i en osäkerhet på var de olika aktiviteterna ska ske. Jag har själv fått frågan när någon vill börja med systemtester, end to end-tester eller liknande men det är oklart var i processen de passar in. I vissa fall finns det klara svar men i andra så beror det på de kringliggande processerna och hur övrig testning sker. Det som är en väl fungerande lösning i en organisation kanske inte alls passar i en annan.
För ett litet tag sedan diskuterade vi till exempel när enhetstester skulle skrivas och köras för att ta fram en gemensam definition för hela utvecklingsavdelningen. Vi var alla överens om att det inte var en bra idé att öppna upp existerande fungerande kod bara för att lägga till enhetstester. Istället ska det ske när det skrivs nya funktioner, vid refaktorering och vid bugfixar. På så sätt bygger man ut täckningsgraden på ett naturligt sätt. När frågan om när testerna ska köras kom upp var det några som med övertygelse sa att alla enhetstester skulle köras och passera på utvecklarens dator innan koden fick gå vidare. Några andra tyckte dock att det var ett helt onödigt steg då de kommit längre på sin continuous-resa och kör sina enhetstester i byggpipelinen och har spärrar som inte släpper igenom ändringar med fallerande tester. Den enkla lösningen var att definitionen nu säger att ingen ny kod får slås ihop med existerande kod om enhetstesterna fallerar så får teamen bestämma var det sker, utifrån sina tekniska möjligheter.
Det här belyser dock att det aldrig är så enkelt att en lösning alltid fungerar, inte ens inom samma organisation. När det är fler olika testtyper som ska planeras in ökar givetvis komplexiteten och det kan vara bra att försöka förenkla det jobbet genom att visualisera de olika alternativen.
Börja modellera
En bra start är att rita upp hur miljöerna ser ut för utveckling och distribution. Följande schematiska bild är ett exempel på en inte helt ovanlig uppsättning. Det räcker dock bra med att rita på en tavla eller liknande.
- Lista de olika test- och kvalitetstyperna som är aktuella. Viktigt är att även få med olika typer av kvalitetshöjande åtgärder och inte bara testning.
- Diskutera vad de olika innebär, om de är aktuella för er och var de i så fall hör hemma.
- Skriv ner dem på tavlan och dra streck till där de hör hemma, eller sätt upp post-it lappar på miljöskissen.
Kanske kommer ni fram till att ni vill införa kodgranskning, enhetstester som ska gå i CI-bygget, någon typ av smoke-test, regressionstest, prestandatest, funktionstest, systemintegrationstest, UAT, monitorering och om möjligt ett sätt att testa produkten i produktion men gömt för användarna. Allt det här blir mycket lättare att planera om det visualiseras och inte bara finns i långa dokument eller en text-tyngd wiki-artikel. Efter en sådan övning skulle det kunna se ut något så här:
Finputsa modellen
När väl den grova planeringen är klar kan man gå vidare till nästa del och visa hur en release-kandidat färdas framåt och i vilken ordning de olika initiativen kommer.
Rätt test på rätt plats gör att man hittar grova fel snabbt. För varje steg ökar tiden för återkoppling men samtidigt minskar risken för allvarliga fel ju längre bort i kedjan man kommer. Notera att återkopplingen skall vara vägledande för om kandidaten skall gå vidare eller stoppas vid manuella steg. Vid automatiska steg går kandidaten vidare om alla tester är gröna. Med CI/CD kommer också behovet av en väl fungerande strategi för att rulla tillbaka och återställa.
Genom att visualisera strategin är det lättare för alla att förstå, vilket ger bättre diskussioner och mer korrekta beslut i frågan om vad som ska ingå och i vilken ordning jobbet ska göras.
Ladda ner vår guide med fler modeller
Vill du läsa mer om hur du kan visualisera din agila teststrategi så kan du ladda ner vår guide. I den tar jag även upp hur du skapar en visuell förklaringsmodell som beskriver var olika typer av kvalitetsåtgärder passar in i arbetet för att få alla att förstå att kvalitet bygger på så mycket mer än test. Dessutom tittar jag närmare på andra varianter för hur du skapar en modell där olika kvalitetsinitiativ kan plottas ut för att skapa en strategi för det fortsatta arbetet.
