Linköpings universitet
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på avancerad nivå, 30hp | Datateknik
2017 | LIU-IDA/LITH-EX-A--17/020--SE
En
testprocess
för
webb-utvecklingsprojekt med små
team
Developing a test process for web development projects in
small teams
Ludwig Wikblad
Mikael Ögren
Handledare : Jonas Wallgren Examinator : Ola Leifler
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Ludwig Wikblad Mikael Ögren
Abstract
Att hitta ett lämpligt tillvägagångssätt för att utföra testning i små utvecklingsteam är en utmaning. Många små företag upplever traditionella testprocesser och testförbät-tringsprocesser som alltför resurskrävande. Minimal Test Practice Framework (MTPF) är ett ramverk för testning vars syfte är att tillhandahålla ett minimalistiskt tillvägagångssätt för testförbättring. Målet med denna studie var att undersöka hur MTPF kan imple-menteras och anpassas till ett litet utvecklingsteam utan att den medför en för stor tidsin-vestering. Studien utfördes på avdelningen Webb & Mobilt i företaget Exsitec där team om 2-6 personer utvecklar webbapplikationer till företagskunder. I nära samarbete med utvecklarna på avdelningen togs en testprocess fram med målet att den skulle anpassas till verksamheten i så stor utsträckning som möjligt. Studien genomfördes som aktions-forskning i tre faser utefter Cooperative Method Development i ett projekt med två utveck-lare. Under studiens första fas intervjuades alla utvecklare på avdelningen för att skapa en grundförståelse för verksamheten. Under den andra fasen togs ett antal förbättringsförslag fram tillsammans med utvecklarna. Under den tredje fasen infördes och utvärderades dessa förbättringar. Genom att fokusera på enhetstestning av central affärslogik i app-likationen uppnåddes en testprocess som gav utvecklarna ett ökat förtroende för kodens kvalitet utan att upplevas som för resursintensiv.
Finding a suitable approach for testing in small development teams is a challenge. Many small companies view traditional test processes and test process improvement models as too resource intensive for their needs. Minimal Test Practice Framework (MTPF) is a frame-work for testing which purpose is to provide a minimalistic approach to test improvement. The goal of this study was to examine how MTPF can be adapted to a small development team without incurring a time cost that the team would experience as too high. The study was performed in the department Web & Mobile of the company Exsitec. At the depart-ment teams of 2-6 people develop web applications to business customers. During the study a testprocess was developed in close cooperation with the developers of the depart-ment with the aim of adapting it as well as possible to the needs of the departdepart-ment. The study was performed as action research in three phases, according to the method Coop-erative Method Development, in a project with two developers. During the first phase all developers in the department were interviewed to establish an understanding of the environment for the study. During the second phase a set of possible improvements was developed together with the developers. During the third phase some of these improve-ments were implemented and evaluated. By focusing on unit testing central business logic in the application the developed test process improved the developers confidence in the code quality without being perceived as too resource intensive.
Författarnas tack
Vi vill passa på att tacka alla fantastiska utvecklare på Exsitecs avdelning Webb & Mobilt som varit tillmötesgående under hela studien. Särskilt tack riktas till vår handledare Eric Johansson som bidragit med mycket vägledning och hjälp på vägen. Vi vill även tacka vår handledare Jonas Wallgren och vår examinator Ola Leifler för deras insikter och feedback under hela studiens gång. Slutligen vill vi rikta ett tack till våra opponenter Arvid Johnsson och Erik Malmberg, för all värdefull och konstruktiv kritik.
Innehållsförteckning
Sammanfattning iii Författarnas tack iv Innehållsförteckning v Figurförteckning vii Tabellförteckning 1 1 Inledning 2 1.1 Motivation . . . 2 1.2 Bakgrund . . . 3 1.3 Syfte . . . 3 1.4 Frågeställningar . . . 3 1.5 Avgränsningar . . . 3 2 Testteori 4 2.1 Testnivåer . . . 4 2.2 Agil utveckling . . . 52.3 Testning i agila projekt . . . 6
2.4 Testautomation . . . 7
2.5 Test av webbapplikationer . . . 8
2.6 Att utveckla en testprocess . . . 10
2.7 Minimal Test Practice Framework . . . 10
2.8 Effekter av testning . . . 13
2.9 Relaterade arbeten . . . 16
3 Metodteori 23 3.1 Forskningsmetodik . . . 23
3.2 Cooperative Method Development . . . 24
3.3 Fallstudier . . . 26
3.4 Intervjuer . . . 27
4 Metod 28 4.1 Metodval . . . 28
4.2 Fas 1 - Förståelse för verksamheten . . . 29
4.3 Fas 2 - Övervägning av förbättringsåtgärder . . . 30
4.4 Fas 3 - Implementation och observation av förbättringsåtgärderna . . . 31
4.5 Slututvärdering . . . 32
4.6 Uppföljning . . . 32
5.1 Fas 1 - Förståelse för verksamheten . . . 34
5.2 Fas 2 - Övervägning av förbättringsåtgärder . . . 37
5.3 Fas 3 - Implementation och observation av förbättringsåtgärder . . . 44
5.4 Slututvärdering . . . 48
5.5 Uppföljning . . . 52
6 Diskussion 55 6.1 Resultat . . . 55
6.2 Metod . . . 59
6.3 Arbetet i ett vidare sammanhang . . . 61
6.4 Framtida arbete . . . 62 7 Slutsatser 63 Bibliography 65 A Intervjufrågor - Fas 1 70 A.1 Uppvärmningsfrågor . . . 70 A.2 Huvudfrågor . . . 70 B Frågor/Diskussionspunkter - Slututvärdering 72 B.1 Införande . . . 72 B.2 Allmänt . . . 72 B.3 Testkvalitet . . . 72 B.4 Produktkvalitet . . . 73
B.5 Tid och andel testning . . . 73
B.6 Arbetsprocessen . . . 73
B.7 Utvärdering av dokumenterade processen . . . 73
B.8 Automation . . . 74
B.9 Avslutande . . . 74
C Frågor/Diskussionspunkter - Uppföljningsmötet 75 C.1 Processen . . . 75
C.2 Effekter . . . 75
C.3 Återkoppling till observationer från fas 1, stämmer de fortfarande? . . . 75
Figurförteckning
2.1 De olika testnivåerna . . . 5
2.2 En överblick över MTPF-modellen. Anpassad från Karlström, Runeson och Nordén [Karlstrom2005] . . . . 11
2.3 Flödesschema över MTPF:s introduktionsmetod. Anpassad från Karlström, Rune-son och Nordén [Karlstrom2005] . . . . 12
4.1 Intervjuprocessen. Anpassad från Karlström och Runeson [Karlstrom2006] . . . . 30
4.2 Flödesschema fas 3 . . . 31
5.1 Arkitektur över frontend i Exsitecs Angular-applikationer . . . 37
5.2 Delar av arkitekturen som enhetstestas initialt . . . 40
5.3 Det nya arbetsflödet. Röda aktiviter är testrelaterade . . . 43
5.4 Testrapport i VSTS . . . 46
5.5 Det faktiska arbetsflödet. Röda aktiviter är testrelaterade . . . 48
5.6 Historik över antal misslyckade testfall och andel lyckade testfall mellan 2017-05-09 och 2017-06-07 . . . 53
Tabellförteckning
2.1 Överblick av tillvägagångssätt . . . 21 4.1 Exempel på hur en tabell kan struktureras för att använda tabulering . . . 31 5.1 Överblick av observationer, relaterad teori och dragen slutsats. . . 44
1
Inledning
Denna studie genomfördes som ett examensarbete på masternivå vid Linköpings Universitet. I det här kapitlet introduceras läsaren till de ämnen som behandlas i rapporten och en kort bakgrund till arbetet ges.
1.1
Motivation
Testning är en etablerad del av mjukvaruutveckling, men i små företag är det lätt hänt att det nedprioriteras på grund av deadlines och tidsbrist [40]. Mjukvarutestning kan i sin enklaste form definieras som "processen att exekvera ett program med intentionen att hitta fel" [42, sida 11]. Att genomföra testning är viktigt för att kunna leverera en produkt av hög kvalitet [43]. Att detta sker på ett strukturerat sätt som hittar felen så tidigt som möjligt är också viktigt då det visat sig att det kan kosta upp till fem gånger så mycket att åtgärda ett fel som upptäckts i ett projekts slutfas jämfört med under projektets start [7].
Mycket forskning har utförts inom mjukvarutestning, men nya tekniker ställer ständigt nya krav på testprocesser. Det är inte trivialt för företag att hitta lämpliga metoder för att förbättra testningen även om de vill. Detta utgör en särskild utmaning i mindre företag där resurserna för processutveckling är begränsade [40]. I denna studie utgår vi från utvecklarnas perspektiv och undersöker hur en strukturerad testprocess som införs steg för steg i det dagliga arbetet kan underlätta utvecklingsprocessen.
Det finns flera metoder för att förbättra testprocesser, till exempel Test Maturity Model [6], Test Process Improvement [36] och Test Improvement Model [16]. Dessa är dock resursinten-siva och är inte anpassade för små och medelstora företag [19, 31, 45]. För att möta behovet från mindre företag utvecklades Minimal Test Practice Framework [31], MTPF, som denna studie utgår ifrån. I en fallstudie av Martin et. al. [40] undersöktes hur organisationens behov påverkar testprocessen och vilka kompromisser ett mindre IT-företag måste göra när komplicerade testprocesser ska integreras i en miljö där tiden är begränsad och resurserna knappa. Vi hoppas att detta arbete, i enlighet med den önskan om mer forskning i liknande miljöer som Martin el. al. framförde, kommer att bidra till ytterligare insikter inom området.
1.2. Bakgrund
1.2
Bakgrund
Exsitec är ett IT-konsultbolag som arbetar med affärssystem. Företaget delar upp sin verk-samhet i de tre områdena Affärssystem, Beslutsstöd och Webb & Mobilt. Det är på Webb & Mobilt denna studie utfördes. Avdelningen arbetar i agila projekt och utvecklar huvudsak-ligen kundanpassade webbapplikationer som agerar gränssnitt gentemot kundens affärssys-tem. Projekten varierar mellan kortare anpassningsprojekt av befintliga programvarupro-dukter på under 100 timmar till storskaliga projekt över cirka 1,5 år och 3500 timmar. Ofta sker projekt på Webb & Mobilt parallellt med implementationsprojekt på andra avdelningar. Utvecklingen sker främst i mindre team av 2-6 personer som jobbar i det JavaScript-baserade ramverket Angular 2 för frontend. Backend/server skrivs i .NET och utgör ett API för fron-tendapplikationen att kommunicera med. Testning av frontend har hittills skett manuellt och ad-hoc. Detta är avdelningen intresserad av att förändra genom en övergång till en mer strukturerad testprocess.
1.3
Syfte
Till och med MTPF, som är utvecklat för små företag, räknar med att små team är 10 personer. I denna studie fokuserar vi på ännu mindre team, med endast 2-6 medlemmar, och under-söker vilka anpassningar som behöver göras för att möta deras behov. Under studien kom-mer en testprocess för webbapplikationer utvecklas, införas och utvärderas gemensamt med utvecklarna på en liten utvecklingsavdelning. Testprocessen kommer att utgå ifrån MTPF och anpassas enligt de problem utvecklarna upplever och vill lösa. Målet är att på så sätt förbättra testningsarbetet på Webb & Mobilt. Studien syftar till att undersöka vilka effekter som uppnås av en testprocess som får växa fram steg för steg, grundad i en befintlig modell men driven av utvecklarnas behov och önskemål. Studien syftar även till att undersöka vilka förändringar som behöver göras av MTPF för att uppfylla de krav som ställs i den aktuella miljön.
Processen utvecklas och förbättras iterativt under ett pilotprojekt för att sedan utmynna i ett antal riktlinjer för hur testning bör ske på avdelningen. Genom att jobba nära utveck-larna under hela studien är målet att resultatet är väl förankrat i både organisationen och rådande teori. Utvärderingen av processen sker ur utvecklarnas perspektiv och görs kvalita-tivt baserat på hur utvecklarna upplever att arbeta i den nya processen.
1.4
Frågeställningar
1. Hur kan Minimal Test Practice Framework anpassas för små webbutvecklingsteam så att den utgör ett strukturerat arbetssätt som ger utvecklarna ett större förtroende för kodens kvalitet och inte innebär en tidsinvestering utvecklarna upplever som för stor? 2. Ur en utvecklares perspektiv, vilka fördelar och nackdelar medför den framtagna
test-processen?
Med små utvecklingsteam avses team av 2-6 personer.
1.5
Avgränsningar
Studien inkluderar endast ett företag och en testprocess. Processen jämförs inte mot andra processer mer än på ett teoretiskt plan och dess effektivitet utanför det aktuella företaget har inte undersökts. Studien rör endast testning av frontendkod, testprocesserna för serversidan behandlas inte.
2
Testteori
I detta avsnitt presenteras rådande teori i området testning för att bilda en grund för resten av studien. En kort introduktion ges även till agil utveckling.
2.1
Testnivåer
Mjukvarutestning delas vanligen in i fyra olika nivåer: enhets-, integrations-, system- och acceptanstester. Dessa illusteras i figur 2.1, och sammanfattas av Copeland [11] som följande:
• Enhetstester är små, isolerade tester som skapas för enskilda metoder eller klasser. De är relativt lätta att skriva och det är ofta dessa det finns flest av i automatiserade testsviter. De utgör således den breda grunden i testningspyramiden i figur 2.1. • Integrationstester är något större tester som syftar till att testa enheter (klasser eller
moduler) tillsammans för att verifiera att de interagerar med varandra som de ska. Även om alla enheter fungerar som de ska i isolering kan problem uppstå när sys-temet sätts samman, och det är detta integrationstester är till för att upptäcka. Inte-grationstester finns av många storlekar då de kan bestå av allt från två komponenter som testas tillsammans, ända upp till i princip alla komponenter i hela systemet. • Systemtester kan ses som integrationstester på den högsta nivån. De är ytterligare lite
större och mer omfattande tester som sker genom att testa alla delar av systemet till-sammans. Detta gör dem ännu lite mer tidskrävande att skriva vilket leder till att det ofta finns ännu färre av dem i automatiserade testsviter.
• Acceptanstester är en serie av tester som ofta görs av kunden själv. Ett lyckat genom-förande innebär att kunden kommer att acceptera produkten som färdig. Dessa tester utvärderar systemet i sin helhet, av den tilltänkta målgruppen, i den tilltänkta miljön. Detta gör att de är relativt dyra att genomföra men kan ge väldigt detaljerad feedback. De utgör således den smala toppen av testningspyramiden.
2.2. Agil utveckling
Ytterligare en term som förekommer när det gäller testnivåer är end-to-end tester, ofta för-kortat till e2e-tester1. Dessa tester sker på samma nivå som systemtester men fokuserar på att testa flöden genom applikationen. Detta ska simulera användarmönster för riktiga slutan-vändare i den tilltänkta miljön och bör således innefatta riktiga databaser, servrar och front end för att testa systemet i sin helhet. Det saknas en erkänd, officiell definition av e2e-tester, men denna beskrivning stämmer överens med hur uttrycket används i industrin.
Figur 2.1: De olika testnivåerna
2.2
Agil utveckling
Agil utveckling, som beskrivet i The Agile Manifesto2, har införts på bred front i mjukvaruin-dustrin [56]. Agila metoder uppstod som ett svar på tunga, processorienterade utvecklings-metoder på 90-talet. De är skapade för att hantera förändring genom att utvecklingsprocessen sker iterativt och planeringsarbetet sköts för några veckor i taget. Iterativt betyder ungefär upprepande, vilket kommer ifrån att processen inte har många olika steg som följer varan-dra, utan istället har ett och samma steg som istället upprepas tills produkten kan anses klar eller tiden är slut. För varje sådan iteration ska en någorlunda fungerande produkt kunna levereras. Detta gör att komponenter ständigt behöver integreras, och testning sker löpande under hela projektet. En effekt av de kontinuerliga leveranserna är att tid och kostnad lättare kan styras, för oavsett när projektet tar slut kommer det finnas en färdig produkt. [14] En av principerna bakom agil utveckling är att motiverade individer utgör grunden i bra projekt och de bör få det utrymme och resurser de behöver för att göra ett bra jobb. Agil utveckling sätter således stor tilltro till individer då allt arbete sker i självorganiserande team, kommunikation sköts öga mot öga, dokumentation minimeras till det nödvändigaste och utvecklingsteamet har direkt kontakt med kunden. [4]
SCRUM är en av de vanligaste agila metoderna [56]. Iterationerna i SCRUM kallas sprintar, och inför varje sprint planeras vilka uppdrag som ska utföras. Dessa uppdrag är skapade i
1https://www.techopedia.com/definition/7035/end-to-end-test 2http://agilemanifesto.org/
2.3. Testning i agila projekt
form av user-stories, kortfattade berättelser om vad olika användare kan tänkas vilja kunna göra med produkten. Dessa user-stories hämtas från en så kallad backlog som är en lista med de user-stories som ska utföras under hela projektet. Produktägaren har ansvar för denna backlog. Detta ansvar innebär att skapa och prioritera ordningen på user-stories. Utöver produktägaren är två ytterligare roller definierade: SCRUM-master och teammedlem. SCRUM-mastern är teamets SCRUM-expert och har en stödjande, men inte styrande, roll. Teammedlemmarna är alla andra i gruppen och ansvarar själva för att åta sig user-stories och färdigställa dem. [51]
Continuous Integration och versionshantering
Ett versionshanteringssystem som Git eller SVN ligger ofta till grund för utvecklingen i mjuk-varuföretag. Det är ett sätt att hantera de olika versioner av programvaran som uppstår när flera utvecklare jobbar på samma produkt samtidigt. När utvecklare vill börja jobba på en ny funktionalitet skapar de ofta en ny så kallad branch. Denna branch utgår från den senaste gemensamma versionen av kodbasen, och utvecklaren uppdaterar sin branch löpande under utvecklandet av den nya funktionaliteten. När funktionaliteten är klar behöver branchen in-tegreras med den gemensamma koden. Om ingen annan gjort ändringar blir detta enkelt då den gemensamma versionen bara behöver uppdateras med de förändringar utvecklaren gjort. Om någon annan däremot har hunnit ändra koden måste utvecklaren nu göra en så kallad merge, en sammanslagning av två brancher. Detta görs för att bevara alla förändringar som alla utvecklare gjort. [8, Kapitel 1]
Versionshanteringssystem kan konfigureras så att endast en eller ett fåtal utvecklare har be-hörighet att göra ändringar i gemensamma centrala brancher. Om detta är fallet kan andra utvecklare skapa ett pull-request då de jobbat klart på sin branch. Detta är ett sätt att noti-fiera de som har rätt behörighet om att det finns ändringar som någon vill integrera i den gemensamma branchen. [8, Kapitel 5]
En vanlig del av agil utveckling är Continuous Integration, ofta förkortat till CI. Grunden i CI är att integrera koden alla utvecklare skriver i ett projekt, löpande under projektets gång snarare än i slutskedet. Ofta sker denna typ av integration till och med flera gånger om dagen. Motivet bakom denna praxis är att undvika de problem som uppstår när kod som utvecklats separat i månader, kanske år, ska integreras och börja fungera tillsammans. Ofta används en byggserver, även kallad continuous integration server eller CI server, för att underlätta arbetet med CI. Det är en server som har tillgång till källkoden för projektet och kan bygga projektet och köra testsviter då kodbasen uppdateras. Att testerna körs på en byggserver gör att alla utvecklares kod måste köras på samma maskin innan den kan kallas färdig. Detta minskar riskerna för fel som uppstår på grund av olikheter mellan miljöerna hos de olika utvecklarna. [17]
2.3
Testning i agila projekt
Behovet av testning finns i agil utveckling såväl som i traditionell utveckling, men det ställs nya krav på testning i en agil miljö. Den iterativa livscykeln gör att testning integreras tidigare i utvecklingen, och kontinuerliga leveranser gör att funktionalitet bör testas och verifieras i samma iteration som de utvecklats i. Ytterligare utmaningar härstammar från att kravspeci-fikationer kontinuerligt förändras under arbetets gång i agila projekt. Detta gör att testerna behöver hänga med i förändringarna. [56]
Efter en studie av ett utvecklingsprojekt definierade van den Broek, Bonsangue och Chaudron [56] ett antal rekommendationer för införandet av testning i projekt som följer SCRUM. Dessa rekommendationer inkluderade bland annat följande.
2.4. Testautomation
• Ha en “Sprint 0”
Genom att hålla en kortare sprint innan själva utvecklingsarbetet kan bl.a. teststrategier utvecklas.
• Använd hela gruppen
Sträva efter att behålla alla gruppmedlemmar, inklusive en testare, under hela projektet. Även om testning ska genomföras av alla gruppmedlemmar är en dedikerad testares kompetens viktig för produktkvalitén.
• Automatisera testningen tidigt
Om projektet ska använda sig av automatisk testning bör den sättas upp så tidigt som möjligt för att leverera största möjliga värde.
Angående den sista punkten är det inte självklart att det är värt att automatisera testprocessen i alla projekt. Till exempel kan projekt vara för korta eller för fokuserade på design av grafiska användargränssnitt för att en investering i testautomation ska betala av sig. [56]
2.4
Testautomation
Testautomation har hyllats för att öka kodkvaliteten genom att göra tester billigare att köra, och det sägs vara mindre tidskrävande än manuella tester [13]. Automatiska tester kan köras ofta och på så sätt användas för att säkerställa att kod som fungerat tidigare inte slutat fungera efter införda förändringar, så kallad regressionstestning [29].
Vad som kan automatiseras
Processen för att framställa testfall kan sägas bestå av fyra generella steg, även om processen är långt ifrån identisk mellan olika miljöer och utvecklare. Testautomation kan gälla flera delar av testprocessen, även om vissa delar är vanligare än andra att automatisera. [3]
1. I första steget designas testfallen. Detta inkluderar att ange input och förväntat resultat. 2. I andra steget skapas testskript. Designen kanske bara är skriven i textdokument, i så
fall översätts dessa till kod för varje testfall i detta steg. 3. Det tredje steget är att genomföra, eller köra, testfallen.
4. Det fjärde steget, tätt kopplat till steg tre, är att utvärdera om systemet som testas fak-tiskt fungerade som väntat och gav det resultat som specificerats i designfasen.
Det finns metoder för att automatisera de två första stegen, t.ex. genom att generera testfall från kravspecifikationer, men det är relativt ovanligt. De två sista stegen är de som är lättast och vanligast att automatisera.[3]
När automation är lämplig
Automatiska tester är ingen universallösning på alla testningsproblem. Karhu et. al [29] fann att det finns empiriskt stöd för att automatisering kan ge högre kodkvalitet och lägre kostnader per test. Däremot introduceras nya kostnader i form av underhåll av testsviter, utbildningar och uppsättningskostnader. Dessutom finns ett antal faktorer för att en mjuk-varuprodukt ska vara lämplig att skriva automatiska tester för:
• Produkter som är standardiserade mellan kunder underlättar automation.
2.5. Test av webbapplikationer
• Återanvändning av komponenter mellan produkter underlättar automation.
I en empirisk studie undersökte Kusurinen, Taipale och Smolander [34] hur testautomation används i utvecklingsprojekt inom ett flertal affärsområden. De fann att samma faktorer som Karhu et. al. [29] tar upp påverkar när testautomation är lämpligt. Utöver dessa faktorer poängterar de även vikten av att utvärdera kostnader för implementationen av testautoma-tion gentemot de fördelar som förväntas uppstå oavsett projektets natur.
Utöver att bestämma vilka projekt som lämpar sig för testautomation måste utvecklarna även identifiera vilka tester som ska automatiseras och vilka som bör skötas manuellt. Automa-tiska tester är främst lämpade för att verifiera existerande funktionalitet och kvalitet, snarare än att upptäcka okända fel [34]. Detta diskuteras ytterligare nedan.
Manuell eller automatisk testning
Automatisk testning kan inte till fullo ersätta manuell testning [43]. Det kan dock vara svårt att bestämma vilka tester som ska automatiseras och vilka som bör skötas manuellt. Enligt Stobie [54] är det enkla svaret "det beror på". De tre viktigaste faktorerna att ta hänsyn till är enligt Stobie:
1. Systemets förändringstakt. En hög förändringstakt innebär höga underhållskostnader för en automatiserad testsvit.
2. Testkörningsfrekvensen. Hur ofta körs testen? Ifall ett test behöver upprepas ofta är automatiserad testning mer kostnadseffektivt. Det är dock inte rimligt att alltid upp-repa alla tester och det är därför viktigt att utvärdera hur pass viktigt testresultatet är och hur kostsamt det är att ta reda på det.
3. Nyttan av automation. Bidrar testet med någon sorts framtida värde? Kan det till exempel hjälpa till att hitta regressioner (återkommande defekter) eller latenta (ännu ej hittade) buggar?
I en förenklad form ger Stobie även tre tumregler kring vad som bör automatiseras:
• Enhetstester är enkla tester som körs ofta och har vanligen en låg underhållskostnad. Därför bör de automatiseras.
• Systemtesters kostnader vägs ofta upp av antalet gånger de exekveras. Detta tillsam-mans med att denna typ av tester eftersträvar att få samma resultat varje gång och dess måttliga kostnader gör att de bör automatiseras.
• Användbarhetstester är nästintill omöjliga att automatisera, har inte samma behov av att upprepas och för med sig höga underhållskostnader. Denna typ av tester bör därför genomföras manuellt.
2.5
Test av webbapplikationer
Webbapplikationer skiljer sig från traditionell mjukvara på några punkter. Webbapplika-tioner bygger ofta på både en server (backend) och en klient (frontend). Detta innebär olika miljöer, olika språk, olika ramverk etc. Bara klienten består i sin tur av både html, CSS och JavaScript som interagerar med varandra. Detta medför problem för helt integrerade test-metoder eftersom de måste stödja alla dessa språk. Webben är dessutom en mycket öppen
2.5. Test av webbapplikationer
miljö vilket resulterar i att webbapplikationer kan komma att köras med väldigt varierande förutsättningar. Hårdvaran (skärmstorlek, processorkraft etc.) beror helt på slutanvändarens utrustning och mjukvaran skiljer sig åt då olika webbläsare implementeras på lite olika sätt. Webbapplikationer används också generellt av många användare åt gången, vilket ställer särskilda krav på servern jämfört med en desktopapplikation. Slutligen kan nämnas att utvecklingstakten bland ramverk för webbapplikationer är synnerligen hög. Detta medför utmaningar för testningsteknologier eftersom de är beroende av gränssnitt och API:er som ofta förändras. [39]
Traditionellt har affärslogiken främst legat i backend, men idag återfinns mer och mer logik i frontend. Detta gör till exempel att enhetstester av JavaScript på en funktionell nivå blivit relevant. Det gör också att tekniker som bygger på att spela in handlingar och sedan automa-tiskt spela upp dom igen inte är lika pålitliga längre. Detta då innehållet är mer dynamiskt och föränderligt än tidigare då det främst var statisk datapresentation. [39]
Verktyg
Det finns ett flertal testverktyg som kan användas för JavaScript-applikationer. Nedan pre-senteras ett urval av verktyg som är vanliga vid testning av Angular-applikationer. De testverktyg som rekommenderas av Angular-teamet själva3är Jasmine, Karma och Protractor
Jasmine
Jasmine4är ett ramverk för att enhetstesta JavaScript-kod som tillhandahåller redskapen för att skriva testerna. Det är möjligt att enbart använda sig av Jasmine men det är betydligt enklare att ta hjälp av en testkörare, till exempel Karma.
Karma
Karma5är en testkörare, skapad av Angular-teamet, som möjliggör att köra JavaScript-tester på webbläsare som Chrome eller PhantomJS. Karma sköter exekveringen av testen samt in-samling och presentation av resultaten.
Protractor
Protractor6är ett ramverk för end-to-end-tester anpassade för Angular-applikationer. Det använder sig av Selenium Webdriver för att simulera användarinteraktion i en webbläsare och möjliggör testandet av Angular-specifika element.
PhantomJS
PhantomJS7 är en webbläsare utan grafiskt gränssnitt. Den används för att köra enhets-tester utan att behöva starta ett faktiskt webbläsarfönster. Detta kan vara fördelaktigt av prestandaskäl och när testen behöver köras på en byggserver som inte har stöd för grafiska gränssnitt.
TSLint
TSLint8är ett verktyg för statisk analys av TypeScript-kod, ett superset av JavaScript. Den analyserar koden utan att köra den och söker efter vanliga misstag eller brott mot de
kod-3https://angular.io/docs/ts/latest/guide/testing.html 4https://github.com/jasmine/jasmine 5https://karma-runner.github.io/ 6http://www.protractortest.org 7http://phantomjs.org/ 8https://github.com/palantir/tslint
2.6. Att utveckla en testprocess
konventioner som bestämts för projektet. Den kan användas som ett plugin i kodeditorn för att få kontinuerlig feedback under utvecklingens gång eller köras på ett projekt från ett terminalfönster och generera rapporter på upptäckta fel.
2.6
Att utveckla en testprocess
Sannolikheten att lyckas skapa en perfekt testprocess på första försöket är minimal. Det finns oändligt många sätt att skapa en teststrategi, så det gäller att hitta en som passar det aktuella projektet. [28, Kapitel 11] För att till slut uppnå en process anpassad till verksamheten bör den regelbundet utvärderas efter de mål som satts upp [5]. Vid utvecklandet av en testprocess är det följaktligen viktigt att ha tydliga mål för vilken funktion den ska uppfylla. Framförallt bör alla delar i en teststrategi kunna motiveras med vilka risker de motverkar och hur mycket resurser som ska läggas på varje del. [28, Kapitel 11]
Tydliga mål är något även Berner [5] betonar i sin modell för att utveckla processer för tes-tautomation. Det ska finnas tydliga mål vad gäller teststrategin i stort, baserade på organ-isationens kvalitetsmål och testobjektets egenskaper. Det ska också sättas specifika mål för testautomationen angående vad det är organisationen vill uppnå med den.
Det är fördelaktigt att diversifiera sin teststrategi med olika metoder och tekniker[5]. Detta innebär i praktiken att det är bättre att lägga lite tid på flera olika tekniker istället för att lägga mycket tid på en enda. Grundidén är att testtekniker uppvisar avtagande avkastning (eng. diminishing returns) vilket innebär att det slutar vara effektivt att lägga mer tid på en teknik efter en viss punkt. Olika testtekniker tenderar dessutom att hitta olika sorters fel, och att begränsa sig till endast en eller ett fåtal tekniker riskerar därför att lämna relativt enkla fel oupptäckta. [28, Kapitel 11]
2.7
Minimal Test Practice Framework
I likhet med Gruner och van Zyl [20] och Martin et. al. [40] har även Karlström, Runeson och Nordén [31] uppmärksammat problemet att de vanliga metoderna för testförbättring är för omfattande för att kunna anammas av små och medelstora företag. De menar framförallt, likt Gruner och van Zyl [20], att testdokumentationen är för utförlig och att mindre före-tag istället för dokumentation förlitar sig på personalens kunskap och erfarenheter. De har därför utvecklat ett minimalistisk ramverk för testning med målet att ta hänsyn till den situ-ation som råder på mindre företag. Ramverkat kallas för Minimal Test Practice Framework (MTPF). MTPF är uppdelat i fem olika kategorier och tre olika nivåer, vilka kan liknas vid mognadsnivåer. De olika kategorierna är:
• Problem- och erfarenhetsrapportering. Hur den systematiska rapporteringen och hanterin-gen av problem och erfarenheter i projektet rapporteras.
• Rollrelaterade och organisatoriska frågor. Hur organisationen formats för testning och vilka testrelaterade roller som fastställts.
• Verifiering och godkännande. Vilka aktiviteter som genomförs för att verifiera och god-känna produkten.
• Testadministration. Förvaltandet av testmiljön.
• Testplanering. Planeringen av testrelaterade aktiviteter.
De olika nivåerna är uppdelade efter storleken på företagets utvecklingsavdelning och varje nivå innehåller olika metoder och praxisar som organisationen rekommenderas att anamma
2.7. Minimal Test Practice Framework
i varje kategori. Nivå 1 är lämplig för utvecklingsavdelningar med runt 10 anställda, nivå 2 är för cirka 20 anställda och nivå 3 är för 30 eller fler anställda. Dessa gränser är riktlinjer och det är upp till organisationen själv att bestämma när de är redo att gå vidare till nästa nivå. Figur 2.2 ger en överblick över MTPF. [31]
Figur 2.2: En överblick över MTPF-modellen. Anpassad från Karlström, Runeson och Nordén [31]
MTPF innehåller även en introduktionsmetod som består av fem steg och syftar till att vä-gleda organisationen vid införandet av modellen. De fem stegen är förberedelse, introduk-tion, omarbetning, utförande och utvärderande. Karlström, Runeson och Nordén har illustrerat introduktionmetoden i ett flödesschema (se figur 2.3). Inom den streckade rutan sker det dagliga arbetet vilket innebär av man kontinuerlig utvärderar och, om nödvändigt, omarbe-tar metoder och praxisar. Det är när det vid en utvärdering bestämts att organisationen är redo för nästa nivå som man går tillbaka till förberedelsesteget. I detta steg förbereds allt som behövs för introduktionssteget. Detta kan innebära testmiljöer, träningsmaterial eller testplan. Introduktionssteget består av att presentera de nya metoder och praxisar som nivån innebär för de anställda. De metoder och praxisar som ingår i varje kategori för varje nivå beskrivs nedan. [31]
2.7. Minimal Test Practice Framework
Figur 2.3: Flödesschema över MTPF:s introduktionsmetod. Anpassad från Karlström, Rune-son och Nordén [31]
Problem- och erfarenhetsrapportering
Nivå 1 - Definiera syntax. På den första nivån sker ingen officiell rapportering. Istället läggs fokus på att etablera en syntax för att beskriva problem. Detta för att utvecklare och testare lättare ska göra sig förstådda genom att använda sig av ett gemensamt språk.
Nivå 2 - Skapa system. På denna nivå introduceras ett faktiskt system för att rapportera och hantera problem. Systemet ska använda syntaxen som skapades på nivå 1. I övrigt ska rutiner för att använda systemet etableras.
Nivå 3 - Underhålla och utveckla systemet. Arbete med att hålla systemet uppdaterat för att hantera nya typer av problem som företaget stöter på.
Roller och organisation
Nivå 1 - Definiera ansvar. Det ska göras klart vem som bär ansvaret för de olika testrelater-ade ansvarsområdena. Till exempel att underhålla testmiljön, utveckla en testplan och att uppdatera checklistor.
Nivå 2 - Definiera roller. Det är ett flertal roller som ska etableras på denna nivå. Det ska finnas en testledare och utnämnda utvecklare samt testare. Det är flera personer som utför testning och bland deras ansvarsområden ingår bland annat att genomföra "walkthroughs", ta fram testfall och att underhålla rapporteringssystemet.
2.8. Effekter av testning
Nivå 3 - Definiera team. På den sista nivån ska det finns ett dedikerat testteam som är separerat från utvecklingen. De olika medlemmarna av testteamet ska tydligt beskrivas. Detta tillåter individuella medlemmar att specialisera sig på olika typer av testning.
Verifierande och godkännande
Nivå 1 - Använd checklistor. Det ska finns checklistor som används vid viktiga testaktiviteter, till exempel GUI-testning.
Nivå 2 - Genom "walkthroughs". En walkthrough är en semi-strukturerad genomgång av mjuk-varan där det finns möjlighet för deltagarna att ge input. Dessa ska helst göras under design-fasen. Deltagarna ska främst bestå av designers och utvecklare, men en testare bör delta för att kunna ge testrelaterade kommentarer.
Nivå 3 - Genomför inspektioner. Inspektioner är mer formella än walkthroughs då de följer en förutbestämd process. På nivå 3 ersätter de oftast walkthroughs och genomförs av ett inspek-tionsteam. På denna nivå måste rutiner och ansvarsområden relaterade till inspektionerna etableras.
Testadministration
Nivå 1 - Grundläggande förvaltning av testmiljön. Testmiljön ska finnas tillgänglig för använd-ning.
Nivå 2 - Testfall. Att utveckla testfall är en tidskrävande process och behöver därför göras av flera testare. Syftet är att se till att de vanligaste situationerna och mekanismerna testas. Nivå 3 - Riskhantering. Vid början av projektet ska potentiella riskområden identifieras för att kunna undvika, eller minska, deras inverkan. För ett detta ska fungera är det viktigt att det finns en välorganiserad databas och rapporteringssystem för att hålla kolla på rapporterade problem.
Testplanering
Nivå 1 - Testplan. En testplan som innehåller all testrelaterad dokumentation ska skapas. En viktigt del av testplanen är att skapa milstolpar för projektet.
Nivå 2 och 3 - Koordinera kvalitetsäkran. Det ska finnas rutiner för kvalitetssäkran för att säker-ställa att mjukvaran inte når kunden innan det uppnått en viss nivå av kvalitet.
2.8
Effekter av testning
I detta avsnitt samlas effekter, positiva eller negativa, som tidigare observerats som en ef-fekt av testning. Kapitlet är uppdelat efter negativa och positiva efef-fekter som i sin tur är uppdelat efter effekter från automatiserad testning och effekter från införandet av olika test-förbättringsmodeller. De observationer som presenteras här låg till grund för vilka effekter som kollades efter under utvärderingen av den nya testprocessen.
Nackdelar och negativa effekter
Automatiserad testning
En litteraturstudie av Rafi et. al. [43] sammanställde vilka olika begränsningar och förde-lar av automatiserad testning som rapporterats i empiriska studier. Nedan presenteras de begränsningarna.
2.8. Effekter av testning
1. Automatiserad testning kan inte ersätta manuell testning - Det är inte alla tester som kan automatiseras, särskilt de som kräver djupa kunskaper inom domänen.
2. Förväntade mål uppnåddes inte - Att kunna kör tester på bara en bråkdel av den tid som manuella tester tar är något som lockar organisationer att gå över till automatisering. Många misslyckas dock med att åstadkomma en kvarvarande eller faktiskt förbättring. 3. Det är svårt att underhålla de automatiserade testerna - Förändringar i teknik och
vi-dareutveckling av mjukvaruprodukter gör det svårt att underhålla testsviten.
4. Processen för testautomation behöver tid för att mogna - Det krävs en högre initial tidsin-vestering innan nyttan av testautomation kan märkas.
5. Falska förhoppningar - Opraktiska förhoppningar kring automatiserad testning och dess kostnadsbesparingar leder till att organisationer blir besvikna och överger testningen. 6. Opassande strategi för testautomatisering - Det kan vara svårt att hitta rätt nivå för
au-tomatisering. Det finns en risk att organisationen väljer en strategi som inte passar för dem och missar därför fördelarna med automatiserad testning.
7. Brist på kunskap - Det krävs fler färdigheter för att lyckas med testautomatisering, till exempel kunskap om verktygen och systemet.
I en artikel av Berner, Weber och Keller [5] sammanfattar de observationer och erfarenheter av testautomation som de tagit med sig från fem olika mjukvaruprojekt. Artikeln är en av de bakomliggande källorna till begränsningarna 1, 3, 5 och 6 från litteraturstudien, men in-nehåller även andra observationer. Författarna noterade att om den automatiserade testsviten inte används ofta blir den inkonsekvent och svårförståelig. Den ansträngning som behövs för att underhålla och köra testen blir då oproportionerligt stor.
Haugset och Hanssen [21] genomförde en fallstudie där implementationen av automatiserad acceptanstestning i två projekt studerades. I intervjuer fick utvecklarna berätta om deras er-farenheter med att använda metoden. Haugset och Hanssen fann att det fanns flera negativa erfarenheter och problem.
• Att ha test kan ge en falsk känsla av säkerhet.
• Att testet existerar och att det ger ett positivt resultat betyder inte att testet är bra och att applikationen fungerar som den ska.
• Det krävs även erfarenhet för att skriva bra tester. • En oerfaren testare skriver ofta onödigt stora tester.
Testförbättringsmodeller
I en litteraturstudie av Garousi, Felderer och Hacaloglu [18] undersöktes bland annat ut-maningarna och fördelarna som medfördes av att använda sig av modeller för att förbättra testprocessen. Den främsta utmaningen var en brist på ekonomiska och mänskliga resurser. De noterade, likt det som framgår i kapitel 2.9, att denna brist främst var en utmaning för små och medelstora företag. Brist på kompetens uppmärksammades som ett problem i flera studier, vilket även nämndes av Rafi et. al. [43] angående automatiserad testning. Ytterligare utmaningar var förändringsmotstånd, att det inte märktes av några fördelar och att arbetet med testförbättringen inte var förankrat hos ledningen. Flera studier rapporterade att förbät-tringsarbetet kändes som slöseri med tid och en extra arbetsbörda.
2.8. Effekter av testning
Nytta och positiva effekter
Automatiserad testning
Litteraturstudien kring fördelar och begränsningar av automatiserad testning av Rafi et. al. [43] listar följande 9 fördelar.
1. Förbättrad produktkvalitet - Det är färre defekter i mjukvaran.
2. Testtäckning - Man når en högre kodtäckning med hjälp av automatiserad testning. 3. Minskad testningstid - Det finns möjlighet att genomföra fler test under en viss
tidspe-riod.
4. Pålitlighet - När tester uppdateras är automatiserade tester mer pålitliga eftersom utfal-let av manuella tester kan variera beroende på hur testaren genomför testfalutfal-let.
5. Ökat förtroende - Utvecklarna känner ett ökat förtroende för systemets kvalitet.
6. Återanvändbara tester - Om testerna är skrivna med underhållbarhet i åtanke kan de återanvändas ofta.
7. Mindre tidskrävande - När vissa tester är automatiserade kan de mänskliga ansträngningarna istället läggas på annat.
8. Minskade kostnader - Vid en hög grad av automatisering minskas kostnaderna. Det intro-ducerar dock även nya kostnader i form av implementation, underhåll och utbildning [21, 29].
9. Ökad förmåga att upptäcka fel - En högre effektivitet i att upptäcka fel i systemet.
Automatiserade tester kan även resultera i bättre självförtroende bland utvecklarna. Eftersom koden täcks av tester känns det mindre riskabelt att ändra i en annan utvecklares kod. Detta gör att man i större utsträckning kan dela kod vilken även kan öka produktiviteten. Denna typ av effekter har identifierats i studier kring automatisering av acceptanstester [21] och enhetstester [15].
Testförbättringsmodeller
Litteraturstudien av Garousi, Felderer och Keller [18] rapporterar att flera studier funnit att utvecklingstiden minskat och att det varit lättare att hålla deadlines. Andra effekter har även varit att det blivit lättare att planera kostnaden för testning och att identifikation och hanter-ing av risker har blivit mer effektiv. Användnhanter-ingen av en modell för testförbättrhanter-ing har också inneburit att testare har får en adekvat utbildning inom ämnet.
Ur ett tekniskt perspektiv ökades kodkvaliteten; produkterna var mer stabila och innehöll färre defekter. Det noterade även att spårbarheten blev bättre vilket underlättade vid beslut om produkten skulle släppas. Modellerna resulterade även i bättre testdesign och test-automation.
2.9. Relaterade arbeten
2.9
Relaterade arbeten
Här presenteras resultaten från tidigare applikationer av MTPF och studier kring testning i små utvecklingsteam samt vilka alternativa tillvägagångssätt för testförbättring som finns tillgängliga.
MTPF i praktiken
Urvalet av fallstudier som direkt undersöker implementationen av MTPF är begränsat till den studie som gjordes av Karlström, Runeson och Nordén [31] i samband med framtagandet av ramverket. MTPF implementerades då på företaget Scalando och observationer gjordes under de första tre månaderna samt ett år efter införandet. Utvecklingsteamet bestod av 10 utvecklare och fokus låg därför på att införa nivå 1 av MTPF. Nedan följer de lärdomar som forskarna tog med sig från studien, uppdelat efter MTPF:s fem olika kategorier.
Problem- och erfarenhetsrapportering
Som nivå 1 av ramverket förordar infördes en gemensam problemrapporteringssyntax. Denna syntax bestod av ett antal förutbestämda fält som tillsammans skulle kunna beskriva problem i alla projekt. Det var viktigt att syntaxen skulle vara lättförståelig och göra det möjligt att gruppera problem. För att undvika svårigheter med att byta syntax ifall den skulle visa sig vara ineffektiv lades stor vikt på att den skulle vara flexibel. Microsoft Ex-cel användes därför som rapporteringsverktyg till en början, för att ge företaget en chans att utvärdera syntaxen innan den användes som grund för att skapa ett ordentligt problemrap-porteringssystem.
Vad det gäller den språkliga delen av syntaxen fann man att det på kort sikt var viktigt att före varje projekt diskutera grundläggande definitioner innan testningsarbetet. På lång sikt var planen att låta syntaxen utvecklas till att bli mer enhetlig som en naturlig följd av strävan efter att skriva konsekventa problemrapporter.
Roller och organisation
En person sattes som ansvarig för att planeringen och genomförandet av mjukvarutestning. Som ett resultat av en mer tydlig ansvarsfördelning fann forskarna att testningen skedde mer strukturerat och att marknadsföringavdelningen med större precision kunde planera varje produkts lanseringdatum. Genom att jobba med en person som är specialiserad på testning kunde också utvecklingsteamet lägga mindre tankekraft på mjukvarukvaliteten på system-nivå och istället fokusera på enhetssystem-nivån av testningen.
Verifierande och godkännande
För plattformstestning användes checklistor som innehöll vilka olika konfigurationer som skulle testas. Det visade sig vara användbart för att lätt kunna skapa statusrapporter kring vilka plattformar som det fanns eller inte fanns stöd för. För att testa funktionalitet skapades checklistor som beskrev vilken funktionalitet som skulle testas samt kriterier för godkän-nande/underkännande. Detta gav utvecklarna en bra överblick över vad som skulle testas och möjliggjorde snabbare regressionstestning.
Testadministration
Att få testmiljön att fungera visade sig vara en av de svåraste delarna. Den var instabil och ibland var det svårt att avgöra om felet låg i testmiljön eller i systemet som testades. Det blev därför nödvändigt att testa testmiljön i sig för att kunna få pålitliga testresultat. Scalandos
2.9. Relaterade arbeten
testmiljö möjliggjorde inte att tester kunde köras parallellt vilket utgjorde en flaskhals. Test-miljön verkade tas för given av utvecklarna och de begränsade resurser som fanns avsatta till hårdvara gick ofta åt till utveckling istället för testing.
Testplanering
Inför varje projekt skulle en testplan skrivas. Planens innehåll kunde variera mellan projekt men de huvudsakliga avsnitten var:
1. Funktionalitet som ska testas
2. Kritierier för godkännande/underkännande 3. Tidsplan
4. Ansvarsområden
Under studien noterades det att ordningen på hur olika testaktiviter utförs påverkar kvaliteten på slutprodukten. Genom att genomföra systematisk testning av funktionaliteten innan testning av olika plattformar minskas antalet fel som kan uppstå på de olika plattfor-marna. Mer tid kan därför läggas på att undersöka de fel som är specifika för en viss platt-form. En slutsats som forskarna tar med sig från studien är att den som är testansvarig måste våga att dra nytta av den högre flexibiliteten som finns i mindre organisationer för att skapa en lyckad testplan. Genom att det fanns en uttalad ansvarsfördelning kring testning sågs det också till att testningen alltid togs med vid tidsestimeringar av olika projekt.
Övriga observationer
Efter införandet av MTPF noterades att det lades mer tid på testning, runt 20 % istället för 5 % av utvecklingstiden, och fler problem dokumenterades. Forskarna sammanfattar med att säga att fallstudien visar att den första nivån av MTPF är rimlig för mindre företag och att dess minimalistiska tillvägagångssätt med fokus på att involvera utvecklarna skapar acceptans inom organisationen.
Tillvägagångssätt till testprocessförbättring
Här presenteras olika tillvägagångssätt i from av ramverk, modeller och processer som har tagits fram för att förbättra testprocessen inom mjukvaruutveckling.
TMM, TIM och TPI
Testing Maturity Model (TMM) [6], Test Improvement Model (TIM) [16] och Test Process Improvement (TPI) [36] är tre välkända modeller vars syfte är att förbättra testprocessen hos organisationer genom att kartlägga de rådande processerna inom vissa nyckelområden och tillhandahålla förslag på hur dessa kan förbättras. De har alla gemensamt att de använder sig av olika mognadsnivåer för att beskriva hur pass långt den nuvarande testprocessen har utvecklats.
Det som skiljer modellerna åt är främst vilka nyckelområden som identifierats, antalet mog-nadsnivåer och metoden för att avgöra vilken mognadsnivå organisationen befinner sig på. Till exempel har TPI 20 olika nyckelområden medan TMM och TIM har 13 respektive 5. I TIM och TPI utvärderas vilken nivå varje individuella nyckelområde ligger på medan TMM in-troducerar nya nyckelområden eller "mognadsmål" som måste uppnås innan organisationen når nästa TMM-nivå. TMM:s utvärderingsmodell består av tre komponenter: målrelaterade
2.9. Relaterade arbeten
frågor för att avgöra mognadsnivå, ett träningsprogram för att utbilda ett utvärderingteam som kan utföra bedömningen och slutligen en bedömningsmodell som låter organisationen utvärdera sig själv med hjälp av data från intervjuer och frågeformulär. TIM använder sig endast av intervjuer för att utvärdera vilken nivå företaget ligger på i varje nyckelområde. TPI:s utvärderingmodell består av två komponenter: en checklista och en testmognadsma-tris. Checklistan används för att avgöra om alla mål för en viss mognadsnivå inom ett visst nyckelområde är nådda och matrisen används för att ge en överblick av vilka områden som behöver förbättras.
ISO standard
Den senaste standarden inom mjukvarutestning från ISO är ISO 29119:2013 [24]. Målet med standarden är att "skapa en generisk processmodell för mjukvarutesning som kan använ-das av vilken organisation som helst för utförandet av vilken sorts mjukvarutestning som helst"[24, Sida vi]. Målet är således mycket brett och verkar ämna täcka in allt från utveck-lingsavdelningar på Microsoft till små enmansbolag. För att anses följa ISO 29119 ska organi-sationen uppfylla alla så kallade shall-statements (ungefär ska-satser) i standarden, som är 132 stycken för testprocesser. Standarden tillåter dock att organisationer siktar mot skräddarsytt efterföljande (eng. tailored compliance) och definierar en delmängd av dessa regler att följa. Testprocessen delas in i tre lager: den organisatoriska processen, testledningsprocessen och de dynamiska testprocesserna. Målet med det organisatoriska lagret är att definiera pro-cesser för organisationsomspännande testspecifikationer såsom teststrategi, testplanering med mera. Testledningslagret syftar till att definiera processer för testledning, vilket inklud-erar tesplanering, testuppföljning och testavslutningsprocessen. Det understa lagret, för dy-namiska testprocesser, har målet att beskriva en generell testprocess för vilken sorts tester som ska skrivas under vilka delar av projekten. Detta inkluderar testdesign, testmiljöer, test-exekvering och felrapportering.
Baserade på TMM
Test Maturity Model Integration (TMMi) [44] är utvecklad av den ideella organisationen TMMi-Foundation och beskriver själva modellen som en "industristandard av utövare för utövare" [44, sida 190]. De flesta mognadsnivåer, aktiviteter och nyckelområden är baserade på TMM, men har utvecklats ytterligare i samarbete industrin. Målet var att skapa en modell som var tillgänglig för allmänheten och som bättra reflekterade industrins behov.
Ministry of National Defence-Testing Maturity Model (MND-TMM) [47] togs fram för att ta hänsyn till de högre kraven på kvalitet inom försvarsindustrin. MND-TMM har likt TMM fem mognadsnivåer. Modellen innehåller 10 nyckelområden som är indelade i kategorierna Militär (eng. Military), Process, Infrastrukur och Teknik.
Metrics Based Verification and Validation Maturity Model (MB-VV-MM) [25] skapades med målet att förbättra TMM-modellen genom att tillhandahålla en kvantitativ metod för att bättre följa förbättringsarbetet och bättre välja vilka förbättringsåtgärder som ska imple-menteras. Kvalitativa mått används för att verifiera att en mognadsnivå har uppnåtts och används som bas för att avgöra nästa steg i processen.
Baserade på TPI
TPI Next [53] är utvecklat av företaget Sogeti som en ersättare till TPI och är framtagen för att vara bättre anpassad till industrins behov. Omfattningen har minskats från 20 till 16 ny-ckelområden. Mognadsnivåerna har även ändrats för att bli mer beskrivande och checklistor innehåller mer tydligt definierade mål.
2.9. Relaterade arbeten
TPI Automotive [52] är framtagen av Sogeti tillsammans med bilindustrin i Tyskland. Mod-ellen är en anpassad version av TPI som tar hänsyn till de specifika behov som finns inom mjukvarutestning inom bilindustrin.
Test Process Improvement Model for Automated Test Generation (TPI-ATG) [22] är ett tillägg till TPI med avsikt att använda TPI-modellen för att hjälpa företag att automatiskt generera testfall. TPI-modellen hålls intakt, men nya mognadsnivåer, nyckelområden och checklistor relaterade till automatisk testgenerering har lagts till.
Embedded Test Process Improvement Model (Emb-TPI) [26] skapades då TPI inte ansågs ta hänsyn till utveckling av inbyggda system. Emb-TPI är en modifierad version av TPI där mognadsmål och checklistor har anpassat för att hantera de hårdvarurelaterade problem som är vanligare under utveckling av inbyggda system.
Baserade på ISO
TestSPICE 3.0 [49] utvecklades för att utgöra en lösning för testutvärdering så nära kopplad ISO 15504 som möjligt. Den har senare utvecklats för att anpassas till den senaste ISO-standarden inom testprocesser, ISO 29119.
Self-assessment framework for ISO/IEC 29119 based on TIM [33] är en modell som låter organisationer utvärdera sina testprocesser i förhållande till ISO 29119. Den utgår ifrån de fem mognadsgraderna i TIM [16]. Modellen beskrivs av författarna som en prototyp som visat lovande resultat, snarare än en färdig produkt.
Fristående tillvägagångssätt
Här beskrivs tre tillvägagångssätt till testprocessförbättring som inte bygger vidare på någon av de tidigare nämnda modellerna. Dessa beskrivs därför som fristående.
Plan-do-check-action (PDCA)-based software testing improvement framework [38] är speciellt inriktad på tredjeparts testcenter som tillhandahållertestning som en tjänst. Den lägger stor vikt vid organisationens kunskapshantering (eng. Knowledge Management). I studien Analysing an Automotive Testing Process with Evidence-Based Software Engi-neering (EBSE) undersöker Kasoju, Petersen och Mäntylä [32] hur metoden Evidence-Based Software Engineering [35] kan användas för att förbättra testprocesserna inom bilindustrin. Metoden applicerad innebar att intervjuer användes för att identifiera problem inom testor-ganisationen. Sedan genomfördes en litteraturstudie för att identifiera lösningar. Till sist användes värdeflödeskartläggning (eng. value stream mapping) för att koppla problemen till lösningarna. EBSE tillhandahåller inga förslag på vilka åtgärder som kan införas utan ett tillvägagångssätt för att hitta dem.
Observing-practice (OB) [55] är ett antal processförbättringsförslag som togs fram efter att ha studerat testning hos ett antal organisationer. Resultatet är inte en process utan snarare en samling riktlinjer eller tips för organisering och förbättring av testprocesser.
2.9. Relaterade arbeten
Sammanfattning av tillvägsgångssätt till testprocessförbättring
I tabell 2.1 presenteras de tillvägagångssätt för testförbättring som beskrivits ovan. De är klassificerade utefter följande kategorier:
• Domän Beskriver om tillvägagångssättet är anpassat för någon särskild industri eller miljö.
• Detaljnivå av testaktiviteter Huruvida tillvägagångssättet presenterar definierade testak-tiviteter som bör ingå i testningsarbetet eller om dessa endast presenteras på koncept-nivå som riktlinjer. För tillvägagångssätt som beskriver en process för att utifrån situa-tionens behov ta fram testaktiviteter skrivs: "Definieras under processen".
• Validerad i mindre företag Huruvida tillvägagångssättet vid dess framtagande valider-ades i ett företag av mindre storlek.
• Utvärderingsmetod Huruvida tillvägagångssättet innehåller en metod för att utvärdera till vilken nivå tillvägagångssättet har anammats. "Endast modell" innebär att tillvä-gagångssättet tillhandahåller en modell eller struktur för utvärderingen (till exempel mognadsnivåer), men det är inte definierar hur utvärderingen ska utföras.
2.9. Relaterade arbeten
Tabell 2.1: Överblick av tillvägagångssätt
Tillvägagångssätt Domän Detaljnivå av testak-tiviteter Validerad i mindre företag Utvärderings-metod Kommentar TMM - Definierade Nej Ja
TIM - Definierade Nej Endast
modell
TPI - Definierade Nej Ja
ISO 29119 - Definierade Nej Endast
modell
TMMi - Definierade Nej Ja Baserad på TMM
MND-TMM
Försvars-industrin Definierade Nej Nej Baserad på TMM
MB-VV-MM - Riktlinjer Nej Nej
Baserad på TMM. An-vänder kvantitativa mått.
TPI Next - Definierade Nej Ja Baserad på TPI
TPI Automotive Bilindustrin Definierade Nej Ja Baserad på TPI
TPI-ATG Automatiserad
testgenerering Definierade Nej
Endast
modell Tillägg till TPI
Emb-TPI Inbyggda
system Definierade Nej Nej Baserad på TPI
TestSPICE 3.0 - Definierade Nej Nej Baserad på ISO 29119
Self-assessment framework for ISO/IEC 29119 based on TIM - Definierade Ja Ja Baserat på TIM-mognadsnivåer för att uppfylla ISO 29119
PDCA
Tredjeparts-testcenter Riktlinjer Nej Nej
Fokuserar på att förbät-tra kunskapshantering (eng. knowledge man-agement) EBSE Applicerades på bilindustrin Definieras under processen Ja Nej
Metod för att utvärdera situationen och ta fram förbättringsåtgärder. Observing-practice (OB) -Definieras under processen Ja Nej
Metod för att utvärdera situationen och ta fram förbättringsåtgärder MTPF Utvecklingsteam med 10 -30 medlemmar Riktlinjer Ja Nej Innehåller förslag på förbättringsområden baserat på utvecklings-teamets storlek
2.9. Relaterade arbeten
Testförbättringsprocesser för mindre företag
Det har i flera studier konstaterats att de metoder som nämns ovan inte är anpassade till de förutsättningar som finns hos mindre och medelstora företag [2, 20, 31, 40]. Små före-tag har inte tillräckliga resurser, varken mänskliga eller finansiella, för att stödja stora sat-sningar på annat än deras huvudsakliga aktiviteter. Större företag uppnår skalfördelar i de satsningar de gör i sekundära aspekter av sina huvudaktiviteter, till exempel förbättringar och utvärderingar av utvecklingsprocesser eftersom förbättringarna kan appliceras på en större mängd utvecklare. [23]
Martin et. al. [40] menar att även om mindre organisationer är medvetna om best-practice inom mjukvarutestning så måste de prioritera bort vissa delar av organisatoriska anled-ningar. Företaget i deras studie lät testningsarbetet kretsa kring fyra organisatoriska faktorer: dynamiska kundrelationer, behovet av att nyttja begränsade resurser så effektivt som möjligt, att kunna släppa nya versioner av produkten när det är lämpligt samt behovet att utöka sin marknad och se framtida kunders behov. Baserat på dessa faktorer avgjordes vilken testning som utfördes och i vilken utsträckning. Faktorerna är inte unika för det företaget, och inte heller för små företag, men organisationers förutsättningar skiljer sig, och därför skiljer sig även hur de kan hantera dessa prioriteringar.
Martin et. al. [40] drar, utifrån sin fallstudie, slutsatsen att forskningen inom mjukvarutest-ning hittills har fokuserat på att förbättra testmjukvarutest-ning ur ett teknisk perspektiv, men att detta i praktiken inte är hjälpsamt eftersom det riktiga problemet är att anpassa testningen till de organisatoriska begränsningarna som finns. Det som behövs är testmetoder som minimerar den ansträngning och tid som krävs för att kunna visa att mjukvaran är "bra nog".
Även Gruner och van Zyl [20] fann det nödvändigt att prioritera bort delar av TMM-modellen när de jobbade med att införa den hos ett mindre mjukvaruföretag. Nyckelområdet "kontroll och övervakning av testprocessen" reducerades rejält då det är väldigt dokumentationstungt, något som företaget inte ansågs ha resurser att hantera. Målet var att uppnå en nivå som näs-tan motsvarade mognadsnivå 2 av TMM. Men även med en nedskuren version av modellen kunde inte alla åtgärder införas direkt. Åtgärderna fick istället införas långsamt och gradvis.
3
Metodteori
Detta avsnitt behandlar metoder för att genomföra aktionsforskning och fallstudier.
3.1
Forskningsmetodik
Forskning kan ske i många olika miljöer och med olika syften. Vissa studier försöker bekräfta befintlig teori, andra försöker hitta nya förklaringar på outforskade fenomen. Vilken typ av studie som lämpar sig för ett visst tillfälle beror således på dess syfte och i vilken miljö den utförs i. Runeson och Höst [46] beskriver fyra olika syften en studie kan ha.
• Explorativa studier undersöker och försöker förstå nya fenomen. • Deskriptiva studier beskriver och rapporterar en befintlig situation. • Explanativa studier försöker förklara en situation eller ett problem.
• Förbättrande studier syftar till att hitta lösningar och förbättringsförslag till befintliga situationer.
Utöver att karaktärisera olika sorters forskning utifrån deras syfte kan de även delas in baserat på om designen av studien är flexibel eller fast. Detta handlar om hur mycket av studiens design som är bestämd och känd från början och hur mycket av den som tillåts utvecklas efter studiens gång. [46]
• Fasta metoder är vanligt för till exempel enkätundersökningar och bygger på att forskarna från början av studien definierat alla dess centrala parametrar.
• Flexibla metoder tillåter istället viss förändring av studiens centrala parametrar allt eftersom studien fortgår. Detta är ett vanligt tillvägagångssätt för fallstudier och ak-tionsforskning.
3.2. Cooperative Method Development
Forskning kan även delas upp utifrån vilken typ av data som huvudsakligen används. I dessa fall används ofta uppdelningen mellan kvalitativ och kvantitativ data.
• Kvantitativ data utgörs av mätningar, siffror och klasser. Denna data behöver tolkas med hjälp av statistiska verktyg och passar generellt forskning med en fast design. • Kvalitativ data består istället av beskrivningar, observationer och ord. Denna data
pas-sar generellt studier med en flexibel design och behandlas med kategorisering och sor-tering.
Aktionsforskning
Aktionsforskning (eng. Action Research) är en form av studie där forskare studerar ett ämne genom att själva vara involverade i arbetet som studeras. Det växte fram som metod då den klassiska naturvetenskapliga modellen, där en hypotes testas under kontrollerade om-ständigheter, inte passade särskilt bra för att studera sociala koncept. [9]
Både aktionsforskning och fallstudier genomförs generellt i verkliga situationer. Detta in-nebär att forskarnas möjlighet att kontrollera miljön till en viss grad offras för att istället få en högre grad av realism. Båda forskningstyper förlitar sig på kvalitativ data i första hand och de följer ofta en flexibel design för att kunna anpassa sig till miljön och situationen studien äger rum i. Det som skiljer dem åt är det grundläggande syftet. Fallstudier är i huvudsak explorativa till sin natur. De ämnar upptäcka och förstå något fenomen. Aktionsforskning är istället mer fokuserat på att förändra någonting och åstadkomma en förbättring i miljön där den äger rum, vilket gör att de generellt klassas som förbättrande studier. [46]
3.2
Cooperative Method Development
CMD beskrivs av sina skapare som en form av aktionsforskning anpassad för utveckling av mjukvaruprocesser. Fokus är på att forskning bör ske på utvecklarnas nivå, att effekter bör utvärderas utifrån deras perspektiv och att utvecklarna bör involveras i en så stor del av processen som möjligt. Vid användandet av CMD är det mer intressant att undersöka hur utvecklarna använder sig av metoder och vilken inverkan metoderna har på det dagliga arbetet snarare än det mätbara resultatet som användandet av metoden resulterar i. Det är dock möjligt att använda kvantitativa metoder som sekundära informationskällor. [12]
Riktlinjer i CMD
CMD beskriver inte exakt vilka steg och moment en studie ska innehålla. Metoden är menad att anpassas efter projektets situation. Istället finns det fem riktlinjer som bör följas. [12]
1 - Action Research-cykler. I stort läggs studien upp i cykler med tre faser: Förståelse för verksamheten, övervägande av förbättringsåtgärder samt implementation och utvärdering av förbättringsåtgärderna. I förståelsefasen används kvalitativ empirisk forskning för att få så mycket och djup förståelse som möjligt av miljön studien utförs i. I den andra fasen sker mer tekniskt arbete och metoder utvecklas i samarbete med utvecklarna på plats. I den tredje fasen återgår fokus till kvalitativ empirisk forskning för att utvärdera effekterna av förän-dringsarbetet från utvecklarnas perspektiv.
2 - Etnometodologisk och etnografiskt inspirerad empirisk forskning. Metoden upp-muntrar användandet av kvalitativa metoder, inspirerade av etnometodologi och etnografi för att göra empiriska fältstudier. Där det passar kan detta göras i kombination med andra metoder. I praktiken innebär detta att man utgår ifrån utvecklarnas dagliga arbete. Ur detta
