Lars Linderoth, ansvarig för våra tjänster inom kvalitet och test, delar med sig av sina tankar och reflektioner vilka  centrala delar du behöver tänka på för att göra ert kvalitetsarbete framgångsrikt och effektivt. De agila organisationerna där många team samverkar kräver ”nya” sätt att se på bland annat kvalitetssäkring och test.

Allt fler av våra kunder går från att ha enstaka agila team till sammansvetsade agila organisationer där många team samverkar i gemensamma leveranser. Detta kräver nya sätt att se på kvalitetssäkring och test, förändrad infrastruktur och mer aktiv samplanering. Här nedan har jag sammanfattat fem centrala delar att jobba med för att göra kvalitetsarbetet framgångsrikt och effektivt.

1. Teamens tekniska inriktning

I organisationer med komplex systemkarta är det i stort sett omöjligt, eller i vart fall mycket ineffektivt, att skapa feature teams som kan verka i hela systemstacken. Det är därför generellt sett olämpligt att försöka skapa sådana team. Istället formas teamen kring den eller de tekniska plattformar där störst behov av agilitet finns, generellt sett är detta i och nära kundkanalen såsom i webbkanaler och i appar.

Med denna skärning återstår sedan valet huruvida teamen ska kunna verka i hela det utvalda systemområdet eller om de ska nischas. Det finns fördelar med båda alternativen, och varje organisation måste göra sina egna val. Sätter man flexibilitet i främsta rummet så bör teamen ha förmåga att verka i hela systemområdet, medan den som prioriterar ett högt genomsnittligt utvecklingstempo gör klokt i att ha något mer specialiserade team.

2. Kvalitetssäkra helheten

De agila teamen bör naturligtvis äga kvalitetsfrågan för den funktionalitet man implementerar, men det finns goda skäl att tydligt definiera till vilken nivå de gör detta. Säkerhetstest, storskalig prestandatestning, portabilitetstestning (test i olika browsers och i olika mobila enheter) och användbarhetstestning är exempel på aktiviteter som kan hanteras gemensamt och därmed bli betydligt effektivare än om de görs per feature eller user story. Det finns också alltid anledning att testa helheten ur ett användar- och kundperspektiv.

Den här typen av arbetsuppgifter kan läggas i ett specifikt team, i en supportfunktion eller rent av outsourcas. Säkerhetstest är en typisk tjänst som många helt eller delvis köper in från en extern leverantör. Men man kan också låta dessa specifika kvalitetssäkringsuppgifter ambulera mellan sina team, och helt enkelt hantera dem som specifika features/user stories.

3. Automatiserad test

Att automatisera repetitiv testning är en självklarhet för att kunna arbeta agilt. Detta gäller både funktionell och icke-funktionell testning. Det finns flera saker att vara medveten om och många fallgropar när det gäller automatisering. Verktygsval, hantering av testdata och de nya krav på testmiljöer som detta kräver är tre punkter som måste analyseras. Alla tre punkterna måste samspela för att automatiseringen ska ge det värde man eftersträvar.

Det är viktigt att förstå att testfall som körs automatiskt flera gånger om dagen också kräver stabila testmiljöer och automatisk hantering av testdata. I praktiken innebär det ofta att man antingen måste isolera de komponenter/system man testar och därigenom bygga bort testdataproblematiken, eller att man helt enkelt begränsar sin automatiska testning så att den inte konsumerar någon testdata. Verktygsval är också en viktig fråga och en tydlig rekommendation är att överväga att använda formella språk (t.ex. Gherkin) för att beskriva sina user stories och därmed göra dem exekverbara.

4. Automatiska byggen och automatisk leverans

CI/CD – Continuous Integration och Continuous Delivery, att hela bygg och deployprocessen inklusive exekvering av automatiska testfall är automatiserad, är viktigt att ha på plats redan när man jobbar med enstaka team. När många team samverkar är det en förutsättning för att kunna arbeta effektivt.

Hur detta ska sättas upp och konfigureras beror självklart helt på vilken teknisk miljö man befinner sig i. Målbilden bör vara att när en utvecklare comittar kod så görs automatiskt ett bygge, relevanta testfall körs innan deploy till en testmiljö där integrationstester körs. Vid eventuella fel så avbryts processen – detta säkerställer att man alltid har en integrerad och fungerande testmiljö.

5. Planera gemensamt och ha kontroll på beroenden

I de allra flesta fall så kommer teamen att ha både rent tekniska och mer organisatoriska beroenden. Det tidigare rör framför allt integrationer mellan tekniska komponenter som ändras av olika team, men kan också inkludera att olika team utvecklar ny funktionalitet i samma system. Det senare rör aktiviteter som ett team måste genomföra på grund av utveckling som något annat team gjort. Oavsett vilka beroenden man har så är samspelet mellan teamen viktigt.

I en miljö med flera agila team bör man ha gemensam sprintplanering, och i anslutning till den ha en separat slot för att klargöra beroenden mellan team. Dessa beroenden ska sedan monitoreras dagligen genom Scrum of Scrums eller motsvarande möte.

Till sist

Oavsett var man befinner sig i sin agila omställning är en central princip att Rom inte byggdes på en dag! Det tar år för en större organisation att ställa om sig till ett agilt arbetssätt, och varje individ kommer att behöva förändra sitt arbete och sin vardag. Uthållighet och förmåga att se möjligheter och goda exempel är avgörande för framgång.

/Lars Linderoth