Häromdagen deltog jag i ett möte i gruppen SNESCM i ämnet ”CMCM: Showstoppers for Continuous Delivery in Small-Scale Projects”. I det exjobb som studerat olika projekt framgick det att testningen var en akilleshäl för dessa projekt att genomföra Continuous Delivery. Trots Agila principer blev det lite vattenfallstänk avseende att det blev en release och releasetestning i slutet av projekten. En viktig punkt för diskussionerna blev därför automattestning.
En grundläggande frågeställning under mötet var hur en CM ansvarig kan hjälpa till med för att underlätta införande av Continuous Delivery. Det jag tror att CM ansvarig kan hjälpa till med är att tydliggöra trender genom att ha en bra kontroll på alla byggen, testerna av varje bygge osv. Det ger projekt underlag för sina beslut om bland annat hur de skall testa.
Vad jag som projektledare vill se är en överblick över hur testerna fungerar över tid förutom förstås hur det senaste bygget fungerar. Då är det viktigt att projektet har ordning och reda på vad som byggts, förändringar i varje bygge samt vilka tester som körts, resultat av dem och vilka tester som inte körts samt kanske viktigast, hur har det gått i förhållande till tidigare resultat.
Ovanstående ger underlag för beslut om det andra ämnet vi pratade om under mötet, vilka tester skall automatiseras? Jag tycker att pyramiden med bas av unit tester, mellannivå av integrationstester och en topp av GUI tester ger en bra bild av hur man skall tänka. Detta synsätt i kombination med att man automatiserar det som är stabilt, vad det nu innebär, av GUI testerna ger bäst effektivitet. Att försöka automatisera GUI testerna i en instabil produkt, där instabil kan betyda, dålig kvalitet i varje enhet eller att kraven ändras frekvent, som i Agile utveckling, är fruktlöst och kostsamt och i stället bör man vänta med att automatisera GUI testerna till senare. Under intensiva utvecklingsperioder är det nödvändigt att göra manuella GUI tester, inte bara pga att man förändrar GUI:et hela tiden och automattesterna blir omöjliga att hålla ajour, utan också för att automattesterna bara kör det som man verkligen tänkt på och inte alla andra fall. Automattesterna kör ju samma sak varje gång och hindrar regression men ser inga nytillkomna problem som kan uppstå. Då rekommenderar jag exploratory testning i stället. Släng in 20-30 testare när en feature är klar och låt de leta efter alla handa konstigheter i de nya features som skapats.
Efterhand som kunden är nöjd med en viss feature kan man sedan välja att lägga in en regressionstest genom GUI-testautomation men fortfarande bör man komplettera med manuella tester som utförs som exploratory testning. Har man kritiska funktioner som betallösningar etc bör man också ha ett antal test scenarior som alltid körs igenom manuellt för att säkra kvaliteten. Detta eftersom integration med andra system förstås kan fallerar även om en egen produkt inte ändrats. Jag hittade en annan artikel i ämnet.
Kör ni Continuous Delivery fullt ut så har ni många releaser per vecka och att ha tillräckligt många testare för att genomföra kvalitetssäkringen kan var kostsamt. Men det finns alternativa lösningar på det. Hör av er till mig så kan jag berätta mer om mina erfarenheter av Community Testing och hur det skall integreras med er Coninuous Delivery process.