Utvecklares upplevelse av övergång till testdriven utveckling

Utvecklares upplevelse av övergång till testdriven utveckling

Caroline Blomgren Rebecca Wallström

Data- och systemvetenskap, kandidat 2021

Luleå tekniska universitet Institutionen för system- och rymdteknik

Förord

Vi vill först och främst tacka deltagarna i vår studie och våra handledare på företaget, utan er hade inte denna studie varit möjlig. Vi vill också rikta ett stort tack till vår handledare på Luleå Tekniska Universitet, Anna Ståhlbröst, för all feedback och vägledning vi fått under arbetets gång. Vi vill även tacka Mari Runardotter som vägledde oss innan vi blev tilldelade Anna som handledare. Tack också till Svante Edzén, Elin Bergström, Jinshu Pan och Andreas Jonsson för värdefull feedback under seminarierna. Slutligen tack till David Granberg som kunde tänka sig att korrekturläsa vår rapport.

Sammanfattning

Syftet med vår studie har varit att utforska hur utvecklare upplever en övergång från iterativ test-sist- utveckling till testdriven utveckling. I studien refereras testdriven utveckling till som TDD, en förkortning som kommer av engelskans test-driven development. TDD är en iterativ och testfokuserad systemutvecklingsmetod. Den typ av testning som används i störst utsträck-ning inom TDD är enhetstester. För att gå över till ett nytt arbetssätt krävs inlärning av den nya metoden. En utmaning är också att människor tenderar att använda sig av kända metoder snarare än att prova något nytt. Vi har gjort en djupgående studie ur ett systemutvecklarperspektiv. Studien genomfördes genom att fyra utvecklare på ett IT- konsultföretag använde sig av TDD under en testperiod, i stället för den iterativa test-sist- utvecklingsmetod som de vanligtvis utövar. Före och efter testperioden intervjuades utvecklarna kring deras bakgrund, upplevelser och åsikter.

Utvecklarna upplevde att TDD fungerade bra för uppgifter där det passar med enhetstester, men att TDD skulle vara svårt att köra om uppgiften de skulle göra inte var väl specificerad eller hade otydligt specificerade krav. Vi upptäckte att hur bra utvecklare förstått något stämmer inte alltid överens med hur bra de tror att de förstått något. Samt att möjligheten att spara tid är en faktor som motiverar utvecklare till vilka metodval de gör. Utvecklarna upplevde att TDD gjorde att de tänkte igenom uppgiften mer innan de började koda och gjorde att de skrev mer enhetstest, vilket i sin tur genererade flera positiva bieffekter. Utvecklarna upplevde få negativa effekter. Majori- teten av utvecklarna upplevde att de flesta utmaningarna med övergång till TDD handlade om att byta vana och tankesätt. Övriga utmaningar utvecklarna upplevde handlade om att börja med TDD för ett befintligt system.

De slutsatser vi har kommit fram till stämmer överens med tidigare forskning på olika fält. Vår studie pekar därför på att allmänna teorier, exempelvis teori om olika lärstilar, förändringsled- ning och bildande av vanor även är applicerbart vid övergång till TDD. Utifrån våra slutsatser har vi formulerat rekommendationer till organisationer hur de kan underlätta för sina utvecklare som ska gå över till TDD.

Abstract

The goal of our study has been to explore how developers experience a transition from iterative test-last development to test-driven development. In this report, test-driven development is ref- erred to as TDD. TDD is an iterative and test-focused system development method. The type of testing most widely used in TDD is unit testing. To switch to a new working method requires learning the new method. A challenge faced is also that people tend to use known methods rather than try something new. We have done an in-depth study from a developer perspective. Four de- velopers at an IT consulting company got to use TDD during a test period, instead of the iterative test-last development method they usually practice. Before and after the test period, the develop- ers were interviewed about their background, experiences and opinions.

The developers felt that TDD worked well for tasks where unit tests were appropriate, but that TDD would be difficult to apply if the task they were to perform was not well specified or had unclear requirements. We discovered that how well developers understand something does not always match how well they think they understand something. We also discovered that the possi- bility to save time is a factor that motivates developers to which method choices they make. The developers felt that TDD made them think through the task more thoroughly before they started coding and that it made them write more unit tests, which in turn generated several positive side effects. The developers experienced few negative effects. The majority of the developers felt that most of the challenges with the transition to TDD concerned changing habits and mindset. Other challenges the developers experienced concerned starting with TDD for an existing system.

Our conclusions are consistent with previous research in various fields. Our study therefore indi- cates that general theories, such as theory of different learning styles, change management and habit formation, are also applicable in the transition to TDD. Based on our conclusions, we have formulated recommendations to organizations on how they can facilitate for their developers to transition to TDD.

Innehåll

1. Introduktion 6

1.1. Syfte och forskningsfrågor 8

1.2. Avgränsningar 8

2. Teori 9

2.1. Testning 9

2.2. Testdriven utveckling (TDD) 11

2.3. Införande av nytt arbetssätt 15

2.4. Införande av ny vana 16

2.5. Lärande och lärstilar 16

3. Fallbeskrivning 18

4. Metod 19

4.1. Urval 20

4.2. Utformning av intervjuer 20

4.3. Analys av intervjuer 21

4.4. Etiska överväganden 22

4.4.1. Vinstetik 22

4.4.2. Informerat samtycke 22

4.4.3. Konfidentialitetskravet 23

4.4.4. Korrekt återgivning 23

4.4.5. Uppdragsforskning 23

4.5. Metoddiskussion 23

4.5.1. Reliabilitet 24

4.5.2. Intern validitet 26

4.5.3. Extern validitet 26

5. Resultat & Analys 28

5.1. Utvecklarnas bakgrund 28

5.1.1. Erfarenheter inom systemutveckling 29

5.1.2. Syn på progress, test och TDD 30

5.1.3. Förutsättningar under testperioden 32

5.2. Upplevelser av övergång 33

5.2.1. Arbetssätt TDD under testperioden 35

5.2.2. Forskningsfråga 1: Upplevda effekter på kodande 38

5.2.3. Forskningsfråga 2: Utmaningar 39

5.3. Underlätta övergång 42

6. Diskussion 45

6.1. Slutsatser 48

7. Rekommendationer 50

Referenser 52

Bilaga 1: Informationsmaterial om TDD 57

Bilaga 2: Underlag för informerat samtycke 66

Bilaga 3: Inledande intervju 67

Bilaga 4: Avslutande intervju 71

Bilaga 5: Hjälp till analys av intervjumaterial 77

Bilaga 6: Schematisk representation över slutsatser och rekommendationer 78

1. Introduktion

För att vara en konkurrenskraftig organisation i en föränderlig omvärld, så måste organisationer kontinuerligt förändra hur de bedriver sin verksamhet för att nå sina mål. Att byta arbetssätt i en organisation är dock inget som sker av sig självt eller är helt lätt. Som svar på de utmaningarna har fältet förändringsledning uppkommit (change management på engelska). Förändringsledning är ett samlingsbegrepp för alla tillvägagångssätt för att förbereda, stödja och hjälpa individer, team och organisationer att göra organisatoriska förändringar. Det handlar om att hjälpa personer i en organisation att lägga sig till med nya vanor samt acceptera och äga förändringen snarare än att motstå den. För att öka chansen att få ett lyckat införande av ett nytt arbetssätt behöver dessa mänskliga förändrings dynamiker tas i beaktning. (Miller & Proctor, 2016)

Historiskt sett har förändringsledning fokuserat mest på utbildning och coaching för chefer, men gradvis har mer och mer fokus även lagts på utbildning och stöd för de anställda (Miller & Proc- tor, 2016). Detta då LaClair & Rao (2002) med flera studier, pekat på att även anställda behöver ha lämpliga färdigheter och tillgång till användbara verktyg, för att få till en lyckad förändring i en organisation. Organisationer måste kunna hjälpa sina anställda att lära sig den nya processen (Miller & Proctor, 2016). Miller och Proctor (2016) konstaterar även att en av de största riskerna för organisationer vid förändring är att de anställda är medvetna om förändringen men inte stöd- jer den. De påpekar därför att det är viktigt att organisationer är tydliga och förmedlar vilket som är deras uppdrag, varför de måste göra förändringen i förhållande till uppdraget, vad förändring- en kommer åstadkomma och hur organisationen praktiskt ska gå tillväga för att uppnå föränd- ringen (Miller & Proctor, 2016). Miller och Proctor (2016) konstaterar också att det är viktigt att mäta effekterna av förändringen.

En av de mjukvaruutvecklingsmetoder som team och företag infört för att försöka uppnå högre produktivitet, effektivitet, kodkvalitet och produktkvalitet är testdriven utveckling (Bakhtiary et al., 2020). Hädanefter kommer testdriven utveckling refereras till som TDD, en förkortning som kommer av engelskans test-driven development, vilket är den vedertagna förkortningen i bran- schen som även används i svenskspråkiga källor. Astels (2003) och Beck (2002) beskriver att TDD bygger på att: små inkrement av funktionaliteten implementeras i många korta iterationer;

programvarukrav omvandlas till testfall innan koden utvecklas; minimalt med kod skrivs för att få testfallen att gå igenom; och refaktorering av koden görs med stöd av tester. Refaktorering innebär att omstrukturera programkod för att göra den mer överskådlig och systematisk, utan att förändra kodens funktion (Lotsson, u.å.-f).

De flesta tidigare studier på övergång till TDD har mätt metodens effekter på skriven program- kod och utvecklares produktivitet, genom jämförelser med andra arbetssätt. Exempel på sådana studier är Santos et al. (2021); Fucci et al. (2017); samt Wilkerson et al. (2011). Santos et al.

(2021) konstaterar att kontrollmetoden som använts att jämföra TDD med, för det mesta varit

vattenfallsmodellen men att det även förekommer studier där iterativ test-sist-utveckling använts som kontrollmetod. Iterativ test-sist-utveckling kommer hädanefter refereras till som ITL, efter engelskans iterative test-last development. ITL och TDD karaktäriseras båda av korta iterationer till skillnad från vattenfallsmodellen (Tosun et al., 2017).

Betydligt färre studier tycks ha undersökt utvecklares upplevelse av övergång till TDD eller vad som skulle hjälpa utvecklare vid en övergång till specifikt TDD. Den forskning vi hittat är en studie av Choma et al. (2018) där de undersökte utvecklares initiala uppfattningar om TDD.

Choma et al. (2018) lät utvecklare utan erfarenhet av TDD, gå en kurs i TDD och sedan utveckla en applikation eller del av en applikation, under ca två månader användandes TDD. Choma et al.

(2018) undersökte sedan utvecklarnas upplevda fördelar och svårigheter med TDD samt utveck- larnas uppfattning om hur koden blev, genom en strukturerad enkät med öppna och semiöppna frågor.

Choma et al. (2018) konstaterar, att gå över och arbeta enligt TDD tar tid då det kräver inlärning av en ny rutin och att utvecklare behöver ändra sitt sätt att tänka, vilket innebär att skapa en ny vana. De kom fram till att utvecklarna i början upplevde det svårt att veta var de skulle börja och hur de skulle skriva testerna först. Detta gjorde att utvecklarna till en början kände sig mindre produktiva med TDD. Mindre erfarna utvecklade hade svårt för att arbeta i små steg då de tende- rade att vara mer ivriga att få funktionerna implementerade snabbt. Medan mer erfarna utveck- lare kunde se att det gav fördelar med att arbeta i små steg, då de tyckte att det hjälpte dem få till en mindre komplex design. Ibland refaktorerade utvecklarna först efter att en uppsättning tester och funktioner implementerats, och inte efter varje iteration. En annan fördel utvecklarna i studi- en upplevde var att arbetssättet gav dem ökat självförtroende att göra ändringar i koden tack vare den breda testtäckningen som erhölls. De flesta utvecklarna upplevde också att kvaliteten på kod- en ökade, exempelvis i form av mer läsbar kod och mindre invecklade lösningar. (Choma et al., 2018)

Choma et al. (2018) konstaterar dock att en brist i deras studie är att de inte tagit hänsyn till utvecklarnas övriga tidigare erfarenheter. De kontrollerade bara att deltagarna inte hade tidigare erfarenhet av TDD. Choma et al. (2018) menar att andra tidigare erfarenheter utvecklare har också kan spela in i hur utvecklarna upplever initial användning av TDD. Choma et al. (2018) konstaterar också att det är dåligt med studier som studerat utvecklares initiala upplevelse av TDD. Vi vill därför göra en mer djupgående studie ur ett systemutvecklarperspektiv, av utveck- lares uppfattning om övergång till TDD, som tar i beaktning utvecklares samlade tidigare erfar- enheter inom systemutveckling. Detta för att bidra med ytterligare kunskap om arbetssättet TDD, specifikt dess införande, och insikter runt vad som kan vara bra att ta i beaktning för organisa- tioner vars utvecklare ska göra en övergång från ITL till TDD.

1.1. Syfte och forskningsfrågor

Syftet med vår studie är att utforska hur utvecklare upplever en övergång från ITL till TDD och på så vis bidra med ny kunskap till forskningen runt TDD. Målet är att formulera rekommenda- tioner till organisationer hur de kan underlätta för sina utvecklare som ska gå över till TDD.

Mer specifikt har vi undersökt följande forskningsfrågor:

1. Vilka effekter på deras kodande upplever utvecklare vid övergång till TDD?

2. Vilka utmaningar upplever utvecklare vid övergång till TDD?

1.2. Avgränsningar

TDD kan både inkludera enhetstester, integrationstester och acceptanstester (Olson, 2017). (Se kapitel 2.1. Testning, för mer information om olika typer av tester.) Studien kommer fokusera på enhetstester och inte på integrationstester eller acceptanstester. Detta på grund av att: enhetstester skrivs av utvecklare, är den sorts test som används i störst utsträckning av de tre inom TDD och är den sorts test som används för snabb feedback till utvecklaren under TDD-arbetsgången (Olson, 2017).

2. Teori

I detta kapitel redovisas aktuell teori för studien. Teoriområden som tas upp är: testning, testdriven utveckling, införande av nytt arbetssätt, införande av ny vana, samt lärande och lärstilar.

2.1. Testning

Testning är alla de aktiviteter som utförs för att kontrollera att mjukvara gör vad det är tänkt att den ska göra och som utförs för att hitta defekter i mjukvaran innan den tas i bruk (Sommerville, 2011). För att veta om ett system uppfyller krav på funktionalitet, pålitlighet och prestanda och därmed är redo för leverans behövs tester (Sung & Paynter, 2006). Såväl utvecklare som använd- are är överens om att testning är bra och viktigt (Astels, 2003; Torres, 2018). Ändå konstaterar Astels (2003) och Torres (2018), att det finns många system som är bristfälligt testade. Torres (2018) konstaterar att det finns otaliga exempel på när problem inträffat, vilka orsakats av buggar som kunde upptäckts av tester. Torres (2018) beskriver att problem sträcker sig allt ifrån frustra- tion hos användare till kostnader i miljardbelopp och kostnader i människoliv, då ej funna fel orsakat olyckor när utrustning och system inte beter sig som de ska. Även om dessa tre effekter har varierande allvarlighetsgrad konstaterar Torres (2018) att alla tre är skäl för användare att sluta använda ett system, vilket är ofördelaktigt för organisationen som utvecklar systemet.

Holmqvist (2018) konstaterar att det finns en mängd olika sorters tester, vilka kan delas upp i fyra testnivåer: enhetstest, integrationstest, acceptanstest och systemtest. Ett enhetstest testar en individuell komponent i programkoden, exempelvis en klass eller en metod, och verifierar om komponenten uppfyller sin tänkta funktionalitet (Holmquist, 2018). En metod i programmerings- sammanhang, också kallat funktion beroende på programmeringsspråk, är en inkapslad bit kod i ett program som kan anropas för att utföra en viss uppgift (Lotsson, u.å.-a; Lotsson, u.å.-b).

Holmquist (2018) förklarar att enhetstester oftast skrivs av utvecklare och att det är vanligt att enhetstester automatiseras så att de kan exekveras automatiskt i samband med att exempelvis mjukvaran byggs.

Integrationstester testar om olika delar fungerar tillsammans. Från hur olika komponenter i kod- en fungerar tillsammans, till hur olika system fungerar tillsammans. Beroende på vilken nivå det rör sig om skrivs och utförs integrationstesterna antingen av utvecklare eller testare. Acceptans- test kontrollerar om systemet uppfyller användarnas krav och behov, samt om det kommer funge- ra att använda i praktiken för det som är tänkt. Acceptanstester utförs oftast av kunder, användare eller verksamhetsexperter. Systemtest testar systemet som helhet, både dess beteende och funk- tion, och utförs innan systemet lämnas över till kunden och användarna. Systemtester utförs of- tast av testare. (Holmquist, 2018)

Sommerville (2011) beskriver att för en metod utformas enhetstester som anrop till metoden med olika inparametrar och för en klass utformas enhetstester för att testa alla egenskaper hos objekt som bildas från klassen. Att testa egenskaper hos objekt görs genom att sätta och kontrollera alla attribut som objektet har, samt simulera olika event som sätter objektet i olika tillstånd (Sommer- ville, 2011). Olson (2017) och Warburton (2015) konstaterar att ett vanligt kontraproduktivt sätt att skriva enhetstest är att testa implementationsdetaljer i stället för beteende, att skriva ett en- hetstest så det testar hur en klass eller metod utför sin uppgift i stället för att fokusera på resultat- et som klassen eller metoden ger. Olson (2017) och Warburton (2015) förklarar att testa imple- mentationsdetaljer medför problemet att testet då måste ändras varje gång något ändras i pro- gramkoden. Olson (2017) och Warburton (2015) beskriver att best practices för hur enhetstester ska skrivas är att, de ska fokusera på vad enheten som testas ska göra och inte hur den gör det.

Olson (2018) konstaterar även att det är en best practice som behöver efterlevas när TDD an- vänds för att lätt kunna göra ändringar i koden.

För att automatisera enhetstester används olika ramverk vilka gör det möjligt att köra en hel svit med tester på några sekunder. Ett automatiserat enhetstest har tre delar: En setup-del där input och förväntat resultat anges; En anropsdel där objektet eller metoden som ska testas blir anropad;

Och en assert-del där resultatet från anropet jämförs med det förväntade resultatet, genom så kallade asserts. En assert är ett koduttryck som utvärderar ett påstående om, oftast, två värden.

Om utvärderingen kommer fram till att påståendet är sant lyckas testet. Om utvärderingen kommer fram till att påståendet är falskt misslyckas testet (Sommerville, 2011).

I vattenfallsmodellen och andra linjära utvecklingsmetoder har faserna i systemutvecklingslivs- cykeln behandlats som separata block efter varandra och testning har varit en fas som ägt rum efter utvecklingsfasen. Sedan början av 2000-talet har fler och fler organisationer gått över från vattenfallsmodellen och andra mer linjära utvecklingsmodeller, till att jobba iterativt och inkre- mentellt enligt agil systemutveckling. Detta då de agila utvecklingsmetoderna är flexibla, ger möjligheten att hantera förändringar i systemkrav och gör att delar av systemet tidigt kan leve- reras. I och med denna övergång behandlas de olika momenten från faserna i systemutvecklings- livscykeln, inklusive testning, inte längre som separata block utan förekommer för varje itera- tion. Det har dock ofta varit så att testning fortfarande ägt rum efter utveckling inom en iteration.

(Wiktorin, 2018)

Inom agila metoder förekommer även shift-left testning, vilket innebär att flytta in testning tidigare i utvecklingsarbetet, testningen flyttas åt vänster på tidslinjen för ett projekt (Bjerke- Gulstuen et al., 2015). En variant av shift-left är tillvägagångssättet test-first som förekommer inom Extreme programming och TDD, vilket innebär att skriva test för en viss funktionalitet innan programkoden för funktionaliteten skrivs (Sommerville, 2011).

2.2. Testdriven utveckling (TDD)

TDD är en testfokuserad systemutvecklingsmetod där:

● Små inkrement av funktionaliteten implementeras i många korta iterationer.

● Test för en viss funktionalitet skrivs innan programkoden för funktionaliteten utvecklas.

● Testerna avgör vilken kod som behöver skrivas.

● Refaktorering i många små steg som görs med stöd av testerna.

● Ingen programkod produktionssätts utan att ha tester som hör till den.

(Astels, 2003)

Astels (2003) och Beck (2002) förklarar att, med TDDs hjälp är målet är att skriva kod som fun- gerar och som är lätt att designa, skriva, läsa, förstå, utvidga och underhålla. Enhetstester är den sorts test som dominerande används för att köra TDD, även om integrationstester och acceptans- tester också kan användas (Olson, 2017).

Figur 1. Arbetsgången för TDD. (Från Pigeon, X. (2015) A graphical representation of the test-driven development lifecycle [Illustration]. https://en.wikipedia.org/wiki/Test-driven_develo pment#/media/File:TDD_Global_Lifecycle.png. CC BY-SA 4.0)

Arbetsgången för TDD kan ses i figur 1 och lyder som följer:

1. Lägg till ett test som kontrollerar att den nya funktionaliteten har en aspekt av önskat beteende.

2. Kör alla tester för funktionaliteten och se att det nya testet misslyckas, då den delen av korrekt beteende ej finns.

3. Gör den minsta möjliga förändringen i programkoden för att få det nya testet att lyckas.

4. Kör alla tester igen och se att alla lyckas, inklusive det nya testet.

5. Gör refaktorering av koden för att: ta bort dubblering, se till att inga kodningsregler eller best practices är brutna, samt göra koden så läsbar och minimal som möjligt.

6. Iterera.

(Beck, 2002)

Testet som skrivs för steg 1 ska vara litet och behöver inte ens gå att kompileras i steg 2. Den minsta möjliga förändringen som görs i steg 3 behöver inte vara en snygg lösning, det ska bara vara den minsta möjliga ändring som utvecklaren kan göra för att få testet att gå igenom, exem- pelvis göra att en metod returnerar ett hårdkodat värde. Steg 2 och 4 verifierar att testet fungerar som tänkt. Genom steg 3 ska utvecklaren låta sig guidas av feedbacken från sin utvecklingsmiljö till vilken kod hen ska skriva. Om det behöver skapas en klass, en metod eller en variabel, etcet- era, utifrån testet, så kommer utvecklingsmiljön skicka felmeddelande att något saknas. Tanken är att på detta sätt förhindras att utvecklaren skapar en mer komplicerad lösning än nödvändigt.

(Astels, 2003; Beck, 2002)

I steg 5 refaktoreras koden i små steg från att vara en ful snabblösning till en lösning utan dupli- cerad kod, brutna kodningsregler eller brutna best practices, samt göra koden så läsbar och mini- mal som möjligt. En duplicering kan exempelvis vara returnerandet av ett hårdkodat värde vilket endast är ditsatt för att matcha värdet som krävs av testet. För varje refaktoreringssteg som görs under refaktoreringen adderas en liten bit av den nya funktionaliteten och samtliga tester för funktionaliteten körs. Detta för att försäkra att inga fel har introducerats i programkoden. Om ett test skulle misslyckas vid något tillfälle under refaktoreringen vet utvecklaren exakt vilken för- ändring som orsakade misslyckandet; den sista. Tanken med att köra testerna för varje refaktor- ering är att det ger trygghet och mod åt utvecklaren att ta sig an komplicerade uppgifter. (Astels, 2003)

Steg 1 och 2 i arbetsgången brukar tillsammans kallas för röd, då texten i command line inter- facet och progressionsfältet i utvecklingsmiljön som visar på testförloppet blir röda när ett test inte går igenom. Steg 3 och 4 brukar tillsammans kallas för grön, då texten i command line inter- facet och progressionsfältet i utvecklingsmiljön som visar på testförloppet är gröna så länge alla test går igenom. Därav lyder TDDs mantra; röd, grön, refaktoreing. (Se figur 2.) (Beck, 2002)

Figur 2. Mantra inom TDD. Röd: Skriv ett failande test. Grön: Få testet att bli grönt.

Refaktorering: Städa upp i koden. (Illustratör: Rebecca Wallström)

Kent Beck, som anses vara den som återupptäckt TDD, beskriver två sätt att få ett test att bli grönt snabbt, Fake It ('Til You Make It) och Obvious Implementation. Vid Fake It sätts metoden som anropas av testet till att returnera ett hårdkodat värde som stämmer överens med det värde som testet kollar efter. Sedan under steg fem refaktoreras det hårdkodade värdet gradvis i små steg, genom att använda variabler, tills den riktiga koden existerar. Detta sätt används när den slutliga lösningen inte är uppenbar. Är det ett enkelt problem där den snygga slutliga implemen- tationen är uppenbar med en gång används i stället alternativet Obvious Implementation, det vill säga skriv den riktiga lösningen med en gång för att få testet grönt. (Beck, 2002)

Beck beskriver tänket bakom steg tre som följer: “Quickly getting that bar to go to green domi- nates everything else. If a clean, simple solution is obvious, then type it in. If the clean, simple solution is obvious but it will take you a minute, then make a note of it and get back to the main problem, which is getting the bar green in seconds.” (Beck, 2002, Kapitel 2)

Astels (2003) hävdar att fördelar TDD ger är att:

● Koden blir mer noggrant testad.

● Designen blir enklare.

● Gold plating¹ undviks.

● Systemet beskriver sig själv tydligt.

● Testerna blir en exekverbar specifikation på vad koden ska göra och beskriver därmed systemet.

● Systemet får extremt låga defektnivåer och är robust från början till slut.

1 Att fortsätta arbeta på ett system långt förbi punkten där något användbart eller meningsfullt läggs till eller att lägga till funktioner i ett projekt som inte ursprungligen begärts, på bekostnad av tid och pengar. (Jones, 2018)

Det finns även argument mot TDD som hävdats av olika källor:

● Testfallen måste också ändras när kraven ändras, vilket är tidskrävande (Agarwal, 2020;

Cronin, 2019; Fox, 2019).

● TDD hjälper med att hitta buggar i koden, men det garanterar inte att koden gör rätt sak i förhållande till kraven. Metoden garanterar inte validitet. (Agarwal, 2020; Li, 2018)

● Hela teamet bör köra TDD om det ska köras, för att få bra resultat (Agarwal, 2020).

● Det kan upplevas som en långsam process för implementation av enklare uppgifter, då mer tid behövs innan programkoden kan börja skrivas (Agarwal, 2020).

● TDD innebär onödigt arbete när prototyper ska produceras snabbt, vilka sedan inte ska användas när den riktiga programkoden skapats (Dredge, 2019).

● TDD lämpar sig inte när programkod behöver produceras snabbt på kort sikt (Dredge, 2019).

Sammanfattningsvis konstaterar Agarwal (2020), Dredge (2019), Li (2018) och Neopragma (2019) att TDD passar inte alla situationer och löser inte alla problem. Dessutom konstaterar Neopragma (2019) och Li (2018) att TDD ofta används i fel situationer och att metoden ofta inte utförs på rätt sätt.

Aniche och Gerosa (2010) har studerat vanliga misstag utvecklare gör vid TDD genom en enkät- studie med 218 frivilliga utvecklare. Aniche och Gerosa (2010) kom fram till att nio olika miss- tag återkom bland utvecklarna. Dessa är ordnade nedan efter de mest förekommande misstaget som sågs i 26,61% av fallen, till det minst förekommande misstaget som sågs i 5,96% av fallen:

1. Utvecklare känner ett behov att skriva komplicerade testfall som testar mer än bara en liten del av funktionaliteten.

2. Refaktoreringssteget glöms bort.

3. Äldre kod refaktoreras medan nya testfall skrivs.

4. När testerna börjar skrivas så skrivs inte det enklaste testet först.

5. Mer än den minsta mängden lösning som behövs för att klara testet skrivs.

6. Testen ges otydliga namn.

7. Utvecklare hoppar över steget att köra testet direkt för att se att det misslyckas.

8. Testkoden refaktoreras inte.

9. Endast det testet utvecklare jobbar på körs, i stället för alla test som tillhör funktionaliteten som utvecklas.

Aniche och Gerosa (2010) konstaterar att TDD med sina få steg är en enkel metod att följa i teorin, men svårare i praktiken.

Dredge (2019) förespråkar att mäta resultaten som fås med TDD i en organisation, för att se hur- uvida önskade resultat uppnås över tid. Dredge (2019) konstaterar dock att alla fördelar som av-

ses med TDD inte går att mäta huruvida de uppnås. Det har gjorts många studier som undersökt TDDs påverkan på utvecklarproduktivitet och mjukvarukvalitet genom mätningar. Några exem- pel på studier är Bakhtiary et al. (2020); Rafique & Misic (2013); samt Santos et al., (2021). Sett till denna tidigare forskning råder det dock väldigt delade meningar om vad för påverkan TDD har på utvecklarproduktivitet och mjukvarukvalitet. Santos et al. (2021) sammanställer resultaten från 36 primärstudier och konstaterar att effekten TDD har på mjukvarukvaliten i förhållande till kontrollmetoden varierar från -39% till +267%. Santos et al. (2021) konstaterar att det varierar också mycket hur tidigare studier har varit uppsatta sett till programmeringsmiljöer, under hur lång tid utvärderingen skett, analysenheter, typ av uppgifter deltagarna kodat och typ av deltag- are. Santos et al. (2021) konstaterar vidare att de flesta tidigare studier ändå indikerar att TDD ger bättre resultat än kontrollmetoden som används med avseende på kvalitet. Santos et al.

(2021) konstaterar även att kontrollmetoden som använts för det mesta varit vattenfallsmodellen, men att det också förekommer studier där ITL använts som kontrollmetod. ITL och TDD karak- täriseras båda av korta iterationer till skillnad från vattenfallsmodellen (Tosun et al., 2017).

Precis som vid TDD utvecklas vid ITL små inkrement av funktionaliteten i iterationer. Iteration- erna innehåller skrivande av programkod, skrivande av tester, körande av de skrivna enhetstester- na och refaktorering. Skillnaden mellan arbetssätten ligger i ordningen som de olika momenten utförs. Vid ITL skrivs produktionskoden först, refaktorering av produktionskoden sker vid behov och sist skrivs och körs tester innan utvecklaren går vidare till att utveckla ett nytt inkrement av funktionalitet. (Tosun et al., 2017)

I Santos et al.s (2021) egna samling experiment, bestående av 12 kontrollerade experiment, an- vände de ITL som kontrollmetod. De kom fram till att TDD ger något sämre kodkvalitet än ITL.

Santos et al. (2021) hypotetiserar att det är de korta iterationerna som test skrivs i, snarare än ordningen som testfall respektive programkod skrivs i, som påverkar resultatet. Det är en hypotes som även Karac & Turhan (2018) stödjer. En studie av Bakhtiary et al. (2020) motsäger dock denna hypotes, då deras resultat visar på att TDD resulterar i kod av klart bättre kvalitet än ITL.

På grund av de olikvisande resultaten från olika studier där TDD och ITL jämförs konstaterar Bakhtiary et al. (2020) och Santos et al. (2021) att vidare studier behövs på ämnet.

2.3. Införande av nytt arbetssätt

Ichniowski et al. (1995) konstaterar att införandet av de mest innovativa rutinerna främst sker hos nystartade organisationer, medan små ändringar främst införs hos äldre väletablerade orga- nisationer och att det då sker väldigt långsamt. Ichniowski et al. (1995) förklarar att väletablerade organisationer möter betydande motstånd från arbetstagare och chefer när de försöker införa nya arbetsrutiner. Ichniowski et al. (1995) samt Pil och Macduffie (1996) konstaterar att personalen ofta gör motstånd då de upplever att en del av deras kompetens förlorar sitt värde vid byte av ar- betsrutin och att det krävs investeringar i att bygga upp den nya kompetensen. I sin bok The Fifth Dicipline skriver Senge (2006) att människor motsätter sig inte förändring, utan de motsätter sig

att förändras. Watzek et al. (2019) har även kommit fram till i sin studie att människor tenderar att använda sig av kända, mindre effektiva metoder snarare än att prova något nytt. Pil och Mac- duffie (1996) konstaterar att införandet av en ny rutin kan resultera i försämrade eller oförändra- de prestationer under en tid direkt efter införandet. Pil och Macduffie (1996) förklarar också att vissa metoder behöver längre tid för att etableras och att de kan ge oönskad påverkan på presta- tion om denna tid inte ges. Ichniowski et al. (1995) menar att det är kostsamt för organisationer att byta rutin och att den kostnaden minskar den vinst som äldre organisationer skulle få av att byta rutin.

2.4. Införande av ny vana

En vana är en process som triggas av ett visst sammanhang och leder till en omedveten impuls att agera på ett visst sätt som associeras till sammanhanget (Gardner & Rebar, 2019). Gardner och Rebar (2019) konstaterar att vanor skapas genom konsekvent genomförande av en handling eller beteende i ett sammanhang. Strack och Deutsch (2004) beskriver att vanor som medvetet försöker införas kommer genomgå en övergångsperiod, över vilken processen som initierar den önskade handlingen eller beteendet förändras. Gardner och Rebar (2019) samt Strack och Deutch (2004) menar att handlingen inledningsvis drivs av en reflekterande process. Gardner och Rebar (2019) samt Strack och Deutch (2004) konstaterar att genom upprepning, vilket skapar associa- tion mellan sammanhang och handlingen som ska genomföras, övergår handlingen från att vara en medveten process styrd av motivation, till att vara en kontextstyrd impulsdriven process.

Detta kommer leda till att handlingen automatiskt kommer triggas av ett sammanhang. Gardner och Rebar (2019) påstår att repetitioner tidigt i perioden av införandet av en ny vana har störst inverkan på utfallet.

2.5. Lärande och lärstilar

Senge (2006) konstaterar att lärandet inom en organisation börjar på individnivå. För inlärning på individnivå så förklarar Dunn (2001) att det huvudsakligen finns fyra inlärningsstilar: visuell inlärare, auditiv inlärare, kinestetisk inlärare och taktil inlärare. För att en visuell inlärare ska lära sig på bästa sätt så bör hen se det hen ska lära sig och få information presenterad genom exem- pelvis bilder (Boström & Wallenberg, 1997). För en auditiv inlärare så bör informationen presen- teras genom exempelvis diskussioner och samtal då hen lär sig bäst genom att lyssna (Boström &

Wallenberg, 1997). För att en kinestetisk inlärare ska lär sig bäst så bör hen jobba med kroppen och genom rörelse, hens känslor och inlevelse har också en inverkan på inlärningen (Boström &

Wallenberg, 1997). Vid taktil inlärning lär sig individer bäst genom att röra vid saker och använ- da händerna. (Boström & Wallenberg, 1997).

Förutom fyra inlärningsstilar så menar Dunn (2001) att det finns en ytterligare uppdelning som kan göras för att förklara inlärning, nämligen analytiskt och holistiskt tankesätt. Vid analytiskt tankesätt så minns individen ensamstående fakta och detaljer enkelt, medan vid holistiskt tanke-

sätt vill individen få informationen i ett sammanhang, likt i en berättelse, för att lättare ta till sig informationen (Dunn, 2001). Dunn (2001) konstaterar att en persons inlärningsstil består av en kombination av de sex former som beskrivs ovan och kombinationen varierar från person till person hur dominanta de olika formerna är.

3. Fallbeskrivning

Studien genomfördes på ett etablerat IT-konsultföretag som verkat i några decennier. De har ett 50-tal anställda som arbetar uppdelade i team. Företagets konsulter jobbar enligt de krav och ön- skemål som ställs av företagets kunder. Företaget beskriver att de kontinuerligt måste uppdatera hur de jobbar och hänga med i utvecklingen i IT-branschen för att vara en attraktiv partner för sina kunder. Vad företaget utvecklar åt sina kunder har med tiden förändrats från att i huvudsak var stora monolitsystem som tagits fram genom vattenfallsliknande arbetssätt, till mer modulära applikationer och mikrotjänster som tas fram med hjälp av agila arbetssätt. Modulära system be- står av olika delar som lätt kan tas isär och sättas ihop på olika sätt, till skillnad mot monolitsys- tem som ej kan plockas isär i olika delar (Lotsson, u.å.-d; NE Nationalencyklopedin AB, u.å.).

En mikrotjänst är ett program som sköter en enda funktion och som kan anropas genom ett API (Lotsson, u.å.-c). API står för application programming interface, vilket är en specifikation för hur man får andra program att utbyta information med programmet som har API:et (Lotsson, u.å.-e).

Företaget beskriver att mer modulära system och agila arbetssätt kräver en annan strategi för test- ning men att deras sätt att testa inte hängt med i förändringen. På grund av detta upplever före- taget att de nu inte testar optimalt utifrån det nya sättet att utveckla applikationer. Företaget upp- lever att de gjort en förbättring gällande testning men att de fortfarande behöver bli bättre för att fortsatt kunna leverera produkter av god kvalitet och möta kundernas förväntningar. De konsta- terar att de saknar en gemensam rutin, både inom och mellan teamen, runt skrivandet av testkod i förhållande till den programkod som skrivs. De ser TDD som en potentiell lösning på de brister- na då TDD är en testfrämjande utvecklingsmetod med definierad rutin. De vill därför testa att in- föra TDD som en del av sitt kontinuerliga förbättringsarbete.

Utöver detta har en av företagets större kunder nyligen tagit fram en ny strategi för sitt fortsatta kvalitetsarbete. En del i strategin är att deras utvecklare ska implementera TDD då de vill flytta större delar av testningen så tidigt som möjligt i utvecklingen, så kallat shift-left, och öka andel- en automatiserade tester. Detta kommer antagligen innebära att flera av företagets team som jobbar mot kunden kommer behöva börja använda TDD inom en framtid, i stället för den ITL- metod den använder i nuläget. Som del i sitt kontrakt med kunden har företaget i uppdrag att jobba proaktivt. Företaget är därför också intresserade att testa en övergång till TDD i mindre skala innan kunden själv genomfört en omställning.

4. Metod

För att undersöka hur utvecklare upplever en övergång till TDD, genomfördes en fallstudie på ett företag. Denna undersökningsdesign valdes då fallstudier lämpar sig för att studera ett fenomen i sitt verkliga sammanhang (Jacobsen, 2017; Denscombe, 2010). Fallstudier lämpar sig även för ingående studier i en avgränsad kontext i tid och rum likt vår studie (Jacobsen, 2017; Denscom- be, 2010). Jacobsen (2017) skriver att en kvalitativ studie är en bra design när fokus ligger på att få ett djupare förstående då det ofta genererar mer nyanserade data. Detta stödjer studiens syfte att undersöka upplevelser mer djupgående. Jacobsen (2017) beskriver att en explorativ undersök- ningsdesign ofta används för att undersöka ett fenomen när det finns begränsad förkunskap om det. Eftersom vi hittat få tidigare studier eller teori som fokuserat på utvecklares upplevelse av övergång till TDD så gör det att vår studie får en explorativ natur. Studiens undersökningsdesign är alltså kvalitativ och explorativ. Studien har även en abduktiv ansats. Jacobsen (2017) menar att en ansats inte är rent induktiv eller rent deduktiv utan snarare är en form av abduktion då den an- ses omöjligt att vara opåverkad av egna antagande vid en induktiv ansats. Jacobsen (2017) kons- taterar även att endast följa teori enligt en deduktiv ansats är lika omöjligt, då dessa teorier ofta föds ur observationer.

Studien genomfördes genom att fyra utvecklare på ett IT-konsultföretag använde sig av TDD vid arbetet med olika avgränsade utvecklingsuppgifter, i stället för den ITL-metod som de vanligtvis utövade. Detta skedde under en testperiod på fyra veckor, parallellt med utvecklarnas övriga ar- bete. En utvecklingsuppgift kallades på företaget för en ticket. Det är därför en benämning som används hädanefter för att hänvisa till en avgränsad utvecklingsuppgift. Före och efter testperiod- en intervjuades utvecklarna kring deras bakgrund, upplevelser och åsikter. Vi valde att hålla in- tervjuer då intervjuer ger en mer nyanserad bild av respondenters uppfattningar än enkätunder- sökningar (Jacobsen, 2017).

Lally et al. (2010) skriver att det tar i genomsnitt 66 dagar att få in en ny vana av något som ut- förs dagligen, men att det varierar från 18 till 254 dagar. Vår testperiod innefattade 20 arbetsda- gar vilket är precis inom den lägre gränsen för att forma en nya vana enligt Lally et al. (2010). På grund av att utvecklarna även hade andra arbetsuppgifter som var tvungna att utföras kunde de dock ej använda TDD samtliga arbetsdagar under perioden. Utifrån Lally et al. (2010)’s konsta- terande anser vi det därför inte troligt att utvecklarna skulle ha skapat en ny vana med TDD un- der testperioden. Därav konstaterade vi att detta är en studie av övergång till TDD. En av utveck- larna kunde bara vara med och testa TDD under första veckan i testperioden.

Miller och Proctor (2016) konstaterar att det är viktigt att utbildning om det nya arbetssättet är kopplad till att anställda kan applicera det på riktiga uppgifter och projekt direkt, för att de an- ställda ska kunna ta tillvara och komma ihåg det de lärt sig, så kallad just-in-time-learning. Inför undersökningen gavs utvecklarna ett informationsmaterial till TDD (se bilaga 1) och ett underlag

för informerat samtycke (se bilaga 2) att ta del av innan studiens uppstartsmöte. Uppstartsmötet hölls före första intervjun för att säkerställa att deltagarna hade en gemensam utgångspunkt för TDD och var införstådda i studiens syfte och upplägg. Testperioden började sedan direkt efter första intervjun med respektive deltagare.

Under studien har vi haft två handledare från företaget. En av dem var del av samma utveck- lingsteam som några av deltagarna i studien och hade expertis på testområdet och TDD. Den andra handledaren hade insikt i företaget som helhet, hur de jobbade och dess historia.

4.1. Urval

Deltagarna i studien valdes ut genom bekvämlighetsurval. Eftersom undersökningen genom- fördes i samarbete med ett IT-konsultföretag så begränsades urvalet till utvecklare på företaget som kunde tänka sig att delta. För att de skulle vara aktuella respondenter behövde utvecklarna ha minst ett års arbetslivserfarenhet, aktivt jobba på ett projekt vid tidpunkten för undersökning- en och ha för vana att jobba med ITL som utvecklingsmetod. För att få tag på deltagare skickade en av våra handledare ut ett mejl till utvecklare på företaget och efterlyste personer som kunde tänka sig att delta. För att få ett bra underlag för att dra slutsatser beskriver Jacobsen (2017) att ju fler enheter som undersöks, desto större är sannolikheten att kunna generalisera resultatet av en studie. Jacobsen (2017) beskriver att mättnad uppstår när en ny intervju inte tillför ny intressant information. På grund av att vi fick ta de deltagare som kunde tänka sig vara med så blev antalet deltagare fyra. Huruvida mättnad uppnåtts i denna studie är därför oklart.

4.2. Utformning av intervjuer

Jacobsen (2017) beskriver öppna, kvalitativa intervjuer som lämpliga vid datainsamling från få respondenter, då deras uppfattningar och tolkningar är av intresse. Jacobsen (2017) beskriver vidare att semistrukturerade intervjuer tillåter att nya frågor kan ställas under intervjun som ej nedtecknats i förväg, även om den utgår från förberedda frågor runt förbestämda teman som intervjuaren vill få reda på information om. Datainsamlingen genomfördes därför som individu- ella semistrukturerade intervjuer.

Intervjuer med deltagarna genomfördes innan deltagarna började använda sig av TDD och efter testperioden med TDD, vilket gav två intervjuer per deltagare. Vid inledande intervju ställdes frågor kring deltagarnas bakgrund, nuvarande arbetssätt, uppfattning och erfarenheter av TDD och testning. Intervjuguiden för den inledande intervjun kan ses i bilaga 3. Vid den avslutande intervjun ställdes frågor kring deras användande av TDD och upplevelser runt övergång till TDD. För utformning av frågor kring hur utvecklarna upplever sin skrivna kod utgick vi från Börstler et al. (2017)’s forskning, där de undersökt vilka faktorer som anses tyda på god kodkva- litet. Intervjuguiden för den avslutande intervjun kan ses i bilaga 4. Följdfrågor ställdes vid samt- liga intervjuer, i stil med: Kan du utveckla? Hur menar du då? Varför? Varför inte? Kan du moti-

vera? Intervjuguiderna testades innan de skarpa intervjuerna genom varsin pilotintervju med en annan utvecklare som ej deltog i studien.

Intervjuerna spelades in genom videoinspelning efter att deltagarna givit sitt samtycke till det, för att enklare kunna transkriberas och analyseras. På grund av Covid-19 genomfördes intervjuerna via videosamtal över Microsoft Teams. Denna plattform valdes då det var en etablerad plattform på företaget som utvecklarna var vana vid.

4.3. Analys av intervjuer

För analys av intervjuerna användes innehållsanalys då det är en metod som passar för att analys- era transkribering av intervjuer och som kan ge kunskap och förståelse för fenomenet som stude- ras (Hsieh & Shannon, 2005; Jacobsen, 2017). Hsieh & Shannon (2005) beskriver att det i huv- udsak finns tre olika varianter av innehållsanalys. Vi använde oss av varianten konventionell inn- ehållsanalys, då den metoden fokuserar på meningen av texten, samt att kategorier kan represen- tera både explicit kommunikation och antydda saker (Hsieh & Shannon, 2005). Hsieh & Sha- nnon (2005) beskriver också att det är en lämplig metod när befintlig teori eller forskningslittera- tur om ett fenomen är begränsad, vilket de var i vårt fall. Det är en metod med induktiv kategori- bildning, det vill säga att öppen kodning används, vilket innebär att kategorier och teman härleds ur data (Hsieh & Shannon, 2005; Jacobsen, 2017). Både tema och kategori är i denna rapport benämningar på grupperingar bestående av likartade meningsbärande enheter. Kategorierna är dock konkreta, medan temana är mer abstrakta.

Vi följde i stora drag Hsieh & Shannons (2005) tillvägagångssätt för konventionell innehålls- analys och utförde analysen enligt följande steg:

1. Transkribera och läs igenom transkriberingarna av inledande intervjuer.

○ Detta gav en första uppfattning om potentiella teman och kategorier. Exempel på tema och kategori som hittades i detta steg var “Förutsättningar under

testperioden” och “Erfarenheter inom systemutveckling” (Se figur 3).

2. Identifiera meningsbärande enheter i inledande intervjuer.

○ Exempel på del av meningsbärande enhet som hittades: “Om det är lite mindre förändringar och man sätter sig och kodar så kan det vara att man glömmer bort att skriva enhetstester...”

3. Generera teman och kategorier medan inledande intervjuer läses igenom och meningsbärande stycken identifieras.

○ Exempel på kategorier som hittades i detta steg var “Utbildning” och

“Enhetstester” (Se figur 4 och 5).

4. Transkribera avslutande intervjuer och identifiera meningsbärande enheter.

○ Exempel på del av meningsbärande enhet som hittades: “Källor som någon tyckte var bra skulle vara bra ... Kan räcka med Youtube, en video är aldrig fel. Kolla och se hur de gör.”

5. Generera ytterligare teman och kategorier utifrån de meningsbärande enheterna från de avslutande intervjuerna.

○ Exempel på kategori och tema som hittades i detta steg var “Arbetssätt TDD under testperioden” och “Upplevda effekter på producerad kod” (Se figur 8 och 9).

6. Ordna teman och kategorier i träddiagram.

○ I denna process redigerades namn, vissa teman och kategorier delades medan andra slogs ihop. Slutgiltiga träddiagram kan ses i figur 3–11.

Inför transkribering av intervjuerna tog vi fram gemensamma riktlinjer för hur transkriberingarna skulle noteras. Riktlinjerna innefattade hur vi skulle notera repliker från olika personer, uttryck som avviker från hur personen uttrycker sig och pratar över lag, egna kommentarer till något som sades och markering för när transkribenten inte hörde vad som sades. Vid de tillfällen under tran- skribering och analys då vi var osäkra på vad olika deltagare menat frågade vi respektive deltag- are om förtydligande för att säkerställ att vi fick med rätt tolkning. Som stöd under steg 1–5 av analysen hade vi en lista med bakgrundstanken varför olika frågor ställts. Denna lista kan ses i bilaga 5.

4.4. Etiska överväganden

Under denna rubrik redovisas hur vi tagit hänsyn till olika etiska aspekter.

4.4.1. Vinstetik

Vinstetik innebär att det ska finnas nytta med resultatet av en studie och att nyttan ska överväga eventuell skada studien kan orsaka (Jacobsen, 2017). Inför studien gjorde vi en övervägning runt detta och kom fram till att denna studie kunde vara till nytta för både forskningen på TDD, för företaget studien utfördes på och för de enskilda deltagarna. Till forskningen på TDD resonerade vi att denna studie kunde bidra med en djupare insikt i hur utvecklare upplever övergång från ITL till TDD. För företaget resonerade vi att studien skulle bidra med information om aspekter för dem att tänka på inför en mer storskalig övergång till TDD. För utvecklarna i teamet resoner- ade vi att de skulle kunna få nytta av studien om den visade sig förbättra deras arbete ur någon aspekt. Vi resonerade att skada som denna studie skulle kunnat orsaka var främst för de individu- ella deltagarna, då det skulle krävas tid och energi för dem att vänja sig vid en ny utvecklingsme- tod. Om det hade visat sig att det inte fungerat bra för deltagare att använda TDD hade det kunn- at innebära en påfrestning under tiden som testperioden med TDD pågick. Vi bedömde dock att nyttan med studien skulle överväga möjlig skada.

4.4.2. Informerat samtycke

För att möjliggöra för informerat samtycke i enlighet med Informationskravet och Samtyckes- kravet som beskrivs av Vetenskapsrådet (2002) låg det på vårt ansvar att se till att deltagarna fick

tillräcklig information om studien i förväg för att kunna avgöra om de ville delta. Deltagarna är vuxna kompetenta människor vid sina sinnens fulla bruk som själva kunde bestämma om de sku- lle delta. Vi har inte fått några indikationer på att deltagarna inte skulle deltagit av fri vilja, dock skulle det ha kunnat finnas påtryckning från företagets sida som vi inte vet om.

4.4.3. Konfidentialitetskravet

Sett till Konfidentialitetskravet som beskrivs av Vetenskapsrådet (2002) kan vi inte garantera del- tagarna total anonymitet, då vi som utför studien vet vilka de är och behövde kunna koppla vil- ken data som hör till vilken deltagare. För att garantera konfidentialitet publiceras inte all rådata som del av rapporten. Deltagarnas namn eller konstellation av uppgifter som skulle kunna göra det möjligt för utomstående utanför företaget att koppla en viss person till en specifik åsikt, an- ges inte vid redovisning av resultaten. Vi hänvisar heller inte till utvecklare med alias för att inte andra på företaget ska kunna identifiera individuella respondenter genom en kombination av uppgifter kopplade till samma person.

4.4.4. Korrekt återgivning

För att säkerställa att vi ej av misstag skulle bryta mot kravet på korrekt återgivning av deltagare, nyttjades respondentvalidering.

4.4.5. Uppdragsforskning

Vid uppdragsforskning utförs forskningen på uppdrag av någon och det finns därmed risk för beroendeställning och bias (Jacobsen, 2017). Vi utförde vår studie på ett IT-konsultföretag. Idén till studien framkom i samspråk med en av de personer vi haft som handledare på företaget och företaget har ställt sig positiva till idén. Studien är därför inte ett explicit uppdrag. En av våra handledare från företaget hade ett stort engagemang och förhoppningar om TDD som utveckl- ingsmetod och tyckte att metoden verkade kanon. Vi upplevde att hen hade ett önskemål från sin sida om att utvecklarna genom att testa TDD skulle upptäcka att det är bra, så hen skulle kunna trycka på för att företaget ska använda TDD i större utsträckning. Vi har dock inte känt något tryck från företagets håll att komma fram till ett visst resultat eller påtryckning att uttrycka vissa synpunkter om ämnet vi studerat, då vår andra handledare och företaget i stort upplevts neutrala till utfallet av studien.

4.5. Metoddiskussion

I denna del redovisas vad som gjorts för att säkerställa god reliabilitet och validitet. Faktorer som skulle kunnat eller har påverkat graden av reliabilitet och validitet hos studien diskuteras också.

4.5.1. Reliabilitet

En undersöknings reliabilitet syftar till pålitligheten hos undersökningens design, datainsamling och analys (Jacobsen, 2017).

Jacobsen (2017) beskriver undersökareffekten som den påverkan undersökaren har på undersök- ningen genom sitt uppförande, utseende och den information deltagare har om undersökaren. Att vi som undersökt är studenter kan ha påverkat deltagarna på ett flertal sätt. Deltagarna kan ha förenklat sitt sätt att uttrycka sig i ett försök att anpassa sig till vår antagna kunskapsgrad, vilket kan ha lett till att aspekter ej delgavs i tron att det var för komplicerat för studiens nivå. Den an- tagna kunskapsnivån kan även färgat hur deltagarna förhöll sig till de nya regler som undersök- ningen medförde. Att deltagarna förlitade sig på det egna förnuftet och avvek från givna regler, om studiens regler krockade med deras egen uppfattning. För att motverka denna möjliga under- sökareffekt gjorde vi vårt bästa för att uppträda professionellt, ställa relevanta frågor, vara pålästa för att förstå deltagarna, samt vara väl förberedda. Detta för att inge pålitlighet och kompetens och stärka tilltron till oss och studien. För att ytterligare motverka undersökareffekten gjorde vi vårt bästa för att bemöta deltagarna väl, genom att visa uppskattning och förståelse för den tid och ansträngning de investerar i undersökningen, för att stärka deras engagemang i deltagandet.

Vi har inte uppfattat någon märkbar undersökareffekt på deltagarna av ovan nämnda saker. För att undvika att få en effekt på resultatet av att olika personer höll olika intervjuer lät vi en och samma person vara intervjuare för samtliga intervjuer. Trots detta, och att vi haft en pilotintervju innan de skarpa intervjuerna, så är det ändå ett faktum att intervjuaren blev skickligare och skick- ligare för varje intervju som gick. Vi har därför antagligen fått fram mer relevant information för studien under senare intervjuer än under tidigare.

Kontexteffekten beskriver den inverkan sammanhanget har på datainsamlingen (Jacobsen, 2017).

Både testmiljö och intervjumiljö var bekant för deltagarna då det var deras arbetsmiljö. Kommu- nikationsplattformen Microsoft Teams valdes då deltagarna var vana att använda den i arbetet. Vi var medvetna om att deltagarnas beteende kunde påverkas av vetskapen om att de blev inspelade och av att de var ovana att ha kamera på vid samtal över Microsoft Teams. Deltagarna informer- ades om intervjuernas innehåll för att de skulle känna sig förberedda och ej överraskade. Tid- punkt för intervjuerna valdes av respektive deltagare och intervjuerna ägde rum under deras ar- betstid. Vi upplevde att deltagarna uppträdde mer nervöst under den inledande intervjun än under den avslutande intervjun. Vilket vi misstänker är en kontexteffekt som skapades av deltagarnas ovana runt intervjusituationen med kamera på över Teams vid första intervjun.

Innan första intervjun testades videoinspelning i förväg i syfte att säkerställa att inspelning fung- erade som tänkt. Vi förberedde även väl fungerande mikrofoner och kameror till oss själva, samt bad deltagarna att förbereda det samma. För att säkerställa god reliabilitet nedtecknandes data med noggrannhet, vilket underlättades av att intervjuerna filmades. För att kunna genomföra en

väl utförd analys såg vi till att vara väl inlästa på området och analysmetoden. Vi såg även till att vara insatta i de mjukvaror vi använde.

I studien så har vi haft deltagare som från början var skeptiska till att byta arbetssätt och till TDD som metod, samt de som inte var skeptiska. Då vi har haft bekvämlighetsurval bestående av del- tagare som kunde tänka sig vara med, så det finns dock en risk att vi inte fått med någon repres- entant som tillhör de som är mest skeptiska till att byta arbetssätt eller till TDD som metod. Vår urvalsmetod kan därför ha påverkat det resultat vi fått.

Under de inledande intervjuerna så framkom det att två av utvecklarna börjat testa TDD på var sin ticket innan intervjuerna. Som nämndes i kapitel 8.2.2. Syn på progress, test och TDD, så verkar detta åtminstone påverkat åsikterna hos en av dem. Det är dock troligt att det även påverk- at åsikterna hos den andre. Detta gör att vi inte fått med komplett information om två av deltagar- nas utgångsläge och kan således inte dra lika säkra slutsatser runt hur deras bakgrund eventuellt påverkat deras upplevelse av övergången till TDD. För framtida studier bör det därför specificer- as mer explicit för deltagarna att de inte ska börja testa arbetssättet innan den inledande interv- jun.

En av deltagarna kunde bara vara med och testa TDD under testperiodens första vecka. Vi valde att hålla slutintervju med hen och ta med hens resultat i studien ändå, då övriga deltagare inte heller kunnat utnyttja majoriteten av testperioden till att använda TDD, på grund av andra upp- drag i sitt arbete. Två av de andra utvecklarna hann göra 2 tickets, medan deltagaren som bara var med första veckan, samt en av de andra utvecklarna hann göra 1 ticket. Deltagarna arbetade enligt TDD på sina tickets utspritt på 1–4 dagar totalt. Utvecklaren som bara var med under första veckan var en av de deltagare som använde TDD under 4 dagar. Vi bedömde därför att deltagar- ens medverkan låg i nivå med övrigas sett till antal gjorda tickets och aktiv tid med TDD.

1–4 dagar och 1–2 tickets med TDD är dock kort tid och inte så många uppgifter. Vilket gav ett mindre underlag att dra slutsatser från än vad vi hoppats på. Deltagarna i studien uttryckte också att de hade velat kunna utföra fler tickets under fler dagar för att kunna uttala sig mer och säkrare runt olika aspekter av övergången. Enligt Gardner och Rebar (2019) så har tidiga repetitioner av införandet av en ny vana dock störst inverkan på vanebildande. Vi anser därför att vårt resultat ändå kan bidra med kunskap till forskningen om TDD och organisationer som ska göra en över- gång till TDD. Vi drar dock slutsatsen att för framtida studier skulle det vara fördelaktigt med en längre testperiod om utvecklarna har många andra uppdrag vid sidan av, eller helst se till att del- tagarna får öronmärkt tid till att köra arbetssättet som inte blir åsidosatt på grund av andra arbets- uppgifter.

4.5.2. Intern validitet

En undersöknings interna validitet beskriver hur väl resultaten överensstämmer med verklighet- en. Faktorer som påverkar den interna validiteten är: om deltagarna ger rätt information, om forskaren tolkat och återgivit data korrekt, samt om resultaten återspeglar tidigare forskning.

Dessa faktorer redogörs för under denna rubrik. (Jacobsen, 2017)

För att säkerställa att våra deltagare kunde ge den information som eftersöktes så var deltagarna tvungna att uppfylla de krav som ställts under rubriken urval. Undersökningens deltagare var pri- märkällor och hade därför störst insikt om sina egna åsikter. Deltagarna gavs chansen att delge åsikter om ett möjligt framtida arbetssätt, vilket borde uppmuntrat dem till att ge sina genuina åsikter, då det skulle vara fördelaktigt för dem personligen. Det var av stor vikt att vi kunde gar- antera god konfidentialitet eftersom sociala relationer skulle kunnat påverka deltagarnas respons.

Deltagarna skulle kunnat vara ovilliga att delge en sann åsikt om de hade avvikande åsikt från en person de ville hålla sig i god med, om konfidentialitet ej garanterades.

Som vi skrev i kapitel 7.5. Uppdragsforskning, så har en av våra handledare från företaget tyckt att TDD verkar kanon och att vi fått intrycket av att hen hoppas att utvecklarna skulle upptäcka att TDD är bra. Det var också samma handledare som skickade ut mejl till utvecklare på företag- et och efterlyste deltagare, i vilket hen formulerade sig väldigt positivt vinklat om TDD. Hur detta första mejl var formulerat skulle kunna ha påverkat studiens interna validitet. Det skulle kunna påverkat hur deltagarna uttryckte sig runt TDD under intervjuerna, om de känt en social påtryckning av mejlet och vår handledare, att uttrycka sig på ett visst vis. Som nämnts upplevde vi att deltagarna uppträdde mer nervöst under den inledande intervjun. Om deltagarna upplevde en social påtryckning om hur de skulle uttrycka sig runt TDD skulle det också kunna bidragit till denna nervositet. Då nervositeten inte kvarstod under den avslutande intervjun är det dock mer troligt att nervositeten berodde på ovana runt intervjusituationen snarare än en verklig social på- tryckning.

För att öka sannolikheten att resultatet återgavs korrekt och för att inte lägga in fördomar oavs- iktligt, analyserades data separat enligt triangulering och sedan jämförde vi om vi dragit samma slutsatser från analysen. För att stärka den interna validiteten fördes en kritisk diskussion om res- ultaten. Vi utförde respondentvalidering på analysen av respektive respondents intervjuer, där de ombads validera huruvida vi uppfattat dem korrekt.

4.5.3. Extern validitet

Jacobsen (2017) definierar den externa validiteten som möjligheten till överförbarhet och genera- lisering av studiens resultat till andra sammanhang. Att vår studie haft en metod som varit kvali- tativ, smal och djupgående är något som enligt Jacobsen (2017) gör det svårare att generalisera resultatet bortom vårt fall. Vi bedömer dock att slutsatserna utifrån vårt resultat kan generaliseras

även till andra fall då vårt resultat stämmer överens med tidigare teorier och flertalet tidigare studier.

5. Resultat & Analys

I detta kapitel presenteras resultat och analys tillsammans för de olika områdena som vår studie innefattat: utvecklarnas bakgrund; deras upplevelser av övergång till TDD, inklusive resultat kopplat till forskningsfråga 1 och 2; samt vad som skulle kunna underlätta en övergång till TDD.

Som tidigare nämnts i kapitel 4.4.3. Konfidentialitetskravet, hänvisar vi inte till individuella ut- vecklare med specifika alias, för att det inte ska gå att identifiera individuella respondenter gen- om en kombination av uppgifter kopplade till samma person. I det fall då det finns en intressant trend mellan olika svar givna av respondenter har detta skrivits ut som del av analysen.

Teman, kategorier och underkategorier som identifierats under analysen kan ses i figurerna 3–11.

Relevanta resultat för de olika områden, utvecklarnas bakgrund, vårt syfte, forskningsfrågor och mål, som sållats ut från dessa redovisas nedan under rubrik 5.1.–5.3. Där 5.1. handlar om utveck- larnas bakgrund. Del 5.2. handlar om upplevelser av övergång, vilket inkluderar funna resultat kopplade till vårt syfte och forskningsfrågor. Del 5.3. handlar om att underlätta övergång, vilket innefattar funna resultat kopplade till vårt mål. Som tidigare nämnts i metodkapitlet så används både tema och kategori som benämningar på grupperingar bestående av likartade meningsbäran- de enheter. Kategorierna är dock konkreta, medan temana är mer abstrakta.

5.1. Utvecklarnas bakgrund

En kategori och två teman som hittats runt utvecklares bakgrund är: “Erfarenheter inom system- utveckling”, “Syn på olika saker” och “Förutsättningar under testperioden”. Dessa illustreras i figur 3 och redovisas närmare under rubrikerna 5.1.1., 5.1.2. och 5.1.3.

Figur 3. Kategorin “Erfarenheter inom systemutveckling” och de två temana “Syn på olika saker” och “Förutsättningar under testperioden” som hittats runt utvecklares bakgrund. För att

se kategorier och underkategorier som hittats under “Erfarenheter inom systemutveckling”,

“Syn på olika saker” och “Förutsättningar under testperioden”, se figur 4–6.

5.1.1. Erfarenheter inom systemutveckling

Underkategorier som hittats under kategorin “Erfarenheter inom systemutveckling” kan ses i figur 4.

Figur 4. Underkategorier som hittats under kategorin “Erfarenheter inom systemutveckling”.

Alla underkategorier är på samma nivå. I figuren är underkategorierna dock placerade på olika nivåer för att lättare få plats på en sida och samtidigt kunna läsa texten i bilden.

Utvecklarna som deltog i studien hade 2–3 års eftergymnasial utbildning inom systemutveckling på högskola eller yrkeshögskola och de hade 2–20 års arbetslivserfarenhet inom systemutveckl- ing efter avslutad utbildning. Samtliga utvecklare hade erfarenhet av att skriva och köra någon

form av tester. Det skilde sig dock i hur vana de var att skriva enhetstester, från att bara ha skrivit det vid enstaka tillfällen tidigare till att ha skrivit det kontinuerligt under 8 års tid. En av deltag- arna hade fått testat på TDD under sin utbildning, men ingen av dem hade använt TDD i sitt arb- ete tidigare. Tre av de fyra deltagarna hade hört talas om TDD och tagit del av information om arbetssättet från webben, innan sitt deltagande i studien. Samtliga deltagare hade läst igenom in- formationsmaterial till TDD (se bilaga 1). En av fyra hade även tittat på innehållet i länkarna i informationsmaterialet. Två av utvecklarna började med TDD på en ticket lite smått redan innan den inledande intervjun.

Vad gäller utvecklarnas arbetssätt, som visualiseras av underkategorin “Nuvarande arbetssätt” sa tre av deltagarna att de påbörjade sitt arbete genom att direkt hoppa in i sin kod, kolla igenom den för att se vart ändringar behöver göras för att sen börja koda direkt. En deltagare började med att strukturera vad som skulle göras på ett papper innan hen började koda. Hen skrev däref- ter fort något som fungerade, för att sen refaktorera till en snyggare lösning. Tre av utvecklarna skrev tester efter att en större mängder kod skrivits eller när de kände att de kodat klart och löste sedan eventuella fel som hittas. En av utvecklarna skrev generellt tester mer parallellt med sin kodning och började med tester när en grundläggande funktionalitet fanns. Av detta kan vi se att två av utvecklare hade element i sina arbetssätt från början som låg aningens närmare TDD än de andra två. Den ena utvecklaren hade vanan att tänka efter lite noggrannare före, skriva något snabbt och sen refaktorera, och den andra utvecklaren började skriva tester tidigare och delvis parallellt med koden. De två utvecklarna som hade element i sitt arbetssätt som låg närmare TDD var också det två utvecklare som hade kortast arbetslivserfarenhet. En av dem var den utvecklare som fått testa TDD under sin utbildning.

Tre av deltagarna sa sig använda sig av sitt sätt att gå till väga på grund av vana och två av dem sa att det kändes tryggt. Tre av utvecklarna motiverade att en styrka med sitt arbetssätt var att de snabbt kom fram till en lösning och en prototyp som gick att visa för kunden. En av utvecklarna sa sig inte se några svagheter med arbetssättet hen vanligtvis använde, medan de andra tre nämn- de ett antal varierande nackdelar. Bland annat att koden ibland fick dålig testbarhet, att enhets- tester inte alltid skrevs, risk för att ibland överdesigna och att buggar upptäcktes sent. “Om det är lite mindre förändringar och man sätter sig och kodar så kan det vara att man glömmer bort att skriva enhetstester. Eftersom att man har skrivit klart koden och känner att, men nu är jag färdig.

Antingen att man glömmer bort eller att man känner att det inte behövs för det här. Då kan det visa sig sen när testpersonen testar att det kanske är någon liten en bugg som man har missat.”

5.1.2. Syn på progress, test och TDD

Kategorier och underkategorier som hittats under temat “Syn på olika saker” kan ses i figur 5. , Hur utvecklarna på framsteg de gör visualiseras av kategorin “Syn på progress”. Två av deltag- arna beskrev sig som praktiska och likställer att göra framsteg med att funktionalitet skapas. Tre av fyra utvecklare uttryckte att de mäter sin progress i mängd skapad eller fixad funktionalitet