Efter fyra sprintar lämnade forskarna projektet. Två sprintar efter detta utfördes ett uppföljn- ingsmöte för att se hur testarbetet fortskridit. Fokus under denna uppföljning var vilka de- lar av processen som fortfarande följdes och vilka delar som ändrats. Inför uppföljningen gjordes även en sorts manuell beräkning av kodtäckning för att skapa en uppfattning om hur många tester som skrivits under utvecklingen. Endast en av utvecklarna var tillgänglig för
4.6. Uppföljning
detta möte och det genomfördes på ett semi-strukturerat sätt. Utöver eventuella förändringar i processen och kodtäckning diskuterades de observationer som gjordes i denna studie un- der fas 1, presenterade i avsnitt 5.1, för att undersöka om uppfattningen kring dessa hade ändrats.
5
Resultat
I detta kapitel presenteras resultatet från studien. Detta inkluderar val av verktyg och ramverk, sammanfattningar av intervjuer samt slutligen en beskrivning av testprocessen som togs fram och utvärderingen av den.
5.1
Fas 1 - Förståelse för verksamheten
Efter den första fasen hade en god uppfattning skapats om den miljö processen skulle passa in i. Från intervjuer med alla tillgängliga som jobbade på Webb & Mobilt, totalt 9 personer, kunde ett antal trender urskiljas.
Resultat från fas 1
Resultatet har delats in i två kategorier: Observationer kring testprocessen och Teknisk överblick. Den förstnämnda handlar om hur det ursprungliga arbetet fungerade och är baserat på in- tervjuer. Tekniska överblick innehåller en beskrivning av den generella arkitekturen hos webb- applikationerna och är baserat på Exsitecs interna dokumentation.
Observationer kring testprocessen
Intervjuerna genererade en god uppfattning om den initiala testprocessen, organisationen och utvecklarnas inställning till testning. Resultaten har sammanställts till en lista av obser- vationer.
1. I dagsläget sker all testning manuellt. Utvecklaren startar applikationen och veri- fierar att systemet beter sig som förväntat. Samma tester behöver ofta upprepas många gånger innan en funktion implementerats eller ett problem lösts.
2. Ad-hoc testning. Det finns ingen dokumentation eller plan för testningen. Den sker improviserat när behov uppstår.
3. Det är svårt att uppskatta hur mycket tid som läggs på testning. Uppskattningar vari- erade mellan 15 % och 80 %, när debuggning räknades in.
5.1. Fas 1 - Förståelse för verksamheten
4. Det finns en upplevd tidsbrist när det gäller testning. Många angav att de kände att de inte hade tid, men att de egentligen trodde att de hade tid.
5. Tid lagd på testning fås igen. Under ett av de senaste projekten har det skrivits mer enhetstester på backend och utvecklarna anger att de lägger 20 % av utvecklingstiden på testning men att de vinner tid totalt genom de fördelar de får av det.
6. Det finns ett utbrett stöd för testning. Alla tillfrågade ställde sig positiva till att testa mer än i dagsläget.
7. Erfarenhet inom testning varierar. 3 av 9 utvecklare har stor tidigare erfarenhet, men ingen utbildning, inom testning. 6 av 9 utvecklare har varken utbildning eller erfaren- het inom testning.
8. Struktur och riktlinjer efterfrågades. Flera av utvecklarna efterfrågade överenskomna riktlinjer om hur de skulle testa sin kod. Detta skulle både underlätta vid upplärning av nyanställda och för att alla utvecklare ska känna att de kan lägga tid på att skriva tester.
9. Små team. Utveckling hos Webb och Mobilt sker oftast i team om 2-6 medlemmar. 10. Anpassning efter företagets behov. Exsitecs Webb & Mobilt-avdelning uttryckte
förhoppningen att testningen ska ligga på en nivå som passar företaget. I detta ingår att ha i åtanke att det är kunden som betalar för testningsarbetet och att förmågan att leverara i tid inte får påverkas.
11. Kunden ansvarig för acceptanstestning. Det är kunden som är ansvarig för att accep- tanstester genomförs. Detta sker i slutet av projektet.
Teknisk överblick
Figur 5.1 presenterar en överblick över arkitekturen för frontend i de applikationer som skrivs i Angular på Exsitec. Nedan presenteras delarna i figuren och hur de interagerar med varan- dra.
De fundamentala byggstenarna i applikationer skrivna i Angular är komponenter. Dessa in- nehåller i regel både innehåll & struktur (html), utseende (css) och funktionalitet (JavaScript) och utgör hela grässnittet mot användaren. Komponenter kan även innehålla andra kompo- nenter. Sådana komponenter tenderar att ses som containrar, eller smarta komponenter, och ansvarar ofta för att bland annat anropa tjänster och innehåller viss logik för att hantera svaren. Komponenter som i sin tur inte innehåller andra komponenter är ofta skapade för att sköta ett enskilt element i gränssnittet, till exempel en knapp, en lista eller ett formulär. Dessa komponenter kallas ibland dumma komponenter eftersom de oftast inte behandlar data själva utan skickar vidare indata från användaren till en smart komponent genom att skicka en händelse (eng. event).
Ett typiskt exempel på smarta komponenter och dumma komponenter skulle vara att en smart komponent kommunicerar med en tjänst som ger den en lista på användare. Den smarta kom- ponenten ger sedan denna lista som indata till en dum komponent. Den dumma komponenten ansvarar för layout av listan, men vet inte egentligen vad den innehåller. Om en användare klickar på ett element i listan skickar den dumma komponenten en händelse med vilket listele- ment som klickades till den smarta komponenten. Den smarta komponenten innehåller logik för vad som ska hända då, till exempel gå vidare till en annan vy för detaljerad information om just den användaren.
Applikationerna skrivna i Angular hos Exsitec följer mönstret Redux [1]. Detta innebär fram- förallt att applikationens tillstånd (eng. state) lagras på en central plats i applikationen, en
5.1. Fas 1 - Förståelse för verksamheten
slags klientdatabas (eng. store). Ändringar i klientdatabasen kan enbart göras genom att skicka meddelanden (eng. actions). Ett meddelande måste ha en typ och kan även innehålla data. När ett meddelande når klientdatabasen skapas en ny version av applikationens till- stånd vilken görs tillgänglig för resten av applikationen. Detta gör att alla förändringar blir spårbara och är tänkt att bland annat underlätta felsökning.
Redux är inte specifikt för applikationer skrivna i Angular [1]. Men för att integrera Re- duxmönstret med Angularapplikationer används biblioteket ngrx/store1som är särskilt äm- nat att göra just detta. I Exsitecs applikationer är det upplagt så att smarta komponenter kom- municerar med ett tunt tjänstelager (eng. services) för att skicka meddelanden till klient- databasen.
Logiken för exakt hur klientdatabasen förändras av ett meddelande sköts av reducers. Dessa är så kallade rena funktioner, vilket innebär att de inte är beroende av något annat än indata för att producera viss utdata. De tar klientdatabasens tillstånd och ett meddelande av en viss typ som indata och producerar ett nytt tillstånd som utdata.
Arkitekturen hittills skulle räcka gott till applikationer som är helt självständiga och inte behöver kommunicera asynkront med externa källor, såsom en server eller andra API:er. För att underlätta då sådan kommunikation behövs används två ytterligare delar i arkitekturen: effekter (eng. effects) och resources.
Resources är funktioner som gör specifika anrop till en server eller liknande och returnerar den data servern skickade. De existerar främst för att separera detaljerad information om hur http-anrop och dylikt utförs från resten av applikationen.
Effekter är funktioner som anropas då specifika meddelanden skickas. De anropar i sin tur resources, och behandlar den data som returneras. Ofta skickar de ett nytt meddelande, som innehåller data från servern, för att uppdatera klientdatabasen.
Ett typiskt exempel för hur dessa delar interagerar börjar med att användaren interagerar med en dum komponent genom att efterfråga att en lista på användare ska laddas in. Den dumma komponenten skickar en händelse (eng. event) till en smart komponent som kom- municerar med en tjänst. Tjänsten skapar och skickar ett meddelande av typen LOAD_USERS, men som inte innehåller någon data. Detta meddelande gör att både en reducer och en effekt anropas. En reducer tar emot det meddelande som skickats och uppdaterar applikationens klientdatabas, som nu reflekterar att listan på användare håller på att laddas. Detta kan an- vändas i gränssnittet för att visa användaren vad som händer. En effekt ser till att anropa en resource som hämtar en uppdaterad användarlista från servern. När effekten har fått listan från resourcen skapar och skickar den ett nytt meddelande, med typen LOAD_USERS_SUCCESS och listan av användare som data. Detta meddelande fångas i sin tur upp av en reducer som uppdaterar klientdatabasen som nu reflekterar att listan är färdigladdad. Detta gör att gränssnittet kan visa listan för användaren.
5.2. Fas 2 - Övervägning av förbättringsåtgärder
Figur 5.1: Arkitektur över frontend i Exsitecs Angular-applikationer
5.2
Fas 2 - Övervägning av förbättringsåtgärder
Den andra fasen byggde vidare på resultatet från den första fasen. Testning skedde helt manuellt (observation 1) och utan planering eller struktur (observation 2). Det verkade rim- ligt att se den övergripande förbättringsåtgärden som "att testa mer". Detta behövde dock ske på ett strukturerat sätt och tydliga riktlinjer behövde utformas (observation 8). Det fanns ett stort stöd för att testa mer (observation 6) men många utvecklare upplevde inte att det fanns tid att sätta sig in i testning ordentligt (observation 4).
Den andra fasen i CMD ska resultera i ett antal åtgärdsförslag. Dessa åtgärdsförslag utgjordes i detta fall av förslag till riktlinjer för testning. Dessa grundade sig i teori, presenterad i den teoretiska referensramen (avsnitt 2), om mjukvarutestning, testautomation och testprocesser i små företag. Utöver den teoretiska kopplingen lades stor vikt vid att anpassa riktlinjerna efter den aktuella miljön. För att verkligen kunna implementera dessa riktlinjer lades även tid på att skapa en grundlig förståelse för hur testning inom webbutveckling utförs praktiskt sett. Detta inkluderade att ta fram ramverk och verktyg samt att tillsammans med utvecklarna på Webb & Mobilt ta beslut om vilka som skulle användas.
5.2. Fas 2 - Övervägning av förbättringsåtgärder
Webb & Mobilts ursprungliga testprocess var ad-hoc (observation 2) men många utvecklare efterfrågade mer struktur och riktlinjer i testningsarbetet (observation 8). Lösningen på detta var att använda MTPF och anpassa den vid behov. På så sätt fanns en grundläggande struktur att basera processen på.
Applikation av MTPF och teststrategi
Under fas 2 av CMD-metoden gjordes de två första stegen i MTPF:s introduktionsmetod: för- beredelse och introduktion av metoder och praxisar, se figur 2.3. Detta arbete gjordes ihop med utvecklarna för att identifiera vilka delar av MTPF:s nivå 1 som var mer angelägna att ha med från start. Vid den första sprinten bestod utvecklingsteamet endast av två medlemmar. MTPF:s nivå 1 är rekommenderat för utvecklingsteam av cirka 10 medlemmar. Eftersom den nya testprocessen skulle appliceras på ett projekt med endast två utvecklare behövdes vissa delar därför prioriteras bort. I ett första steg identifierades fyra kategorier som foku- sområden: Testplanering, Testadministration, Verifiering & Godkännande samt Roller & Or- ganisation. Den femte kategorin Problem och Erfarenhetsrapportering valdes bort eftersom den fokuserar på rapportering och spårning av buggar vilket ansågs vara den minst kritiska kat- egorin i ett team med endast två medlemmar.
Testplanering
Testplanering inkluderar vilka tester som ska genomföras och när de ska genomföras. För att hålla testningen simpel valdes det att lägga fokus på enhetstester. Det är dock fördelaktigt att diversifiera sin teststrategi med flera metoder och tekniker [28]. Att även ha, till exempel, automatiserade acceptanstester har rapporterats öka kodkvalitet och vara ett bra sätt att upp- täcka brister i kravspecifikationen [21]. På Webb & Mobilt är det dock kunden som ansvarar för acceptanstestning (observation 11) och med målet att inte överbelasta utvecklarna med testningarbete prioriterades acceptanstestning bort. Som diversifieringsteknik valdes istället end-to-end-tester av de programflöden som identifierats som kritiska under sprintplanerin- gen. Stor vikt lades på att börja med automatiseringen tidigt i projektet eftersom det ökar det medförda värdet [56].
För nivå 1 i MTPF:s kategori Testplanering ska en testplan skrivas. Exakt hur detta genomförs är inte specificerat. Eftersom Webb & Mobilt inte hade någon testdokumentation alls sattes målet till en början på att skapa ett utkast till en teststrategi i början av projektet för att ha något att utgå ifrån. Denna teststrategi är tänkt att kunna fungera även för andra liknande projekt och innehåller riktlinjer kring vilka komponenter som ska testas. Utifrån denna test- strategi skapades sedan en testplan för projektet.
Testadministration
För nivå 1 i MTPF:s kategori Testadministration ska en grundläggande testmiljö finnas tillgäng- lig för utvecklarna. I vissa fall skulle detta kunna inkludera fysisk konfiguration av hårdvara att köra testerna på. I Webb & Mobilts fall handlar det istället om att inkludera alla testverk- tyg i projektdefinitionen så att alla utvecklare kan köra testerna på sina egna datorer. Dock fanns ingen testmiljö sedan innan, så det första steget blev att bestämma vilka verktyg som skulle användas och ta reda på hur de behövde konfigureras. Detta utfördes av forskarna inför pilotprojektets start för att låta utvecklarnas tid läggas på att använda och utvärdera processen snarare än att sätta upp testmiljön.
Även om alla utvecklare kan köra testerna själva finns en risk att testerna ändå inte körs tillräckligt ofta. Testsviten blir lätt föråldrad om den inte används [5] och därför bestämdes det att testerna ska köras på en byggserver vid varje pull-request. Detta tvingar utvecklarna
5.2. Fas 2 - Övervägning av förbättringsåtgärder
att hålla testerna uppdaterade samt förhindrar att det läggs tid på att granska kod som inte klarar testerna.
Verifiering och Godkännande
För nivå 1 i MTPF:s kategori Verifiering och Godkännande ska checklistor skapas för vanliga testaktiviteter. I detta fall beslutades att det skulle skapas en checklista för testning av de komponenter som var fokusområde för enhetstestningen.
Något Webb & Mobilt redan beslutat sig införa var kodgranskning. Detta återfinns egentligen först i nivå 3 i MTPF, men inkluderades ändå från början i projektet. Som en grundläggande regel, men inte utan undantag, granskar en annan utvecklare varje pull-request. Detta skil- jer sig något från den sorts kodgranskning som beskrivs i MTPFs senare steg. Där skapas istället särskilda grupper som genomför kodgranskningen. Utvecklarna kände att ett rimligt mellansteg var att hålla kodgranskningen mer informell, men genomföra den ofta.
Roller och Organisation
För nivå 1 i MTPF:s kategori Roller och Organisation ska ansvar fördelas för testning på före- taget. Då processen bara införs under ett pilotprojekt delades inte det ansvar upp på före- tagsnivå. Däremot utnämndes en av utvecklarna i projektet till ansvarig för att testplanen uppdaterades inför varje sprint.
Övriga testrelaterade beslut
Verktyg
Att göra en utförlig utvärdering av tillgängliga testverktyg är inte en del av denna studie. Kombinationen av Jasmine och Karma för enhetstester samt Protractor för end-to-end-tester valdes på två grunder. De är rekommenderade av Angular-teamet själva2och en av de två
initiala team-medlemmarna i projektet hade tidigare positiva erfarenheter av att använda dessa verktyg. Detta motverkar en av de utmaningarna som Rafi et. al. [43] identifierade för testautomatisering: brist på kunskap kring verktygen.
Som källkodskatalog för Git (eng. Git repository) användes redan Visual Studio Team Ser- vices3(VSTS) och det fanns inget intresse från företaget att lägga tid och resurser på att un-
derhålla en egen byggserver. Det föreföll sig därför naturligt att använda VSTS:s hosted agent- lösning. Byggservern underhålls då av Microsoft och kan konfigureras från VSTS-sidan.
Enhetstester i relation till arkitekturen
Som tidigare nämnts var ett viktigt första steg för utvecklarna att börja skriva enhetstester utan att känna att de blir överväldigade med för många riktlinjer och regler för testning. I samtal med utvecklarna valdes därför att fokusera på två delar av arkitekturen till en bör- jan: effekter (eng. effects) och reducers. Se avsnitt 5.1 för en beskrivning av hela arkitekturen. Dessa delar valdes ut av två huvudsakliga skäl: dels är de tydligt separerade från annan funk- tionalitet vilket gör att de inte är beroende av så många andra delar av applikationen, dels är de centrala i applikationens datahantering och därför viktiga att testa. Detta visualiseras i figur 5.2 där reducers och effekter är de delar av applikationen som tar emot meddelanden och avgör vad som ska göras baserat på meddelandets typ. Där ligger följaktligen mycket av logiken för hur applikationen hanterar förändringar.
2https://angular.io/docs/ts/latest/guide/testing.html 3https://www.visualstudio.com/team-services/
5.2. Fas 2 - Övervägning av förbättringsåtgärder
Figur 5.2: Delar av arkitekturen som enhetstestas initialt
Actions, här benämnda meddelanden, är bara meddelandeklasser utan egen funktionalitet och ansågs därför inte kräva egna enhetstester. Enligt utvecklarna tenderar services att vara såpass "tunna" att de inte kräver enhetstester i någon större utsträckning. En typisk service skapar bara ett meddelande och skickar den, utan avancerad logik som behöver testas. Där- för bedömdes de inte vara lika relevanta i enhetstestning. Resources är liknande i att de har ett mycket begränsat ansvar i att sköta kontakten med en specifik del av ett API. Det finns däre- mot en poäng i att skapa integrationstester som till exempel bekräftar att API:t tar hand om alla anrop från applikationen. Utvecklarna uttryckte ett visst intresse för detta, men kände att dessa kunde införas i ett senare skede.
Nästa steg för enhetstester vore att börja testa Angularkomponenter. Särskilt nämnde utveck- larna att de smarta komponenterna tenderar att ha något mer avancerade funktioner som kan vara värda att testa. Dessa tester kräver ofta mer av testmiljön än tester för reducers och ef- fekter. Anledningen är att komponenterna är beroende av Angular för att bland annat kunna rendera html-element och få tillgång till tjänster. Angular tillhandahåller testverktyg för att underlätta detta, men de tar fortfarande något längre tid att skriva och exekvera enligt egen erfarenhet. För att hålla processen lättviktig till en början infördes inte dessa tester i processen initialt.
Resultat från fas 2
Baserat på resonemangen ovan sammanställdes följande lista på åtgärder att genomföra. De är organiserade enligt de fyra MTPF-kategorierna. Efter listan presenteras även hur det dagliga arbetsflödet blev med den nya processen.
MTPF - Testplanering
Utkast till teststrategi för Angular-projekt. Inkluderar motivation och mål med testning inom Exsitec. Innehåller även riktlinjer och exempel kring hur enhetstester och integrationstester kan skrivas.
Testplan. Testplanen är specifik för varje sprint och innehåller vilka user-stories som är kritiska och därför ska ha end-to-end-tester.
5.2. Fas 2 - Övervägning av förbättringsåtgärder
Testmiljö. Uppsättning av testverktyg som kan användas tillsammans, nödvändiga filer för att varje utvecklare ska kunna skriva och köra tester direkt.
Byggserver. Vid en pull-request ska alla automatiserade tester köras och vara godkända av en byggserver innan nästa steg, kodinspektion, genomförs. Vid fall där testen inte är godkända är det upp till utvecklaren att uppdatera koden eller testet beroende på var felet ligger. Detta ser till att testen hålls uppdaterade.
Enhetstester. Enhetstester ska skrivas i så stor utsträckning som möjligt. Enhetstesterna skrivs i testramverket Jasmine och körs med hjälp av Karma.
Integrationstester. Inför varje sprint väljs kritiska användarflöden ut och end-to-end-tester skrivs för dem. Protractor används för detta ändamål.
Ad-hoc testning. Vid upplevt behov sker manuell testning. Detta gäller framförallt visuella aspekter av applikationerna.
MTPF - Verifiering och Godkännande
Checklistor. Som ett stöd vid skrivandet av enhetstester används checklistor som beskriver vilken funktionalitet som ska testas.
Kodinspektioner. Enligt MTPF är kodinspektioner en del av nivå 3, men det fanns en vilja från Webb & Mobilt att införa en sorts lätta inspektioner vid pull-requests. Ifall en pull-request gått igenom alla tester ska koden granskas av en annan utvecklare som utgår ifrån en checklista med punkter att kolla efter. Vid en lyckad inspektion blir det en godkänd pull-request.
MTPF - Roller och Organisation
Testplan. Det ska finnas en ansvarig person för att en testplan skapas för varje sprint.