Automatisering i agila sammanhang

2009-08-14 Artikelbanken Test Läst 6308 gånger

Allt fler företag använder sig av agila utvecklingsmodeller både vid nyutveckling och vid förvaltning och de hamnar snart i samma situation. Mängden regressionstester ökar kontinuerligt och är snabbt större än andelen tester kopplat till nyutveckling. Man har dessutom ofta ett behov av att göra dagliga byggen vilket ökar behovet av att köra regressionstestsviterna väldigt ofta. Lösningen på detta problem är sannolikt att automatisera en större del av testerna.

Om dagliga byggen används kommer regressionstester att köras dagligen och för varje ny iteration kommer andelen regressionstester öka från den föregående iterationen. Om utvecklingstiden inom varje iteration är lika stor kommer andelen nyutvecklad kod av total mängd kod sjunka till ca 10% av den totala kodmassan i den tionde iterationen, men redan i den andra iterationen är den nyutvecklade delen nere i ca 50% av den totala kodmassan.

Skall en projektmedlem ha någon möjlighet att arbeta med den nyutveckling som skall ske inom sprinten kommer en stor del av de regressionstester som körs behöva vara automatiserade eftersom all tid annars kommer att gå till manuell testning av ”gammal” funktionalitet. Vi vill självklart att de manuella testerna fokuserar på de funktioner som har förändrats eller nyutvecklats.

Automatisering i större agila utvecklingsprojekt eller i agil förvaltning

I alla större agila projekt levereras mer och mer funktionalitet över flera olika iterationer, men ofta också från flera olika parallella team. Att inom varje team och iteration arbeta med automatiserade tester är enkelt och kan göras på flera olika sätt, exempelvis testdriven utveckling (TDD) eller modellbaserad test (MBT). Dessa kan teamet själv sedan bygga på för varje iteration för att klara av ”continious integration”.

Att teamen fokuserar på sin iteration och de föregående iterationer som teamet har haft medför dock inte direkt att alla teams iterationer säkerställs tillsammans, så när fler team arbetar parallellt behöver ytterligare steg tas om hand för att säkerställa att systemtest kan göras och med så små ytterligare insatser som möjligt eftersom vi fortsatt vill ha den huvudsakliga manuella insatsen fokuserad på det som är nyutvecklade funktioner i den senaste (och kommande iterationen).

Ett enkelt sätt att hantera det är att de olika utvecklingsteamen överlämnar delar av sina komponenttester till ett team som fokuserar på systemtester. Teamet kan likställas med kunden och det som levereras dit skall ha genomgått samma tydliga Klar-definitioner som vid direkt leverans till kund. Det är dessutom självklart möjligt att systemet också levereras till den riktiga kunden från systemtestteamet.
Systemtestteamet kombinerar ihop de olika testerna till sammanhang som betyder något systemmässigt. Vartefter ytterligare iterationer lägger till ny och/eller förändrar redan levererad funktionalitet så justerar teamet systemtesterna utgående från de nya komponenttester som levereras från utvecklingsteamen. Utvecklingsteamen kan då fortsatt fokusera på iterationen och komponentens testning men systemsammanhanget tas om hand ändå.

För att säkerställa att inte ett team i en iteration inte spräcker bygget helt kan systemtesten från föregående iteration användas för att säkerställa att systemet fortsatt håller samman. Detta medför att systemtest blir något som pcågår hela tiden i stället för i slutet av systembygget eller iterationen och kalender-tiden kan då ändå hållas inom en kort iteration.

Skillnaden mellan helt nya projekt som arbetar agilt och förvaltningsarbete som bedrivs agilt blir i huvudsak vad som är basen för de första automatiserade testerna. I ett helt nytt projekt kommer basen från utvecklingsteamens komponenttester och i förvaltningsarbete måste vi ta basen från något annat håll med högsta sannolikhet.

När ett större system redan existerar och man skall påbörja en vidareutveckling i ett antal steg, kan det enklaste sättet vara att automatisera systemets huvudflöden som verifieras vid acceptanstest. Att i efterhand försöka automatisera alla tester för att få full kodtäckning är inte realistiskt utan skulle bli väldigt kostsamt. Däremot kan det vara möjligt att automatisera de regressionstester man har identifierat på en högre testnivå vilket exempelvis kan göras via ett inspelningsverktyg.
De inspelade regressionstesterna kombineras sedan med de tester som utvecklingsteamen levererar till systemtestteamet som kan anpassa de inspelade regressionstesterna att inkludera de nya testerna så att hela systemet återigen testas.

Continuous Integration för att lyckas med agila projekt

Continuous Integration, CI, är ett snabbt växande begrepp inom de agila arbetsmetoderna. Att automatisera sin integration är ett måste i dagens snabba utvecklingsprojekt.
Vad ingår då i det som kallas CI?

  • Bygga koden, Builds
  • Installera koden på körbar test/produktionsmiljö, Deploy
  • Testa applikationen på olika nivåer, Test
  • Rapportera innehåll och resultat, Reporting

Dagliga byggen är det första man tar sig an när man vill börja arbeta med CI. En förutsättning är att man har ett verktyg för konfigurationshantering av koden, source control. Till detta bör man även ha gemensamma regler för hur man arbetar i detta verktyg. För att bygga koden finns det byggskript och en särskild server där alla byggen sker, en byggserver.

När koden är byggd finns även möjlighet att installera den körbara applikationen i en testmiljö med automatik. På längre sikt kan man även ha rutiner för att installera applikationen i produktionsmiljön. I samband med installation kan även installationstester köras med automatik.

Mycket utav testaktiviteterna kan automatiseras i samband med CI. Det vanliga är att man har automatiska enhetstester, kanske tillsammans med mätning av kodtäckning. Ett område där man kan tjäna många timmar är att automatisera regressionstester. Dessa regressionstester körs om och om igen i ett projekt därmed finns det stora vinster att redan ifrån start se till att man designar testfall på ett sätt som möjliggör automatisering.

Rapportering är ett område som man kanske inte tänker på i första taget när man skall ge sig på CI. Speciellt i stora projekt med många agila team som skall leverera mot samma slutkund ger det stora vinster att automatisera rapportgenerering samt spridningen/åskådliggörande av detta. Via rapporter kan man visualisera vilka koddelar som påverkas utav olika team, i vilka byggen de finns med samt resultat av tester.

Det finns olika grader av mognad i dessa fyra delar av CI. Man bör först och främst fokusera på vilket/vilka områden man vill börja inom. Sedan som ett andra steg sätta ribban inom vart och ett utav dessa. Tänk dock på att det finns stora delar där dessa områden samverka på olika sätt, det ger större vinst att se till att dessa områden satsas på samtidigt. Vill man ha automatisk installation i testmiljö kan det vara på plats att satsa på ett automatiserat installations test samtidigt.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln