Sammanfattning
I tabell 5.1 presenteras en överblick över observationerna, vilken teori de är relaterade till och vilken slutsats som drogs till följd.
Tabell 5.1: Överblick av observationer, relaterad teori och dragen slutsats.
Observation Teori Slutsats
2: Ad-hoc testning Låg mognad i
testprocessen. [6, 16, 36]
Använde en modell för testförbättring.
8: Strukturer och riktlinjer
4: Upplevd tidsbrist Detta är faktorer som pekar på att traditionella
förbättringsmetoder är för resursintensiva. [20, 31, 40]
Använde MTPF som grundmodell, men anpassade efter behov. 9: Små team
10: Anpassning efter före- taget
1: Manuell testning Flera metoder för testning ger bättre resultat [28]
För att diversifiera test- strategin användes enhets- och end-to-end-tester. 11: Kund ansvarar för ac-
ceptanstesting
Automatiserad
acceptanstestning ger flera fördelar [21].
Trots fördelar prioriteras acceptanstester bort på grund av tidsbrist. 4: Upplevd tidsbrist
7: Varierande erfarenheter
Brist på kunskap kring verk- tygen är en utmaning vid automatisering. [43]
Använde verktyg som utvecklarna redan var bekanta med.
6: Utbrett stöd för testning Att automatisera tidigt i projektet ökar det medförda värdet [56]
Fokus lades på att komma igång med automatiserad testning från start. 10: Anpassning efter före-
taget
4: Upplevd tidsbrist kring testning
En testsvit som inte används ofta blir inkonsekvent och svårförståelig [5]
Vid en pull-request måste testerna köras av en byggserver. Föråldrade tester måste uppdateras. 6: Utbrett stöd för testning
på avdelningen
5.3
Fas 3 - Implementation och observation av förbättringsåtgärder
Implementationen skedde i ett projekt som fungerade som ett pilotprojekt innan testpro- cessen började användas av hela avdelningen. Arbetet startade strax efter att fas 2 var färdig och förändringarna kunde därför implementeras från start. Denna studie pågick under pro- jektets fyra initiala sprintar, där varje sprint omfattade 2 veckor. Under de tre första sprint- arna bestod utvecklingsteamet av två personer. En tredje utvecklare involverades under den fjärde sprinten.
Projektets start
Planen var att från start introducera alla åtgärder som som tagits fram i fas 2. Det visade sig dock tidigt under sprint 1 att detta inte var rimligt. Det största problemet var att få test- miljön att fungera som tänkt. Trots att projektet hade startat var det nedprioriterat. De två utvecklare som var tilldelade projektet lade cirka 40 % av sin arbetstid på det. Den första
5.3. Fas 3 - Implementation och observation av förbättringsåtgärder
sprinten var alltså drabbat av tidsbrist och fokus lades mest på att bygga upp grundstruk- turen för applikationen. Detta gjorde att hela testprocessen inte kunde anammas direkt utan vissa prioriteringar behövde göras. Fokus lades på följande:
• Att skapa en fungerande testmiljö för enhetstester. • Att tidigt komma igång med skrivandet av enhetstester.
• Att få igång en fungerade byggserver och integrera denna i utvecklingsflödet. • Att göra kodinspektioner vid pull-requests.
Projekets utveckling
Nedan presenteras det arbetet som gjordes inom de fyra MTPF kategorierna och hur arbets- flödet samt vad som noterades under utvärderingsmötet.
Testplanering
Under den första sprinten fanns det en preliminär teststrategi baserat på resultatet från fas 2. Den beskrev målen med testningsarbetet, vilka typer av tester som skulle genomföras, vilka komponenter som skulle testas, vilka verktyg som skulle användas samt hur arbetsflödet skulle se ut. Den saknade dock mer specifika riktlinjer och råd för hur själva skrivandet av testerna skulle göras. Istället fanns det exempeltester att kolla på, och vi fanns tillgängliga för att hjälpa till om problem uppstod. Under projektets gång utvecklades teststrategin vi- dare för att inkludera mer specifika riktlinjer och råd samt en checklista för hur man skriver enhetstester. Tanken är att denna ska ligga till grund för och vägleda testningsarbetet även i kommande projekt.
I fas 2 bestämdes att det under sprintplaneringen även skulle genomföras en testplanering vars syfte var att välja ut user-stories som ansågs vara kritiska. Dessa user-stories skulle täckas av end-to-end-tester. Det visade sig att när projeket startade att utvecklarna inte kände att de hade tid till att sätta sig in i och att börja med end-to-end-testerna. Som en följd av detta blev inte heller testplaneringen av.
Testadministation
Kategorin testadministration inkluderade tre delar som var nya för Webb & Mobilts test- process: enhetstester, end-to-end-tester och byggservern.
Enhetstester
Som deltagande observatörer var vi delaktiga i att få igång testmiljön. För enhetstesterna in- nebar detta att göra nödvändiga åtgärder för att få Karma och Jasmine att fungera i projektet. Detta var färdigt redan vid projektets start vilket gav utvecklarna möjligheten att fokusera på att skriva enhetstesten. En av utvecklarna hade tidigare erfarenhet av att jobba med mjuk- varutestning, medan den andra beskrev sin egen erfarenhet som begränsad. Trots denna variation i kunskap noterades det inga problem med att komma igång med skrivandet av enhetstesterna.
I och med uppsättningen av testmiljön inkluderades även exempel på hur enhetstester kunde skrivas för effekter och reducers. Detta verkar ha underlättat skrivandet. Arbetet på sviten med enhetstester påbörjades redan från dag ett och fortsatte under alla fyra sprintar. Den initiala inriktningen på att bara skriva enhetstester för effekter och reducers behölls under alla fyra sprintar.
5.3. Fas 3 - Implementation och observation av förbättringsåtgärder
End-to-end-tester
Protractor användes för att köra och skriva end-to-end-tester. Uppsättningen av Protractor i utvecklingsmiljön var inte färdig vid projektets start utan förutsättningarna för att skriva end-to-end-tester var på plats först en vecka in på den första sprinten. Utvecklarna ansåg sig dock inte ha tid att skapa end-to-end-tester. Förutom ett test för att se att inloggningen fungerade gjordes inga end-to-end-tester.
Byggserver
För versionshantering använder Exsitec sig av en källkodskatalog (eng. repository) för Git som ligger hos Visual Studio Team Services4(VSTS). Byggservern behövde alltså vara kom- patibel med VSTS och eftersom Exsitec uttryckte en motvilja till att underhålla en egen server användes VSTS:s "hosted agent"-lösning5. Detta är byggservrar som underhålls av Microsoft. De medförde dock vissa restriktioner vilket gjorde att end-to-end-testerna inte kunde köras på byggservern.
Att konfigurera byggservern att köra testerna och att integrera den i ett continuous integra- tionflöde medförde vissa tekniska problem, vilket gjorde att det tog hela första sprinten att få den att fungera. När byggservern väl var på plats kördes den vid varje pull-request som tänkt och sattes upp för att köra hela testsviten då pull-request skapades. På så sätt kunde den andra utvecklaren, som skulle godkänna detta pull-request, se resultatet av testerna tydligt kopplade till kodändringarna som gjorts. Då testsviten kördes genererades en testrapport, se figur 5.4, som visade hur många tester som passerat, hur lång tid det tog med mera.
Figur 5.4: Testrapport i VSTS
Verifiering och godkännande
Under denna kategori fanns två delar: checklistor och kodinspektioner. Först skulle check- listor användas vid skrivandet av enhetstester. Dessa fanns inte klara under den första sprinten utan togs fram under projektets gång. Under den första sprinten fick utvecklarna istället stöd genom att ha exempeltester att basera sig egna tester på. Den andra delen var kodinspektioner. Dessa tog fart redan från början i projektet.
Användandet av kodinspektionerna skedde dock bara till och från. Medan det endast var två utvecklare som jobbade på projektet uppstod problem när de inte jobbade samtidigt. Utveck- larna godkände vid flera tillfällen sina egna pull-requests då den andra utvecklaren inte fanns tillgänglig. Alternativet hade varit att behöva vänta upp emot en dag med att få in förän- dringarna på development-branchen.
4https://www.visualstudio.com/team-services/
5.3. Fas 3 - Implementation och observation av förbättringsåtgärder
Roller och organisation
Denna kategori var väldigt simpel och bestod endast av att utse en ansvarig person för att testplanen skapas vid varje sprint. Prioriteringen av user-stories och skrivandet av end-to- end-tester var dock en del som de två utvecklarna inte ansågs sig ha tid att göra i denna fas av projektet så att utse en ansvarig för detta var inte relevant.
Arbetsflöde
I fas 2 tog arbetsflödet som det var tänkt att fungera fram och presenterades i figur 5.3. Vid den implementationen skedde dock vissa förändringar. Som nämnt i tidigare delar blev det inget planeringsarbete där user-stories prioriterades och som en följd skrev det inte heller några end-to-end-tester. De momenten försvann alltså helt ur arbetsflödet. Vad det gäller kodinspektionerna skedde de inte vid pull-requests då en annan utvecklare inte var tillgänglig. Detta finns nu representerat i arbetsflödet genom en streckad alternativ väg genom flödess- chemat. Figur 5.5 representerar arbetsflödet som det faktiskt såg ut under slutet att studien.
Utvärdering
I samband med varje sprintmöte hölls ett utvärderingsmöte. Syftet med detta var att utvärdera de förändringar som införts och överväga vad som kunde förbättras eller utveck- las.
Efter den första sprinten låg fokus på att komma igång med byggservern som då hunnit konfigureras. Utvecklarna var nöjda med testningen och uppgav att det inte funnits några större tekniska svårigheter. De sa att "testningen hittills har legat på rätt nivå och inte varit för tung att genomföra". Det som var svårast var att vänja sig vid var att lägga tid på testning. De hade dock inte observerat några direkta fördelar med testerna och ansåg att det antagligen var för tidigt i projektet för att testsviten ska vara användbar i en större utsträckning. De bekräftade att de inte hunnit sätta sig in i end-to-end-testningen. Framöver uttryckte de åsikten att skrivandet av end-to-end-tester bör begränsas till ett fåtal tester.
Efter den andra sprinten hade utvecklarna fått lite mer vana med att inkludera testning i arbetet. Byggservern var nu helt integrerad i arbetsflödet och testerna kördes vid varje pull- request. Utvecklarna uttryckte att de var mycket nöjda med byggservern, den "underlättar jobbet för den som ska granska koden" enligt en av utvecklarna. Möjliga förbättringar av pro- cessen diskuterades. Det konstaterades att någon form av testning av Angular-komponenter vore bra, men utvecklarna kände att de ville bli bekvämare med den testning som gjordes än så länge innan fler delar lades till i processen. Därför beslutades att fortsätta som förra sprinten ytterligare en sprint och sedan överväga förbättringar inför sprinten därefter. Några dagar efter detta möte visade det sig att projektet blivit ytterligare nedprioriterat. Den mest erfarne utvecklaren behövdes i ett annat projekt som närmade sig deadline och även den mindre erfarne utvecklaren hade mindre tid att lägga på detta projekt. Detta resulterade i att utvecklingen saktade ned.
Under den tredje sprinten skedde utvecklingen i mycket låg takt. Detta gjorde att samma beslut som vid förra mötet togs: fortsätt som hittills och vänta med att lägga till delar i testnin- gen tills utvecklarna hunnit lägga mer tid på projektet och blivit bekvämare med processen. Under den fjärde sprinten ökade arbetstakten då den mindre erfarne utvecklaren kunde lägga en större del av sin tid på projektet igen. Han jobbade dock ofta ensam på projektet. I utvärderingen efter denna sprint konstaterades att arbetsflödet inte var väl anpassat efter att bara vara en utvecklare. Kodinspektionen hoppades över och testerna kördes framförallt
5.4. Slututvärdering
Figur 5.5: Det faktiska arbetsflödet. Röda aktiviter är testrelaterade
lokalt eftersom byggservern inte alltid hann köra bygget när pull-requests godkändes direkt av utvecklaren som skapat det.
5.4
Slututvärdering
Efter att fyra sprintar genomförts hölls ett utvärderingsmöte som var mer omfattande än de regelbundna utvärderingarna som skett i samband med varje sprint. Nedan presenteras
5.4. Slututvärdering
resultatet från slututvärderingen indelat efter de olika MTPF-kategorierna samt arbetsflödet och uppnådda effekter.
MTPF - Testplanering
Utvecklarna var medvetna och missnöjda med att den återkommande testplaneringen som skulle ske vid varje sprintplaneringsmöte hade uteblivit. De var nöjda med att ha en test- strategi som gav en mer övergripande plan för hur testningen i projektet skulle ske, men såg behovet av att i framtiden planera mer testning löpande. Att i framtiden prioritera user-stories för end-to-end-tester, vilket var ett förslag från fas 2, togs upp som ett mål inför framtiden. För att se till att testerna skrivs föreslogs att testning av utvalda user-stories borde synliggöras mer i VSTS och inte bara i testplanen.
I övrigt diskuterades planering från ett tidsestimeringsperspektiv. Vid tidsplanering bör test- ningsarbetet finnas i åtanke. Det fanns inga önskemål om att planera och schemalägga tid som är dedikerad till testning, istället ska testning ses som en naturlig del av utvecklingen.
MTPF - Testadministration
Utvecklarna upplevde att det var lätt att arbeta med de verktyg som ingick i testmiljön, och när väl byggservern var uppsatt behövde den ingen ytterligare administration. De nämnde dock att de sannolikt behöver bli mer insatta i hur testverktygen fungerar i framtiden för att kunna hantera eventuella förändringar i testningen.
Manuell testning fortsatte vara viktigt för de visuella aspekterna av applikationen. Ingen av utvecklarna trodde att automatiserad testning kan komma att ersätta manuell testning helt, utan ser dem som två metoder som kompletterar varandra.
Enhetstester
Utvecklarna konstaterade att det inte hade varit några problem att komma igång med skri- vandet av enhetstester. I och med att testmiljön redan var på plats var det bara att börja skriva. En utvecklare uttryckte att han hade förväntat sig att tröskeln för att komma igång med verktygen skulle vara större. Dock var den samlade uppfattningen att de alla hade en del kvar att lära sig för att bli riktigt duktiga.
Utvecklarna i projektet uppgav att de kände att det gick snabbt att skriva enhetstesterna. De upplevde att många effekter och reducers höll en liknande struktur mellan varandra vilket gjorde det lätt att skriva tester eftersom även testerna blev väldigt lika varandra. Detta bidrog till att enhetstesterna alltid blev skrivna då de inte krävde så stor ansträngning i det dagliga arbetet.
Testsviten har använts vid jämna mellanrum under utvecklingen och inte bara vid pull- requests. Vid den fjärde sprintens slut hade det endast vid några få tillfällen uppstått behov av att underhålla och uppdatera tester. Detta upplevdes då inte som ett problem.
I huvudsak upplevde utvecklarna att testen fyllde en funktion och var värdefulla. Eftersom projektet fortfarande var i en tidig fas kände de dock att många av fördelarna sannolikt kom- mer visa sig i senare skeden, då testsviten byggts upp ordentligt. De konstaterade dock att vissa effekter är väldigt simpla, de hämtar data och skickar den vidare utan att behandla den något. De förväntar sig inte att få så mycket värde från de testen. Som ett resultat av detta överväger de att i framtiden skapa en "tröskel" för vilka effekter som är värda att testa, till exempel baserat på antal rader kod.
5.4. Slututvärdering
End-to-end-tester
Av framtida förbättringar av testprocessen sågs end-to-end-tester som en av de viktigaste. De hanns inte med under projektets start på grund av att utvecklingsteamet var litet och att fokus låg på att komma igång med de mer grundläggande delarna av testningen. Nu när testningen kommit igång ses end-to-end-tester som nästa naturliga steg i att diversifiera testmetoderna.
Vid ett kommande införande av end-to-end-testning är målet att hålla dem lättviktiga. Syftet ska inte vara att testa alla gränsfall utan att ge en trygghet i att ändringar inte har förstört gränssnittet. Ett problem som noterades under denna studie var att end-to-end-tester i pro- tractor inte kan köras på VSTS hosted agent-lösning. För att lösa detta och göra end-to-end- testerna en del i Exsitecs continuous integration pipeline, ska lösningar som att tillhandahålla en egen byggserver eller att använda Microsoft Azure:s molnlösning undersökas.
Byggserver
Jämfört med de utvärderingar som gjordes under studiens gång var det inga nya åsikter som uttrycktes under slututvärderingen. Utvecklarna var fortsatt positiva till användandet av byggservern och ansåg att det var ett bra verktyg för att göra en första kontroll innan kodinspektioner genomfördes på pull-requests.
Som det nämndes i ovanstående avsnitt så är utvecklarna intresserade av att utvidga bygg- serverns uppgifter till att även köra end-to-end-tester. Detta kan innebära att Exsitec slutar använda VSTS hosted agent till att istället underhålla en egen byggserver eller använda sig av en annan molnlösning som stödjer protractortester.
MTPF - Verifiering och godkännande
Vid utvärderingsmötet ställde sig utvecklarna positiva till att både kodinspektioner och checklistor för enhetstester bör vara del av testningsarbetet framöver. Checklistor bör finnas inte bara för reducers och effekter utan även för smarta komponenter.
Utvecklarna uppfattade det som att man i viss mån misslyckats med kodinspektionerna. De användes väldigt sporadiskt och var inte en fast del av arbetsprocessen. De uttryckte dock att problemet inte låg i hur arbetet med kodinspektionerna var upplagt utan i den tidiga fas som projektet befann sig i. De upplevde inte att kodinspektionerna passade bra i den tidsbegränsade miljö som rådde, särskilt inte vid de tillfällen då endast en utvecklare jobbade på projektet i taget. Men utifrån det arbetet som faktiskt skedde noterades vissa positiva effekter. De är ett bra sätt att hänga med i vilka förändring som skett i kodbasen och det fungerar som ett stöd för nya oerfarna utvecklare samt personer som jobbar på distans. Inför framtiden, när projektteamet växt, anser utvecklarna att kodinspektionernas roll kom- mer vara mer betydelsefull. Det är då viktigt att dessa blir en del av arbetsdagen så att det inte blir för långa fördröjningar innan nya kod läggs in i development-branchen.
MTPF - Roller och organisation
Det fanns endast en ansvarroll definierad för projektet och den innebar att man inför varje sprint skulle skapa en testplan som innehöll de user-stories som bedömts som mest kritiska. Extra fokus skulle läggas på att testa dessa user-stories genom att skriva end-to-end-tester. Eftersom arbetet med end-to-end-tester inte tog fart under studien var det därför inte heller någon som tog sig tid att göra några testplaner.
5.4. Slututvärdering
När ansvarfördelningen under utvärderingsmötet diskuterades konstaterade utvecklarna att det i princip inte har funnits någon. Angående vilka ansvarsroller som bör finnas i framtiden uttryckte de att Exsitec i allmänhet är "dåliga" på den typen av strukturer. Istället vill man förespråka "frihet under ansvar". I framtidens testningsarbete skulle detta innebära att det är teamet tillsammans som måste se till att testplaner skapas och att det är upp till var och en att ta sig tid och utföra kodinspektioner.
MTPF - Problem- och erfarenhetsrapportering
Vid fas 2 beslutades det att MTPF-kategorin Problem- och erfarenhetsrapportering skulle väl- jas bort eftersom det inte ansågs nödvändigt att standardisera rapporteringen i ett team med bara två medlemmar. Vid utvärderingen konstaterades det att utvecklarna inte stött på några situationer där kommunikationen brustit på ett sätt som hade kunnat undvikas med hjälp av sådan standardisering.
Utvecklarna uttryckte dock att ett rapporteringsverktyg borde användas när projektet växer och att andra projekt inom företaget använder sig av "åtgärdslistor" där alla kända problem listas. Det finns stöd i VSTS, som redan används i projektet, för denna typ av problemrap-