Teststrategier: En fallstudie för Scouternas medlemsregister

Teknik och samh¨alle Datavetenskap

Examensarbete 15 h¨ogskolepo¨ang, grundniv˚a

Teststrategier: En fallstudie f¨or Scouternas medlemsregister

Test strategies: A case study for the Swedish Scouts’ and Guides’ membership management system

Johan Holmberg

Examen: Kandidatexamen 180 hp Huvudomr˚ade: datavetenskap Program: Datavetenskap

Handledare: Ulrik Eklund Andrabed¨omare: Mia Persson

Sammanfattning

Mjukvarutestning ¨ar en f¨oruts¨attning f¨or att garantera kvaliteten hos levererad mjukvara. Trots detta blir testningen fortfarande nedprioriterad i somliga mjukvaruprojekt, vilket f˚ar tydligt negativa f¨oljder.

Arbetet unders¨oker ett utvecklingsprojekt hos en st¨orre ideell ungdomsorganisation i Sverige och dess motsvarighet i Norge. S¨arskilt fokus ligger p˚a kvalitetss¨akring och test-ning. Likas˚a unders¨oks hur detta arbete delats upp mellan best¨allare och leverant¨or.

Unders¨okningen visar att bristande kvalitet i leveranserna skadat f¨ortroendet f¨or leve-rant¨oren, f¨orsenat och f¨ordyrat utvecklingen, samt lett till frustration hos slutanv¨andarna. Orsaken till den bristande kvaliteten st˚ar att finna i en fr˚an b¨orjan otydlig kravprocess och i en oplanerad och ostrukturerad testprocess.

Ett f¨orslag till teststrategi med syfte att formalisera testprocessen har tagits fram och levererats till organisationerna och deras gemensamma leverant¨or. Kravprocessen f¨oresl˚as unders¨okas i ett senare skede.

Abstract

Software testing is a prerequisite for quality in software. Even so, testing is still down-prioritized in certain software projects.

The report examines a development project within a major non-profit youth organiza-tion in Sweden, and its Norwegian counterpart. Focus has been put on quality assurance and testing. Also examined is the division of those tasks between customers and contractor. The survey shows that a lack of quality in the delivered product has damaged the confidence in the contractor, delayed and increased the cost of the development, and led to frustration with the end users. The cause for the lack of quality is to be found in a from the start inexplicit requirements process, and in an ad hoc-planned and unstructured test process.

A proposed test strategy with the purpose of formalise the test process has been devised and delivered to both organizations and their common contractor. A survey is proposed to gain insight of the requirements process.

F¨

orord

Ett stort tack till Kim Rask f¨or gott samarbete under arbetet. Jag vill ocks˚a tacka Ingrid Stene och Russel Flynn f¨or intervjuerna. Slutligen vll jag tacka min handledare Ulrik Eklund f¨or god ˚aterkoppling och v¨agledning n¨ar det har beh¨ovts.

Inneh˚

all

1 Inledning 1

1.1 Bakgrund . . . 1

1.2 Fr˚agest¨allning och problemformulering . . . 1

1.3 Studiens avgr¨ansning . . . 1

1.4 Uppsatsens disposition . . . 2 2 Metod 3 2.1 Intervjuer . . . 3 2.2 Dialoger . . . 4 2.3 Litteraturstudier . . . 5 2.4 Validering av artefakt . . . 5 2.5 Metoddiskussion . . . 5

2.5.1 Tillf¨orligtlighet - metoden . . . 5

2.5.2 Validitet - felk¨allor . . . 6

3 Teoretisk bakgrund 6 3.1 Agila utvecklingsmodeller . . . 7 3.1.1 Lean Development . . . 7 3.1.2 Kanban . . . 7 3.1.3 Scrum . . . 7 3.2 Testdriven utveckling . . . 8 3.2.1 Beteendedriven utveckling . . . 8 3.2.2 Acceptanstestdriven utveckling . . . 8 3.2.3 Kontraktdriven utveckling . . . 8 3.3 Inledande om mjukvarutestning . . . 8 3.3.1 Testprocessen . . . 9 3.3.2 Testplanering . . . 10 3.3.3 Testmetoder . . . 11 3.3.4 M¨atningar av testningsmoment . . . 13

3.3.5 Hur mycket b¨or testas? - Kort om testt¨ackning . . . 14

3.3.6 Vem som ansvarar f¨or testningen . . . 15

4 Bakgrund 15 4.1 Scoutnets historik . . . 15

4.2 Scoutnets uppbyggnad . . . 16

4.3 Scoutnets utvecklingsprocess . . . 16

4.3.1 Framtagande och prioritering av krav . . . 17

4.3.2 Felrapportering och felhantering . . . 18

4.3.3 Leverans och acceptans av leverabler . . . 18

4.3.4 Nuvarande testningsf¨orfarande . . . 19

4.3.5 Scoutnets ideella arbetsgrupp . . . 19

4.3.6 F¨orh˚allandet mellan Scouterna och leverant¨oren . . . 19

4.4 F¨or¨andringar i Scouternas organisation . . . 20

4.4.1 Scouternas ¨ovriga digitala hj¨alpmedel . . . 20

4.5 Liknande produkter . . . 21

5 Relaterat arbete 21 6 Analys av insamlad data 22 6.1 F¨oruts¨attningar . . . 22

6.2 F¨orh˚allandet mellan best¨allare och utf¨orare . . . 22

6.3 F¨orenklingar och f¨orb¨attringar . . . 22

6.4 Externa aktiviteter . . . 23

7 Resultat 24 7.1 Teststrategi . . . 24

7.1.1 Inledning och avgr¨ansning . . . 24

7.1.2 F¨oruts¨attningar . . . 24

7.1.3 Metoder och teori . . . 24

7.1.4 F¨oreslagna test- och utv¨arderingsaktiviteter . . . 25

7.2 Validering . . . 25

7.2.1 Mottagande hos Scouterna . . . 25

7.2.2 Mottagande hos Norges Speiderforbund . . . 26

8 Diskussion 26 8.1 Studiens allm¨angiltighet . . . 26

8.2 Teststrategin som m¨ojligg¨orare f¨or en ¨oppnare utvecklingsmodell . . . 27

8.3 Utvecklingsarbete i ideella organisationer . . . 27

8.4 Liknande arbete . . . 27

8.4.1 Germundssons Improvement Areas for Agile Test Processes . . . 27

8.4.2 Hedins och Birgissons Introducing the Agile Requirements Abstration Model - Requirements Engineering in a Scrum environment . . . 28

8.4.3 Ghahrais Agile Test Strategy Example Template . . . 29

8.5 F¨oreslagen framtida forskning . . . 29

9 Slutsats 29

Ordlista 31

Referenser 34

1

Inledning

Scoutr¨orelsen ¨ar en v¨arldsomsp¨annande ungdomsr¨orelse som syftar till att bidra till ungas utbildning och utveckling baserat p˚a de v¨arden som uttrycks i scoutlagen och scoutl¨oftet [1]. I Sverige organiseras scoutr¨orelsen i Scouterna [2], som ¨ar en sammanslagning av de fem scoutf¨orbund som existerade fram till 2012 [3].

Scoutnet ¨ar Scouternas verksamhetsst¨odsystem. Det hanterar framf¨orallt organisatio-nens medlemsregister, vilket ¨ar ett centralt medlemsregister f¨or samtliga direktanslutna lokalavdelningar, kallade scoutk˚arer. Ut¨over att tillhandah˚alla ett medlemsregister ¨ar am-bitionen att Scoutnet ska vara ett st¨od f¨or all administrativ verksamhet i den svenska scoutr¨orelsen. S˚aledes erbjuder Scoutnet ett antal andra tj¨anster, som alla ska f¨orenkla den administrativa b¨ordan f¨or b˚ade ideella och avl¨onade funktion¨arer och administrat¨orer i r¨orelsen. Funktionalitet som byggts in i Scoutnet innefattar ans¨okningsverktyg f¨or stats-och landstingsbidrag, ett administrationsverktyg f¨or Scouternas folkh¨ogskola, dynamiska e-postlistor och ett verktyg f¨or administration av de arrangemang som utf¨ors i Scouternas regi.

F¨or att organisationens medlemmar ska kunna fokusera p˚a den dagliga verksamheten ¨

ar det viktigt att administrationen kan h˚allas p˚a en l˚ag och hanterbar niv˚a, vilket ¨ar ett av de problem som ett verksamhetsst¨odsystem som Scoutnet ¨ar t¨ankt att l¨osa. Ett st¨odsystem av det h¨ar slaget kan dock bara anses l¨osa detta om det upplevs som p˚alitligt av anv¨andarna [4].

Utvecklingen av Scoutnet har dragits med problem i form av leveranser av bristande kvalitet, vilket bland annat yttrat sig i programfel som l¨oses f¨or att sedan ˚aterkomma i en senare leverans. Scouterna ¨onskar analysera och hitta l¨osningar p˚a detta problem.

1.2 Fr˚agest¨allning och problemformulering

Studien syftar till att besvara fr˚agan hur kan en teststrategi utformas f¨or att s¨akra kvali-teten hos levererad mjukvara i ett p˚ag˚aende agilt utvecklingsprojekt hos en ideell organisa-tion?

F¨or att unders¨oka detta tas ett utkast till en teststrategi fram och l¨aggs fram f¨or Scouterna som ett f¨or¨andringsf¨orslag. F¨orslaget l¨aggs ¨aven fram f¨or Norges speiderforbund, vilka f˚ar agera referenser f¨or att validera teststrategins allm¨angiltighet.

N¨ar en teststrategi ¨ar framtagen unders¨oks huruvida denna kan anv¨andas f¨or att un-derl¨atta och underst¨odja ett upp¨oppnande av mjukvarans utveckling, i syfte att p˚a sikt m¨ojligg¨ora en ¨oppen utveckling av mjukvaran d¨ar professionella utvecklare tillsammans med frivilliga kontribut¨orer driver mjukvarans utveckling fram˚at [5].

1.3 Studiens avgr¨ansning

Testaspekten ¨ar bara en liten del av hela utvecklingsprocessen. I fallet med Scoutnet finns brister p˚a fler st¨allen i processen [6, 7, 8], men dessa anses ligga utanf¨or det omr˚ade som studien omfattar. Av den anledningen kommer, ut¨over den del som r¨or datainsamling f¨or

f¨orst˚aelse av historik och process, ¨amnen s˚asom kravhantering, felhantering och program-meringsmetodik inte att avhandlas i rapporten.

Den slutprodukt som levereras till Scouterna kommer inte att kunna implementeras under arbetet, varf¨or en utv¨ardering om dess verkan inte heller kommer att beskrivas i rapporten.

1.4 Uppsatsens disposition

Inledning

Inledningskapitlet beskriver arbetets bakgrund och m˚albild. H¨ar beskrivs fr˚agest¨allning, avgr¨ansning och hur uppsatsen ska l¨asas.

Metod

I metodbeskrivningen redog¨ors f¨or hur arbetet lagts upp och utf¨orts. De metoder som anv¨ants f¨orklaras och argument f¨or att dessa metoder valts redovisas. Kritik mot metoden presenteras sist i avsnittet.

Teoretisk bakgrund

En ¨oversikt av omr˚adena agila utvecklingsmetoder och mjukvarutestning ges. Beskrivna omr˚aden omtalas i intervjumaterialet, den f¨ardiga teststrategin eller tas upp i den analys av litteraturstudien och intervjumaterialet som lett fram till teststrategin.

Bakgrund

En beskrivning av historisk bakgrund och nul¨age r¨orande utvecklingen av Scoutnet pre-senteras f¨or l¨asaren. Utvecklingsprocessen och relationen mellan leverant¨or och best¨allare genomlyses.

Relaterat arbete

Relaterade arbeten i form av tv˚a masteruppsatser och en f¨oreslagen mall f¨or agila test-strategier presenteras.

Analys av insamlad data

En analys av teori och insamlat material presenteras. Resultat

I resultatkapitlet beskrivs det f¨orslag till teststrategi som arbetet utmynnat i, samt hur detta skulle kunna anv¨andas f¨or att s¨akerst¨alla kvalitet i leveranserna. ¨Aven validering avhandlas i detta kapitel.

Diskussion

En diskussion om arbetets resultat f¨ors och en beskrivning av hur resultatet kan imple-menteras i Scouternas utvecklingsprocess presenteras.

Slutsats

Arbetet och dess resultat sammanfattas.

2

Metod

Arbetet har utf¨orts med en aktionsforskande metod som grund. Easterbrook m.fl. [9] diskuterar aktionsforskning som en metod f¨or att generera vad de kallar autentiskt kun-skapsutfall ˚at studiens deltagare, vilket inneb¨ar att ett verkligt problem finns och att detta m˚aste l¨osas. Ett verkligt problem, bristande kvalitet i leveranser av Scoutnet, har identi-fierats. Problem¨agaren, Scouterna, har visat sig vara villig att kollaborera f¨or att finna en l¨osning p˚a problemet.

Datainsamlingen ¨ar av kvalitativ natur och vilar p˚a en konstruktivistisk grund [10]. Insamlingsarbetet har skett fr¨amst genom intervjuer och dialoger med ber¨orda parter, inkluderat ansvariga tj¨anstem¨an f¨or Scoutnet och ScoutNet, utvecklare och testexperter. Ut¨over detta har en litteraturstudie gjorts f¨or att skapa en teoretisk bakgrund till arbetet med artefakten.

En artefakt, en teststrategi, som syftar till att inf¨ora en f¨or¨andring i det dagliga arbetet med Scoutnet har tagits fram i samarbete med ansvarig tj¨ansteman f¨or Scoutnet. Arte-fakten har modellerats med inspiration av Ghahrais Agile Test Strategy Example Templa-te [11]. Analys av vem som b¨or ansvara f¨or de olika aspekterna av testningen har gjorts med hj¨alp av Maricks testkvadrant [12].

Slutligen har artefaktens giltighet validerats genom dialog med Kim Rask och Ingrid Stene.

Arbetets uppl¨agg har till viss del modellerats utifr˚an Hanna Germundssons master-uppsats [13], vilken unders¨oker f¨orb¨attringsomr˚aden f¨or agila testprocesser.

2.1 Intervjuer

En intervju ¨ar en mer eller mindre systematisk utfr˚agning av intervjupersoner kring ett visst tema [14]. I en kvalitativ studie b¨or intervjupersonerna v¨aljas ut med omsorg f¨or att f˚a tillg˚ang till s˚a relevanta data som m¨ojligt f¨or omr˚adet. D˚a antalet potentiellt intressanta respondenter ¨ar begr¨ansat, har studiens urval gjorts med metoden purposeful sampling [15]. Som en del av studien har intervjuer gjorts med Kim Rask, ansvarig tj¨ansteman f¨or Scoutnet hos Svenska scoutf¨orbundet (SSF), samt med Ingrid Stene, ansvarig tj¨ansteman f¨or ScoutNet hos Norges speiderforbund (NSF). Dessa intervjuer har varit ¨oppet rikta-de [14] och har till ¨overv¨agande del utgjorts av likalydande fr˚agor. I intervjun med Kim Rask st¨alldes en extra fr˚aga som inte har b¨aring i det norska fallet, varf¨or denna fr˚aga utesl¨ots ur intervjun med Ingrid Stene. I Ingrid Stenes intervju st¨alldes en fr˚aga r¨orande ¨

Figur 1: Beskrivning av arbetsprocess.

f˚att st¨allas som kompletterande fr˚aga under dialogfasen. Fr˚agorna var av ¨oppen natur, vilket inneburit att intervjupersonerna haft m¨ojlighet att svara p˚a intervjufr˚agorna i den omfattning de sj¨alva ¨onskat.

En intervju har ¨aven gjorts med Russel Flynn p˚a Custard Labs, nuvarande huvud-utvecklare av Scoutnet och ScoutNet. Flynns fr˚agor har varit skilda fr˚an de fr˚agor som st¨allts till Rask och Stene, och har till stor del varit av mer teknisk natur. Denna intervju gjordes f¨orh˚allandevis sent i arbetet, d˚a litteraturstudien till stor del var genomf¨ord.

En kort intervju med David Gustavsson p˚a Sverok Admin AB har ocks˚a genomf¨orts med syfte att skapa en ¨overblick av arbetet hos ett f¨oretag inom samma segment som Custard Labs och Redpill Linpro.

Intervjun med Kim Rask utf¨ordes under ett fysiskt m¨ote. ¨Ovriga intervjuer har utf¨orts som telefonintervjuer. Svaren har tolkats och skrivits ner som anteckningar under inter-vjuerna.

2.2 Dialoger

Under arbetet har kontinuerliga dialoger f¨orts med Kim Rask och Sigurdur Birgisson, Quality Assistance Engineer hos Atlassian.

Birgissons vetenskapliga bidrag best˚ar i hans master-uppsats, vilken avhandlar krav-hantering i agila utvecklingsprocesser [16]. Hans yrkesm¨assiga bidrag till omr˚adet st˚ar fr¨amst att finna i agil testmetodik. I det h¨ar arbetet har han agerat referens och varit behj¨alplig vid b˚ade framtagning och validering av teststrategin. Ut¨over professionen har Birgisson l˚ang erfarenhet av organisationen, Scouterna, som uppsatsen beskriver, och f˚ar d¨arf¨or anses ha insikt i ¨aven den aspekten av arbetet.

Rasks bidrag till arbetet har varit av konsultativ natur. Han har efter avslutad inter-vju st˚att till f¨orfogande f¨or uppf¨oljningsfr˚agor och f¨ortydliganden. Under framtagning av

teststrategin har han agerat referens och fungerat som st¨od vid framtagning av strategin.

2.3 Litteraturstudier

En litteraturstudie har genomf¨orts f¨or att f¨orankra arbetet i en solid teoretisk grund. En v¨al genomf¨ord litteraturstudie ¨ar till stor hj¨alp f¨or att bygga vidare p˚a existerande kunskap och f¨or att minska risken att f¨orbise redan gjorda l¨ardomar [14]. Denna del av studien ¨ar en iterativ process, d¨ar en brett anlagd litteraturs¨okning efterhand smalnas av allt eftersom f¨orst˚aelsen f¨or omr˚adet hos rapportf¨orfattaren ¨okar. Detta inneb¨ar ocks˚a att om arbetet tar en ov¨antad riktning m˚aste ¨aven litteraturs¨okningen anpassas efter den nya riktningen [14].

Studerat material innefattar framf¨orallt facklitteratur i magasin- och bokform, forsk-ningsartiklar och studentuppsatser. Litteraturen som ing˚ar i studien har publicerats mellan 1980 och 2015, med en tydlig tyngdpunkt p˚a ˚aren 2006–2012. Detta ¨ar naturligt, d˚a de agila utvecklingsmetoderna blommat ut under denna tidsperiod.

Litteraturs¨okningar har gjorts fr¨amst med Google Scholar, Malm¨o h¨ogskolas Summon, IEEE Xplore och ACM. Referenser har s¨okts bland Wikipedia-artiklar r¨orande testning, i bokreferenser, samt bland tidigare studentuppsatser. Vanliga s¨okfraser har varit software testing, test strategy, software quality, agile testing och contract driven. Pluralvariationer p˚a s¨okord har f¨orekommit i relevanta fall.

F¨or avsnitt 4.1 r¨orande Scoutnets historia har fr¨amst relevanta webbresurser anv¨ants. D˚a dessa resurser saknar referenslistor har f¨orfattaren f˚att lita till sina egna kunskaper och erfarenheter av dom¨anen f¨or att bed¨oma trov¨ardighet och validitet i k¨allmaterialet.

2.4 Validering av artefakt

Validering av artefakten har gjorts genom dialog via telefon med Kim Rask f¨or Scouter-na och Ingrid Stene f¨or NSF. Argument som anv¨ants f¨or att styrka artefaktens validitet gentemot Scouterna och NSF har baserats p˚a analysen av insamlad data och av litteratur-studien. Dialogerna har inte utmynnat i n˚agra f¨or¨andringar av den presenterade artefakten.

2.5 Metoddiskussion

Som i alla fallstudier ¨ar en unders¨okning aldrig rakt ¨overf¨orbar p˚a andra fall, d˚a detaljer s˚asom kultur, ¨oppenhet och utf¨orare alla inverkar p˚a resultatet [14]. Den ¨overgripande metoden kan trots detta utv¨arderas i termer av tillf¨orlitlighet och validitet.

2.5.1 Tillf¨orligtlighet - metoden

Unders¨okningens fr¨amsta metod f¨or datainsamling var ¨oppna intervjuer. En f¨ordel med metoden ¨ar att respondenterna har m¨ojlighet att ge utt¨ommande svar. En nackdel med dem ¨ar risken f¨or att respondenterna tillr¨attal¨agger svaren f¨or att framst¨alla sig sj¨alv i b¨attre dager, av skam eller av ¨onskan f¨or att tillfredsst¨alla fr˚agest¨allaren. Detta f¨ors¨amrar kvaliteten i den insamlade datan [14].

Att inte inleda studien med en litteraturstudie l˚ater sig endast g¨oras om f¨orfattaren sedan tidigare ¨ager adekvata kunskaper om problemomr˚adet. I den aktuella studien inled-des studien med intervjuer av Rask och Stene, vilket inte n¨odv¨andigtvis varit en optimal arbetsg˚ang. Tack vare de dialoger som f¨orts med Rask under arbetets g˚ang har detta dock inte haft allt f¨or stor inverkan p˚a studien.

Uppdelningen av intervjuomg˚angarna i en intervjuomg˚ang med best¨allare och en omg˚ang med leverant¨or var positiv, men var inte planerad fr˚an b¨orjan.

Dialogerna med Birgisson var inte s˚a frekventa som ¨onskat. Detta ledde till att valide-ringen av teststrategin inte varit s˚a rigid som ¨onskats. En mer frekvent dialog hade med stor s¨akerhet lett till en mer allm¨angiltig teststrategi.

Till skillnad fr˚an aktionsbaserad forskning, s˚asom den vanligtvis uppfattas, har det utv¨arderande steget i denna studie reducerats till en utv¨ardering av en f¨oreslagen teststra-tegi, vilken utv¨arderats tillsammans med Scouterna. Detta beror till ¨overv¨agande del p˚a att arbetet med mjukvaran f¨or¨andrats under studien, vilket medf¨ort att tid och incitament saknats f¨or att inf¨ora f¨or¨andringarna under arbetets l¨optid.

F¨orfattaren ¨ar sedan tidigare v¨al f¨ortrogen med organisationen och projektet som studerats. Detta har dragits nytta av vid uttolkning av givna svar fr˚an intervjurespon-denterna, vilket inte n¨odv¨andigtvis framg˚ar av intervjudatan. Brannick och Coghlan [17] f¨orsvarar ett s˚adant f¨orfarande och framh¨aver den f¨orenklade ˚atkomsten av data och un-ders¨okningssubjekt som en tillg˚ang i forskningen.

Ett problem f¨or studien var den l˚anga tid under vilken studien f¨oretogs. Scoutnetpro-jektet har studerats under totalt femton m˚anader, vilket medf¨ort att m˚anga parametrar f¨or¨andrats under studien. Detta f˚ar bed¨omas vara den allvarligaste kritiken mot metodens validitet.

2.5.2 Validitet - felk¨allor

Inledande intervjuer med Rask och Stene f¨oretogs utan ljudinspelning. De anteckningar som togs bygger d¨arf¨or p˚a situationsberoende tolkningar. Efterf¨oljande dialoger var till stor hj¨alp f¨or att f¨ortydliga och klarg¨ora dessa tolkningar.

Det faktum att intervjuerna av Rask, Stene och Flynn skedde p˚a tre olika spr˚ak (svens-ka, norska och engelska) ger sk¨al f¨or att anta att information fallit bort och f¨orvanskats vid ¨overs¨attningen till och fr˚an svenska, d˚a exaktheten i b˚ade fr˚agest¨allning och svar g˚ar f¨orlorad. Detta ¨ar ett k¨ant problem. ¨Aven h¨ar var efterf¨oljande dialoger till stor hj¨alp.

3

Teoretisk bakgrund

Studien avhandlar framf¨orallt testning och validering i utvecklingen med Scoutnet, men ber¨or ¨aven andra delar av utvecklingsprocessen, s˚asom krav- och leveransprocesserna. Det-ta kapitel vill ge en ¨oversikt ¨over utvecklingsprocessen i allm¨anhet och testprocessen i syn-nerhet. Testmetoder och deras roller i agila utvecklingsprocesser konstrateras mot motsva-rande metoder och roller i mer traditionella, vattenfallsbaserade metoder. Kapitlet inleds med en ¨oversikt ¨over agila utvecklingsmodeller f¨or att d¨arefter beskriva testprocessen p˚a djupet.

3.1 Agila utvecklingsmodeller

Termen agil mjukvaruutveckling introducerades 2001 i Manifesto for Agile Software Deve-lopment [18]. Manifestets f¨orfattare menar att en mer l¨attr¨orlig utvecklingsmodell i m˚anga fall ¨ar ett b¨attre alternativ ¨an mer traditionella metoder. Gemensamt f¨or de agila meto-derna ¨ar deras fokus p˚a ¨okad kundnytta genom t¨ata och fungerande leveranser.

Detta avsnitt kommer kort att beskriva n˚agra av de agila utvecklingsmodeller som har b¨aring p˚a arbetet.

3.1.1 Lean Development

Lean Development har sitt ursprung i det arbete hos framf¨orallt den japanska biltill-verkaren Toyota, som syftade till att str¨omlinjeforma produktionen av bilar genom att minimera sl¨oseri av resurser[19, 20]. Metodiken har visat sig vara framg˚angsrik p˚a m˚anga andra omr˚aden och anv¨ands ¨aven som en term inom agil mjukvaruutveckling [21].

Grundstenen i Lean ligger i att utnyttja ett projekts resurser p˚a b¨asta s¨att vid varje givet tillf¨alle. Man realiserar detta genom att iterativt unders¨oka och f¨orb¨attra sj¨alva arbetsprocessen. Germundsson [13] sammanfattar Lean som Lean is a way of thinking and an approach to decisions; it is applicable in any process. It is all about getting the right things to the right place at the right time.

3.1.2 Kanban

Kanban ¨ar, precis som Lean, sprunget ur Toyotas arbetsprocess och ¨ar i f¨orsta hand ett verktyg f¨or att visualisera processfl¨oden i projekt [22]. Som en agil utvecklingsprocess ¨ar den n˚agot annorlunda, med tre huvudsakliga komponenter: att visualisera arbetsfl¨oden, begr¨ansa p˚ag˚aende arbete och m¨ata ledtider.

Metodiken utg˚ar fr˚an en tavla, en fysisk eller virtuell s˚adan, d¨ar varje delmoment som m˚aste genomf¨oras representeras av ett kort. Dessa kort flyttas mellan kolumner p˚a tavlan, vilka alla representerar en m¨ojlig status, s˚asom exempelvis p˚ab¨orjad eller avslutad. Id´en bakom detta ¨ar att visualiseringen ska hj¨alpa till med att ge en ¨ogonblicksbild av hur utvecklingen fortskrider, samt vara ett verktyg f¨or att g¨ora de eventuella omprioriteringar som beh¨ovs f¨or att slutf¨ora ett projekt inom angivna tidsramar.

3.1.3 Scrum

Scrum ¨ar ett ramverk f¨or iterativ och adaptiv mjukvaruutveckling, vilken bygger vidare p˚a id´eerna som beskrivs i The Agile Manifesto [18]. Som process ¨ar Scrum inte helt fast, utan uppmuntrar varje enskilt team till att v¨alja just de delar av ramverket som passar f¨or det aktuella projektet [23].

Centralt i Scrum ¨ar insikten om att en produkts kravbild f¨or¨andras ¨over tid och att ut-vecklingsprocessen d¨arf¨or m˚aste st¨odja en f¨or¨anderlig kravbild. F¨or att kunna m¨ota denna f¨or¨anderliga kravbild arbetar Scrum-team med korta iterationer, kallade sprintar. Teamet m˚aste efter varje sprint leverera ett fungerande, om ¨an begr¨ansat, system. Scrum definierar en upps¨attning teamroller, h¨andelser och artefakter som anv¨ands f¨or att strukturera upp teamets arbete [23].

Scrum h¨amtar mycket inspiration fr˚an b˚ade Lean och Kanban. Ett exempel p˚a detta ¨ar visualiseringstekniken Scrumboard, vilken ¨ar en utveckling av Kanban-tavlan. Fr˚an Lean har Scrum l˚anat verktyg f¨or att iterativt utv¨ardera, f¨orst˚a och f¨orb¨attra utvecklingspro-cessen [21, 22, 23].

3.2 Testdriven utveckling

Testdriven utveckling, TDD, grundar sig p˚a en id´e om att en mjukvaras funktionalitet b¨or definieras utifr˚an en upps¨attning regler, vilka formaliseras som tester [24]. Tester, i form av enhetstester, skrivs vid TDD alltid innan produktionskoden p˚ab¨orjas. F¨or att s¨akerst¨alla att testerna fungerar f¨oruts¨atts testerna att fallera innan n˚agon produktionskod skrivs. Produktionskoden anses vara f¨ardig n¨ar alla p˚a f¨orhand uppsatta testfall uppfylls.

En ofta framf¨ord f¨ordel med TDD ¨ar att om de enhetstester som produceras i utveck-lingen anv¨ands vid regressionstestning, s˚a minskas antalet fel i produktionskoden ¨over tid, vilket ger utvecklingsteamet en ¨okad trygghet i att f¨or¨andra och f¨orb¨attra redan existe-rande kod.

3.2.1 Beteendedriven utveckling

En vidareutveckling av testdriven utveckling kallad beteendedriven utveckling (BDD), Behaviour-Driven Development p˚a engelska, presenterades 2006 [25]. Testfallen, som likt ovan formuleras innan n˚agon kod produceras, skrivs som anv¨andningsfall. Dessa anv¨ and-ningsfall best˚ar av en beskrivande del och en upps¨attning scenarier, vilka tillsammans beskriver funktionaliteten hos en avgr¨ansad del av mjukvaran. Scenarierna anv¨ands som acceptanstester f¨or leveransen.

3.2.2 Acceptanstestdriven utveckling

Acceptanstestdriven utveckling (ATTD), Acceptance Test-Driven Deveopment p˚a engels-ka, ¨ar en utvecklingsmetodik som s¨atter acceptanstester i fr¨amsta rummet. Metodiken bygger i grunden p˚a att ett antal acceptanstester definieras innan n˚agon produktionskod b¨orjar skrivas. N¨ar mjukvaruartefakten ¨ar skriven och acceptanstesterna g˚ar igenom kan mjukvaran anses vara f¨ardig att drifts¨attas eller levereras [25].

3.2.3 Kontraktdriven utveckling

Relaterat till test-, acceptanstest- och beteendedriven utveckling ¨ar kontraktdriven utveck-ling, i vilken mjukvarans funktionalitet beskrivs direkt i k¨allkoden. Ur k¨allkoden, i vilken funktionaliteten finns specificerad, genereras enhetstester och dessa f˚ar sedan utg¨ora ac-ceptanstester. Leitner m.fl. [26] beskriver en metod f¨or detta, vilken ¨ager giltighet f¨or projekt utvecklade i programmeringsspr˚aket Eiffel.

3.3 Inledande om mjukvarutestning

En entydig definition av begreppen test och testning saknas. Burnstein [27] definierar test-ning som “[..]a process used for revealing defects in software, and for establisihg that

the software has attained a specified degree of quality with respect to selected attribu-tes”. Denna definition f˚ar utg¨ora grund f¨or vidare resonemang kring testbegreppen i detta arbete.

Grunden f¨or all mjukvarutestning ¨ar en ¨onskan att s¨akerst¨alla kvaliteten i den mjukvara som utvecklas. Processen f¨or detta kan d¨arf¨or ses som en garant f¨or kvalitet [27], men ¨

ar ¨aven ett st¨od f¨or programmerare [12, 24]. Detta kapitel ¨onskar ge en ¨overblick av testprocessen, samt de tekniker som den innefattar.

3.3.1 Testprocessen

Testprocessen ¨ar den delprocess i utvecklingsprocessen, i vilken utvecklade artefakter va-lideras och verifieras. Daich m.fl. definierar validering som “[..]the process of evaluating a software system or component during, or at the end of, the development cycle in order to determine whether it satisfies specified requirements” [28]. P˚a liknande s¨att definierar de verifiering som “[..]the process of evaluating a software system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase”. I allm¨anhet associeras validering med exekvering av koden med hj¨alp av f¨ordefinierade testfall, medan verifiering associeras med granskning av leverabler [27].

Beroende p˚a vilken typ av utvecklingsprocess som anv¨ands i ett utvecklingsprojekt kan testprocessen te sig p˚a olika s¨att. Grovt sett kan tv˚a indelningar sk¨onjas: traditionella, vattenfallsbaserade testprocesser och agila testprocesser [29] (se figur 2).

Figur 2: Testprocessen som del i utvecklingsprocessen. Testaktivteter ¨ar markerade i r¨ott. Vattenfallsbaserade testprocesser bygger p˚a efter varandra kommande faser, i vilka olika aspekter av leverablerna granskas. Detta f¨orfarande g¨or testprocessen f¨oruts¨agbar, men kan inneb¨ara att fel uppt¨acks sent och d¨arf¨or f¨ordyrar projektet [27, 29].

uppt¨ackas tidigt och ofta. Metodiken underst¨odjer ¨aven en utvecklingsmodell med f¨or¨ and-erlig kravbild [16, 29].

En organisations testmognad kan beskrivas med hj¨alp av Test Maturity Model in-tegration (TMMi) [30]. Modellen definierar fem niv˚aer, ben¨amnda niv˚a 1 – 5, d¨ar varje niv˚a best˚ar av en upps¨attning test- och kvalitetsrelaterade aktiviteter (se figur 3). TMMi kr¨aver inte att en organisation uppfyller alla aktiviteter som specificeras p˚a en given niv˚a f¨or att organisationen ska kunna uppn˚a n¨astf¨oljande niv˚a, men organisationer avr˚ads fr˚an ett s˚adant tillv¨agag˚angss¨att, d˚a detta f¨orfarande ofta ¨ar kontraproduktivt. En organisa-tion, i vilken dessa aktiviteter utf¨ors utan plan eller helt saknas, s¨ags befinna sig p˚a niv˚a 1. I organisationer som opererar p˚a denna niv˚a ¨ar testresultaten s¨allan repeterbara och mjukvarans kvalitet kan d¨arf¨or inte s¨akerst¨allas [27, 30].

Figur 3: De fem niv˚aerna i TMMi.

3.3.2 Testplanering

Oavsett vilken utvecklings- och testprocess som anv¨ands, s˚a m˚aste testaktiviteterna pla-neras p˚a n˚agot s¨att. Utan en plan f¨or detta tenderar testaktiviteterna att tappa sitt v¨arde [27, 31]. Arbetet med detta kan grovt delas in i tv˚a delar: teststrategier och testpla-ner [29, 31].

Crispin [29] definierar teststrategin som “[..]a static document that seldom changes, a long-term plan of action. It is documentation about your overall test aproach to projects”.

En teststrategi ¨ar ett organisatoriskt dokument som b¨or vara fri fr˚an detaljer r¨orande implementationen av sagda strategi [31].

Testplanen definieras av IEEE [32] som “A document describing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning”. Ur ett agilt perspektiv ¨ar testplaner enligt denna definition on¨odigt tunga, varf¨or testplanen som eget dokument ofta utel¨amnas i agila projekt [29]. Med en enklare definition av begreppet kan testplaner fortfarane relativt enkelt anv¨andas ¨aven i agila projekt. Ett exempel p˚a en s˚adan definition ges av Burnstein: “A [test] plan is a document that provides a framework or approach for achieving a set of goals” [27]. Oavsett om en testplan fastst¨alls som ett eget dokument eller ej b¨or en testplanering genomf¨oras f¨or att s¨akerst¨alla att n¨odv¨andiga aktiviteter utf¨ors p˚a ett tillfredsst¨allande vis [29].

3.3.3 Testmetoder

Ut¨over de granskningar av krav som g¨ors f¨or att s¨akerst¨alla att r¨att mjukvara utvecklas finns ett flertal tekniker och metoder som kan till¨ampas av testare och programmerare. Det h¨ar avsnittet avser ge en ¨oversikt ¨over den verktygsl˚ada som st˚ar testaren och utvecklaren till buds.

F¨or att s¨akerst¨alla att mjukvaran fungerar p˚a en grundl¨aggande niv˚a anv¨ands ofta en teknik kallad enhetstestning. Med denna teknik skrivs tester f¨or kodens minsta enheter, exempelvis f¨or enskilda klasser i objektorienterade spr˚ak [27]. Enhetstester kan ses som b˚ade specifikation och dokumentation av den kod som testas och testerna b¨or d¨arf¨or skrivas p˚a ett s¨att s˚a att de t¨acker b˚ade ¨onskade och o¨onskade anv¨andningsfall. Extra fokus l¨aggs ofta vid gr¨ansfallen mellan dessa fall. En f¨ordel med att testa just gr¨ansfallen ¨ar att fel ofta uppst˚ar kring dessa, vilket g¨or att fel som kunnat propagerats upp˚at i mjukvaran hittas tidigt i utvecklingsprocessen och d¨arf¨or ¨ar billigare och enklare att ˚atg¨arda. Idealt skrivs enhetstester som helt isolerade tester, d¨ar de enskilda enheterna testas oberoende av annan kod. Detta l¨oses ofta med hj¨alp av mock-objekt, vilka simulerar ¨onskad funktionalitet [27, 24]. Ett viktigt argument f¨or att skriva enhetstester ¨ar att defekter snabbt kan f˚angas upp n¨ar koden f¨or¨andras. Jeffries m.fl. [24] h¨avdar att ett utvecklarteam vars mjukvara t¨acks av m˚anga och relevanta enhetstester ¨ar mindre r¨adda f¨or att g¨ora stora f¨or¨andringar i sin k¨allkod ¨an team utan dessa tester. Enhetstetster skrivs p˚afallande ofta av programmerarna sj¨alva.

N¨ar mjukvarans grunder antas fungera utf¨ors som regel integrationstester [27]. Dessa tester s¨akerst¨aller att de olika mjukvarumodulerna fungerar med varandra p˚a ett korrekt s¨att. Fokus ligger p˚a funktionalitet framf¨or andra aspekter, s˚asom anv¨andbarhet, prestan-da, s¨akerhet. De enskilda testfallen skrivs vid integrationstestning p˚a ett s˚adant s¨att att kommunikationen mellan ett mjukvarusystems olika delar testas. Integrationstestning ¨ar s¨arskilt viktig n¨ar mjukvaran integrerar mjukvara fr˚an tredje part.

Den sista fasen i en utvecklingscykel utg¨ors ofta av systemtestning [27], d˚a den kod som ska levereras testas i sin helhet. I denna fas testas f¨orutom funktionalitet ¨aven and-ra aspekter av mjukvarusystemet, s˚asom prestanda, s¨akerhet, skalbarhet, anv¨andbarhet och installation. I m˚anga agila utvecklingsmodeller utg¨or systemtestningen inte alltid en

separat del av utvecklingen, d˚a varje sprint idealt ska resultera i en k¨orbar version av mjukvarusystemet, d¨ar de enskilda komponeneterna och deras funktionalitet testats och och validerats i samband med utvecklingen av dem.

Innan mjukvaran levereras utf¨ors acceptanstester, vanligtvis i samarbete med kunden. Dessa tester b¨or definieras i samband med kravst¨allningen och utg¨or d˚a en del av den gemensamma m˚albild som kund och best¨allare kommer ¨overens om [27]. Acceptanstester utg¨ors ofta inte av enbart funktionella krav, utan ¨aven av kvalitativa s˚adana. Stress-, s¨akerhets- och anv¨andbarhetstestning ¨ar exempel p˚a s˚adana aktivteter [27].

Ut¨over de funktionella kraven, som beskriver hur en mjukvara ska fungera, m˚aste ¨

aven de icke-funktionella kraven tas i beaktande. Ett expempel p˚a en testmetodik av icke-funktionella krav ¨ar anv¨andbarhetstestning [27, 29]. Vid anv¨andbarhetstestning utv¨arderas mjukvarans anv¨andbarhet f¨or att s¨akerst¨alla att den levererade mjukvaran lever upp till de, ibland dolda, krav som slutanv¨andarna st¨aller p˚a mjukvaran. Fokus b¨or ligga p˚a att maximera effektiviteten f¨or anv¨andarna och minimera upplevd frustration med mjukvaran. Anv¨andbarhetstestning utf¨ors genom kvalitativa studier av slutanv¨andare som anv¨ander mjukvaran, ibland tillsammans med expertgranskning av samma mjukvara.

¨

Aven om m˚anga fel f˚angas upp av programmerarnas analyser och enhetstester, samt av testarnas integrations- och systemtester, missas m˚anga defekter. En metod som anv¨ands f¨or att hitta dessa dolda fel ¨ar utforskande testning. Denna testteknik ¨ar enligt Crispin [29] s¨arskilt viktig vid agil utveckling.

N¨ar en f¨or¨andring g¨ors i kodbasen, oavsett om det ¨ar i form av ny eller f¨or¨andrad funktionalitet, finns en ¨overh¨angande risk f¨or att f¨or¨andringen ger o¨onskade effekter i andra delar av systemet. F¨or att minimera dessa effekter k¨ors m˚anga tester om inf¨or varje leverans. Detta tillv¨agag˚angss¨att kallas regressionstestning [27, 29].

D˚a manuell testning ¨ar tids¨odande och os¨aker p˚a grund av den m¨anskliga faktorn anv¨ands ofta automatiserade tester, framf¨orallt f¨or funktionella tester. Med ett automati-serat testf¨orfarande kan mjukvaran testas oftare och noggrannare ¨an annars. Detta medf¨or att regressionstester blir ekonomiskt f¨orsvarbara, vilket har en tydligt positiv inverkan p˚a mjukvarans kvalitet [27, 33]. Crispin [29] argumenterar f¨or att automatiserade tester b¨or anv¨andas f¨or att frig¨ora ytterligare resurser till utforskande testning. Ghahrai [11] argu-menterar p˚a ett liknande s¨att f¨or att l˚ata merparten av testningen vara automatiserad f¨or att frig¨ora resurser p˚a exempelvis testning av mjukvarans anv¨andargr¨anssnitt (se figur 4). I samband med agila utvecklingsprocesser talas ofta om kontinuerlig integration [24, 33] och kontinuerlig leverans [34] som viktiga verktyg f¨or att f¨orkorta ledtiden mellan krav och leverans. D˚a kontinuerlig integration och leverans bygger en h¨og grad av automa-tisering m˚aste testsviterna till ¨overv¨agande del best˚a av automatiserade tester. Jeffries och Stolberg [24, 33] argumenterar d¨arf¨or f¨or att mycket tid b¨or l¨aggas p˚a att skriva bra enhetstester samt att samtliga tester k¨ors vid varje bygge av kodbasen.

Marick [12] argumenterar f¨or att det finns tv˚a huvudsakliga anledningar till att testa en mjukvara. Dessa ¨ar att underst¨odja programmeringen och att kritisera produkten. Han klassificerar testfaserna och testmetoderna som teknik- eller aff¨arsriktade. Dessa tv˚a dimensioner av testning sammanfogar han till en testmatris (se figur 5), vilken Ghahrai [11] anv¨ander som visuellt st¨od i sin f¨oreslagna mall f¨or agila teststrategier.

Figur 4: Ett rimligt f¨orh˚allande mellan automatiserade och manuella tester enligt Ghah-rai [11].

3.3.4 M¨atningar av testningsmoment

F¨or att unders¨oka och s¨akerst¨alla kvaliteten i testningsarbetet utf¨ors i m˚anga mjukvaru-projekt m¨atningar av testningsmomenten. I vattenfallsbaserade utvecklingsmetoder, d¨ar testning ofta ¨ar en separat aktivitet, ¨ar m¨atningar av denna typ legio [27]. Crispin och Gre-gory [29], som diskuterar m¨atningar utifr˚an ett agilt perspektiv, varnar f¨or att m¨atningar ibland kan vara skadliga f¨or produktiviteten i ett utvecklingsprojekt och argumenterar f¨or att bara anv¨anda m¨atningar n¨ar de verkligen g¨or nytta och inte tillf¨or mer arbete ¨an de sparar. De kallar detta tillv¨agag˚angss¨att lean metrics f¨or att knyta an till m¨atningarna som ett pragmatiskt verktyg. Gemensamt f¨or dessa syns¨att ¨ar att m¨atningar bara tillf¨or ett v¨arde om m¨atningarna analyseras och f¨oljs upp p˚a ett genomt¨ankt s¨att.

F¨or att tillf¨ora ett reellt v¨arde m˚aste utvecklingsteamet noggrant v¨alja vad som ska m¨atas och n¨ar detta ska g¨oras [29, 35]. I m˚anga fall kan m¨atdata samlas in automatiskt med hj¨alp av de utvecklingsverktyg som anv¨ands av utvecklingsteamet, vilket eliminerar fr˚agest¨allningen om n¨ar m¨atningen ska utf¨oras. ˚Aterst˚ar g¨or d˚a fr˚agest¨allningen om vad som ska m¨atas, eller i alla fall vad som ska analyseras. En potentiellt god startpunkt ¨ar att m¨ata hur stor andel av kodbasen som t¨acks in av tester, vilket kallas kodt¨ackning. En h¨og kodt¨ackning indikerar att testningen som g¨ors ¨ar adekvat p˚a en basal niv˚a, men det ¨

ar inte n¨odv¨andigtvis indikativt f¨or hur v¨al testerna ¨ar utformade [29]. Detta m¨atv¨arde s¨ager inte heller mycket om kodens kvalitet [27].

Figur 5: Maricks testmatris [12].

uppn˚a modellens fj¨arde niv˚a implementera en m¨atande och utv¨arderande testorganisa-tion [30]. D˚a kvaliteten p˚a testerna till stor grad ¨ar indikativ f¨or den levererade mjukvarans kvalitet [24, 27] kan en testprocess av dokumenterat h¨og kvalitet vara ett s¨aljargument f¨or den utvecklande organisationen gentemot existerande och potentiella kunder.

F¨or att kunna s¨aga n˚agot om kvaliteten hos testfallen m˚aste dessa analyseras mer i detalj. Exempel p˚a aspekter som kan analyseras ¨ar grent¨ackning, konditionst¨ackning, funktionst¨ackning och v¨agt¨ackning [27]. F¨or denna typ av testanalys finns ofta verktyg till hj¨alp, vilket minskar b¨ordan f¨or utvecklingsteamet.

3.3.5 Hur mycket b¨or testas? - Kort om testt¨ackning

Testaktiviteter ¨ar kostsamma och prioriteras ofta ner till f¨orm˚an f¨or ytterligare produk-tionskod. P˚a l˚ang sikt tenderar detta att vara betydligt kostsammare ¨an att faktiskt utf¨ora testningen, d˚a defekter inte f˚angas upp under utvecklingen om testningen prio-riteras bort [24, 27]. Att hitta det l¨age i vilket testaktiviteterna ¨ar ekonomiskt f¨orsvarbara ¨

ar d¨arf¨or av h¨og vikt.

F¨orespr˚akare f¨or XP talar ofta om syns¨attet test everything that could possibly break. Detta betyder f¨or en XP-utvecklare att programkoden ska analyseras och testas i de fall d¨ar mjukvaran kan g˚a s¨onder, vilket inte ¨ar det samma som att verkligen testa all programkod. Den statiska analysen i form av kontinuerlig granskning av koden, under vilken den kod som inte anses kunna g˚a s¨onder identifieras, ¨ar f¨or ett XP-team en lika viktig del av testningen som skrivandet och exekveringen av faktiska testfall [24].

dessa processer anv¨ander ofta matematiska modeller f¨or att avg¨ora n¨ar testaktiviteterna inte l¨angre ¨ar ekonomiskt f¨orsvarbara [36].

M˚anga team v¨aljer att ha en n˚agot mer avslappnad attityd till n¨ar testningen kan anses vara klar. De kriterier som anses uppfylla avslutad testning kan d˚a innefatta att teamet k¨anner sig f¨ardigt med testningen baserat p˚a en allm¨an konsensus eller att projektledaren anser vara testningen vara avslutad [13].

Fr˚agan om n¨ar en artefakt ¨ar adekvat testad f˚ar anses vara fortsatt sv˚arbesvarad och ¨

oppen.

3.3.6 Vem som ansvarar f¨or testningen

I st¨orre projekt kan testarbetet vara delegerat till speciella grupperingar av dedikerade tes-tare. Detta har f¨ordelen att testarna kan specialisera sig p˚a just testaktiviteter och d¨armed h¨oja kvaliteten i testarbetet, samt att risken f¨or intressekonflikter av leverera fungerande kod kontra leverera mycket funktionalitet minimeras [27, 29]. Ofta ¨ar dessa grupperingar underst¨allda en st¨orre kvalitetss¨akringsorganisation. I mindre projekt och ¨aven i m˚anga st¨orre agila projekt ¨ar uppdelningen mellan utvecklare och testare mer flytande. Detta g¨or att testarna har en klarare f¨orst˚aelse f¨or den underliggande k¨allkoden [24, 29]. Burnste-in [27] f¨orordar d˚a att en utvecklingsorganisation tills¨atter en testspecialist, ¨aven om denna ¨

aven ¨ar delaktig i programmeringsarbetet. Testspecialistens uppgift ¨ar att tillse att fast-slagna riktlinjer och uppsatta regler f¨or testningen efterf¨oljs, samt att f¨oresl˚a och genom-driva f¨orb¨attringar i arbetet med testningen. Crispin och Gregory [29] f¨oresl˚ar p˚a liknande s¨att att ett agilt team b¨or ha en medlem med tydligt ansvar f¨or kvalitetss¨akringsarbetet. I m˚anga vattenfallsbaserade mjukvaruprojekt utf¨ors viss testning av mjukvarans fram-tida anv¨andare eller av best¨allarens representanter redan innan acceptanstestningen [27]. Dessa testningsfaser, kallade alfa- och betatestning, utf¨ors i slutfasen av en utvecklingscy-kel p˚a initiativ av utvecklingsteamet. I dessa testningsfaser s¨akerst¨aller utvecklingsteamet att de verkligen levererar r¨att produkt. Eventuella fel som uppt¨acks tas om hand och rapporteras.

4

Bakgrund

4.1 Scoutnets historik

Scouternas nuvarande verksamhetsst¨odsystem, Scoutnet, ¨ar resultatet av ett utvecklings-arbete som p˚ab¨orjades 2010 [6]. Utvecklingen utgick fr˚an arbetet med det nya anm¨ al-ningssystem som NSF redan p˚ab¨orjat under 2008 i samband med att deras sommarl¨ager Landslejr beh¨ovde ett verktyg f¨or att hantera anm¨alningar. Detta verktyg v¨axte efterhand till ett fullskaligt verksamhetsst¨odsystem, som fick namnet ScoutNet [7]. ScoutNet ersatte vid inf¨orandet i Norge ett tidigare nyckelf¨ardigt st¨odsystem, som inte upplevdes uppfylla de speciella krav som NSFs verksamhet st¨allde.

Den omedelbara anledningen till att SSF l¨amnade sitt tidigare verksamhetsst¨odsystem, kallat Melker, var att den tidigare leverant¨oren under 2010 sade upp sitt avtal med SSF med sex m˚anaders varsel [6]. Med s˚a kort varsel gavs inte mycket tid f¨or att g¨ora en

mellan upps¨agning av avtalet och drifts¨attning av Scoutnet medf¨orde att kravbilden inte var helt klar f¨or den nya leverant¨oren, Redpill Linpro [6, 8]. Sammantaget med initiala kommunikationsproblem parterna emellan ledde detta till att den f¨orsta leveransen inte motsvarade de f¨orv¨antningar som byggts upp hos SSFs medlemmar [6, 7].

Runt ˚arsskiftet 2010/2011 tillsattes en heltidstj¨anst f¨or att ansvara f¨or vidareutveck-lingen av Scoutnet. En av de f¨orsta stora leveranserna innefattade medlemsfaktureringen, vilken skulle f¨orenkla den ekonomiska administrationen f¨or scoutk˚arerna. Inte heller denna leverans fungerade bra, beroende p˚a integrationsproblem mellan Scoutnet och Scouternas ekonomisystem, vilket levererades av Hogia [6].

Efter att till en b¨orjan ha utvecklats parallellt av SSF och NSF togs under 2011 initiativ till ett ¨okat samarbete organisationerna emellan. Detta samarbete ledde till att mer och mer funktionalitet kom att utvecklas gemensamt [7].

De b˚ada scoutf¨orbunden Svenska scoutf¨orbundet och KFUMs scoutf¨orbund slogs sam-man den f¨orsta januari 2012. Som en del av det omfattande sammanslagningsarbetet bygg-des ¨aven f.d. SSFs verksamhetsst¨odsystem, Scoutnet, om f¨or att ¨aven kunna hantera de medlemmar som tidigare tillh¨ort KFUMs scoutf¨orbund, vilket medf¨orde stora kostnader och ett avbr¨ack i det ordinarie utvecklingsarbetet. Till detta kom ¨aven en omorganisation av Scouternas folkh¨ogskola, samt nya regler f¨or statsbidrag, b˚ada med stor inverkan p˚a verksamhetsst¨odsystemet, vilket sammantaget lett till att utvecklingen av Scoutnet inte fortskridit p˚a ett s¨att som kommit flertalet medlemmar till gagn i sitt dagliga scoutarbete. Under 2014 sade Redpill Linpro upp samarbetet med NSF och Scouterna i samband med avdelningen som arbetade med utvecklingen av Scoutnet/ScoutNet lades ner. Ett interimavtal kring fortsatt utveckling ingicks med Custard Labs, som drivs av Russel Flynn, vilken tidigare arbetat med Scoutnets utveckling p˚a Redpill Linpro [6].

4.2 Scoutnets uppbyggnad

Scoutnet ¨ar realiserat som en MySQL-databas med en backend skriven i PHP p˚a ramverket Symfony. Frontenden ¨ar skriven i HTML med en del Javascript [8]. Delar av funktionali-teten ¨ar exponerad via ett publikt API.

Driften av Scoutnet sk¨ots av ett f¨oretag i Stockholm, vilket har placerat tj¨ansten p˚a ett svenskt datacenter [8].

4.3 Scoutnets utvecklingsprocess

Utvecklingen f¨or Scoutnet kan b¨ast beskrivas som ostrukturerat agil. Redpill Linpro be-skrev sin process som Scrum [8, 37], men detta har av tj¨anstem¨annen inte upplevts vara fallet. Ut¨over anv¨andning av sprintar, tickets och Kanban [37] anv¨ande Redpill Linpro inte n˚agot av de verktyg som utg¨or Scrum. Avstegen fr˚an Scrum beskrivs som s¨arskilt allvarliga i de fall d¨ar n˚agra sprintar inte avslutades med en sprintgranskning, samt de fall d¨ar sprintarna inte reslulterade i en k¨orbar version av mjukvaran. Detta berodde enligt Rask p˚a att utvecklingsteamet vid ett flertal tillf¨allen saknade en projektledare som kunde ta ett ¨overgripande ansvar f¨or sprintarna. I en del av dessa fall fick Rask sj¨alv tr¨ada och projektleda utvecklingsteamet, n˚agot han inte har n˚agon formell tr¨aning f¨or [6].

¨

Aven Stene [7] p˚apekar brister i Redpill Linpros utvecklingsprocess. Redpill Linpros ursprungliga plan var att dela upp utvecklingen i tv˚a veckor l˚anga sprintar och f¨olja Scrum-modellen, men detta visade sig snart inte fungera. Stene anser att den direkta orsaken till brist p˚a testrutiner st˚ar att finna i detta skede, d˚a testningen st¨andigt prioriterats bort. Utvecklingsteamet satte inte heller upp n˚agra automatiska tester som hade kunnat s¨akerst¨alla funktionen inf¨or varje ny version av mjukvaran. Trots detta anser Stene att utvecklingsarbetet till stor del fungerat bra och att arbetet blev mer och mer strukturerat ¨

over tid. Hon tillstyrker dock att de regressionsfel som ¨aven Scouterna upplevt har pl˚agat utvecklingen genom produktens hela livscykel.

Flynn ber¨attar om hur utvecklingen under tiden med Redpill Linpro inledningsvis aktivt underestimerats f¨or att f˚a leverant¨oren att framst˚a i b¨attre dager, men vilket f˚att motsatt effekt [8]. F¨or att spara in p˚a tid valde projektledningen vid ett flertal tillf¨allen att spara in p˚a testningen, d˚a denna ans˚ags vara en on¨odig kostnad. Vidare saknades regressionstester, vilket innebar att en ¨andring i en del av systemet kunde p˚averka en till synes orelaterad del utan att detta f˚angades upp. Sammantaget konstaterar Flynn att orealistiska tids- och kostnadsestimat tillsammans med brister i leveranserna, vilka kan kopplas till avsaknad av en vedertagen teststrategi, haft en tydligt negativ inverkan p˚a utvecklingen och f¨orh˚allandet till best¨allarna.

Ut¨over brister i kvalitet p˚a leveranser har processen fr˚an insamlade krav till f¨ardig leverans blivit n˚agot mer strukturerad ¨over tid. Scouterna anser sig ha en klar bild av hur hela utvecklingsarbetet i stort ser ut, likas˚a NSF. Denna process beskrivs mer i detalj i avsnitt 4.3.1.

Sedan Custard Labs tagit ¨over utvecklingen har testningen f˚att en mer framtr¨adande roll [8]. Den nya leverant¨oren upplever att utvecklingsprocessen ¨over lag fungerar b¨attre nu ¨an tidigare, men pekar p˚a brist i redundans som en tydlig projektrisk.

4.3.1 Framtagande och prioritering av krav

Kravhanteringsarbetet i utvecklingsprocessen ˚aligger tj¨anstem¨annen. I fallet Scouterna finns det tv˚a fl¨oden f¨or insamling av krav (se figur 6). Det f¨orsta fl¨odet r¨or ny funktionalitet, vilket ¨ar fl¨odet som behandlas i detta avsnitt. Det andra fl¨odet r¨or felrapporter, men ¨aven sm˚a funktionalitetsf¨orb¨attringar, som av tj¨ansteman bed¨oms vara enkla nog att klara av utan att g¨ora en st¨orre investering [6]. Detta fl¨ode beskrivs i avsnitt 4.3.2.

Vid utveckling av st¨orre funktionalitet, av Rask ben¨amnt nyutveckling, samlar Rask in de personer som bed¨oms vara n¨armast ber¨orda av f¨or¨andringen till ett arbetsseminarium f¨or att generera id´eer och identifiera behov till kravarbetet. I de flesta fall best˚ar dessa grupper av kanslipersonal hos Scouterna. Utifr˚an insamlade behov och id´eer sammanst¨aller Rask en samling krav i form av ett antal anv¨andarfall. Kraven ¨ar p˚a relativt h¨og niv˚a, av typen Administrat¨oren ska kunna byta namn p˚a en anv¨andare. N¨ar dessa krav ¨ar samman-st¨allda skickas dessa till leverant¨oren via verktyget Redmine, som g¨or en estimering av tid och l¨amnar ett kostnadsf¨orslag [8]. Rask v¨aljer ut de krav han anser ha h¨ogst prioritet, och leverant¨oren ges i uppdrag att utveckla dessa [6, 8]. St¨orre investeringar i utveckling g¨ors efter beslut i styrelsen.

det Stene ensam som arbetar fram kraven. Lejonparten av kravarbetet i NSF utg˚ar fr˚an omedelbara behov som m˚aste tillfredst¨allas [7]. I ¨ovrigt liknar processen den som finns hos Scouterna.

Figur 6: Scoutnets utvecklingsfl¨ode enligt Rask.

4.3.2 Felrapportering och felhantering

Felrapportering sker i verkyget Redmine, vilket anv¨ants sedan Redpill Linpro var leve-rant¨or [7, 8]. Felen beskrivs s˚a noggrannt som m¨ojligt, inte s¨allan med r¨orliga sk¨ armdum-par [6]. ¨Ar felen v¨aldigt sm˚a rapporteras de ibland in via IRC. Dessa chatloggar sparas av leverant¨oren [8]. N¨ar ett fel rapporteras in handl¨aggs detta av en utvecklare, som estime-rar ber¨aknad tids˚atg˚ang f¨or att reparera felet. Utifr˚an detta tidsestimat s¨atts ett pris p˚a ˚atg¨arden, och best¨allaren har att besluta om ˚atg¨arden ska utf¨oras eller senarel¨aggas [6].

De huvudsakliga k¨allorna till inrapporterade fel ¨ar tj¨anstem¨annen sj¨alva i samband med acceptanstestning, men m˚anga fel rapporteras ¨aven in av slutanv¨andare via telefon, e-post och Get Satisfaction. Slutanv¨andarna rapporterar aldrig sj¨alva in i Redmine, som anv¨ands uteslutande av tj¨anstem¨an, utvecklare och den idella arbetsgrupp som arbetar med Scoutnet i Sverige [6].

4.3.3 Leverans och acceptans av leverabler

Efter varje sprint, som kan variera i tidsrymd och omf˚ang, levereras en leverans p˚a en utvecklingsserver f¨or initiala tester [6, 7]. Om denna upplevs vara nog stabil och felfri

drifts¨atts denna version p˚a en stagingserver. Denna leverans innefattar k¨allkod, inklu-derat aktuell sprints tickets, markerade med en tag [6]. I samband med detta uppda-teras uppgifterna i Redmine, och utifr˚an dessa uppgifter genereras en lista ¨over gjorda f¨or¨andringar [6]. Leveransen testas, baserat p˚a listan ¨over gjorda f¨or¨andringar, igenom av best¨allaren och n¨ar best¨allaren upplever att leveransen ¨ar bra nog l¨aggs en best¨allning p˚a drifts¨attning [6, 7, 8]. Eventuella fel inrapporteras i Redmine f¨or vidare ˚atg¨ard. N¨ar en leveransbest¨allning l¨aggs uppdaterar leverant¨oren aktuell produktionsserver och denna testas igenom f¨or att hitta eventuella uppenbara fel.

Efter att Custard Labs tagit ¨over utvecklingen har Flynn f˚att m¨ojlighet att delvis fr˚ang˚a de rutiner som trots allt fanns hos Redpill Linpro. Han ber¨attar att han fram¨over ser en m¨ojlighet till mer frekventa, men mindre, leveranser. Detta skulle inneb¨ara att enklare bugfixar skulle kunna komma anv¨andarna till godo betydligt snabbare ¨an vad de g¨or idag [8].

4.3.4 Nuvarande testningsf¨orfarande

I nul¨aget finns ingen formaliserad testprocess hos de best¨allande organisationerna. Det som n¨armast kan liknas vid acceptanstester ¨ar de tester som genomf¨ors av Rask och Stene vid leverans av ny mjukvara. Dessa tester ¨ar ostrukturerade till sin natur, utan att f¨or den sakens skull kunna anses utg¨ora formaliserad utforskande testning [6, 7, 8]. ¨Aven hos Redpill Linpro saknades en formaliserad testprocess [8]. Likas˚a saknas en s˚adan process idag hos Custard Labs.

Avsaknaden av en formaliserad testprocess hos b˚ade leverant¨orer och best¨allare place-rar dem p˚a niv˚a 1 enligt TMMi [30].

4.3.5 Scoutnets ideella arbetsgrupp

Till utvecklingen av Scoutnet finns en ideell arbetsgrupp knuten [6]. Dess arbetsuppgifter har innefattat att bist˚a Rask med kravst¨allning, testning och utv¨ardering av leveranser, samt utbildning och dialog med slutanv¨andarna. Arbetsgruppens arbete har varit av varie-rande intensitet, vilket medf¨ort att gruppen aldrig varit en fast del av utvecklingsprocessen. Snarast kan gruppen ses som en hj¨alporganisation som bist˚att Rask i hans arbete.

I samband med ett omorganisationsbeslut taget i februari 2015 [38] blev arbetsgruppen suspenderad tills vidare, s˚a n¨ar som p˚a en person som arbetar med utbildning.

4.3.6 F¨orh˚allandet mellan Scouterna och leverant¨oren

Custard Labs, liksom Redpill Linpro innan dem, utvecklar och f¨orvaltar Scoutnet [6, 7]. Detta inneb¨ar att de inte ¨ager produkten, vilket g¨or att utvecklaren inte har varit s¨arskilt drivande i vidareutvecklingen av produkten. F¨orh˚allandet mellan de b˚ada scoutorgani-sationerna ˚a ena sidan och leverant¨oren p˚a anda sidan ¨ar d¨arf¨or att anse som ett rent best¨allar- och utf¨orarf¨orh˚allande.

I den tidigare konstellationen med Redpill Linpro som leverant¨or hindrade inte detta att leverant¨orens utvecklare tog egna initiativ och utvecklade delar av systemet utan att ha f¨ardiga krav fr˚an de b˚ada best¨allarorganisationerna, vilket var en k¨alla till frustration, fel

och f¨orseningar [6]. Kvaliteten p˚a utvecklingen var ocks˚a personberoende, d˚a leverant¨oren tidvis inte hade tillsatta projektledare som ledde utvecklingsarbetet [6]. B˚ade Rask och Stene beskriver att Scouterna haft kommunikationsproblem med Redpill Linpro, n˚agot som NSF f¨or egen r¨akning inte upplevt i samma utstr¨ackning [6, 7]. Skillnaden i upp-levd kommunikationsf¨orm˚aga antogs allm¨ant ha berott p˚a spr˚akbarri¨arer och det faktum att medan Scouternas tj¨ansteman ¨ar anst¨alld p˚a att arbeta med Scoutnet p˚a 100% ¨ar motsvarande tj¨anst hos NSF endast p˚a 20% [7].

4.3.7 F¨orh˚allandet mellan Scouterna och Norges speiderforbund

Scouterna och NSF ¨ager gemensamt k¨allkoden till Scoutnet och ScoutNet [6]. Kostnaden f¨or utvecklingen f¨ordelas mellan organisationerna p˚a ett inte helt transparent vis, men beskrivs som att delas solidariskt f¨or grundfunktionalitet, medan organisationsberoende funktionalitet betalas av best¨allande organisation. Sterne beskriver samarbetet som per-sonberoende och p˚apekar att samarbetet organisationerna emellan fungerar b¨attre sedan Scouterna tillsatte en heltidstj¨anst f¨or utvecklingsarbetet med Scoutnet [7].

Samarbetet sker framf¨orallt p˚a tj¨anstemannaniv˚a, d¨ar id´eer organisationerna emellan utbyts p˚a ett ostrukturerat s¨att med hj¨alp av e-post, IRC-samtal, Google Hangout och infrekventa fysiska m¨oten [6, 7]. F¨or arbete med gemensamma krav och uppgifter anv¨ands Trello och Google Apps [6].

Frekvensen f¨or fysiska m¨oten beskrivs som att ha varit h¨ogre tidigare, men d˚a tj¨ ans-tem¨annen, Rask och Sterne, l¨art k¨anna varandra b¨attre har man valt att dra ner p˚a antalet fysiska m¨oten till f¨orm˚an f¨or distansbaserade kontaktformer [7]. I den tidigare fasen av samarbetet, d˚a fysiska m¨oten var mer frekventa, alternerade m¨otesplatserna mellan Stockholm och Oslo, som ¨ar organisationernas respektive s¨aten. Vid en del av dessa m¨oten n¨arvarade ¨aven representanter fr˚an utvecklaren, Redpill Linpro [7].

Samarbetet sker ¨aven p˚a en strategisk niv˚a, d¨ar organisationernas respektive general-sekreterare samtalar om organisationiska f¨or¨andringar, f¨or¨andringar r¨orande leverant¨oren och potentiella samarbeten med andra organisationer [6]. Som en del av detta arbete har ¨

aven fr˚agan om ett ¨oppnande av kodbasen f¨or att attrahera andra samarbetspartners lyfts fram [7].

4.4 F¨or¨andringar i Scouternas organisation

Den 19:e februari 2015 meddelades att utvecklingen f¨or¨andras p˚a grund av f¨or¨andringar i Scouternas organisation [38]. Som en f¨oljd av omorganisationen kommer Scoutnet inte l¨angre att utvecklas p˚a samma s¨att som tidigare, utan ha ett tydligare fokus p˚a underh˚all. 4.4.1 Scouternas ¨ovriga digitala hj¨alpmedel

Scouterna har, f¨orutom Scoutnet, ett Wordpress-baserat verktyg f¨or publicering av webb-sidor [39]. Detta verktyg anv¨ands av Scouterna f¨or att realisera sina b˚ada digitala kanaler, Scouterna.se [40] och Scoutservice [41]. Det anv¨ands ¨aven av Scouternas olika arrange-mangsgrupper, distriktsorganisationerna, samt ett flertal scoutk˚arer och av scoutr¨orelsen ¨

4.5 Liknande produkter

Ungdomsf¨orbundet Sverok, vilket har liknande krav p˚a sina verksamhetsst¨odsystem som Scouterna, tar ocks˚a fram sin egen mjukvara. Hos Sverok motsvarar mjukvaran eBas Scout-nets grundl¨aggande funktionalitet r¨orande hantering av medlemsregister och statsbidrags-ans¨okningar [42]. Sverok har valt att l¨agga utvecklingen i ett helbolag. Detta bolag, Sverok Admin AB, s¨aljer ¨aven vidare st¨odsystemen till andra organisationer [42]. Utvecklingspro-cessen liknar i viss m˚an den som Scouterna och dess leverant¨orer arbetat efter. Sverok Admin AB beskriver sin utvecklingsprocess som en f¨orenklad version av Scrum p˚a samma s¨att som Flynn beskriver utvecklingen hos Redpill Linpro [8, 42]. ¨Aven testprocessen liknar den som beskrivits f¨or Scoutnet i det att den av Gustavsson [43] beskrivs som odefinierad. Ny funktionalitet introduceras i fallet med eBas i f¨orsta hand av Sverok Admin AB. Innan funktionaliteten implementeras presenteras denna f¨or bolagets kunder och bryts ner till f¨ardiga krav. En viktig skillnad mellan hur Scoutnet och eBas finansieras f¨oreligger. Medan Scouterna och NSF best¨aller sin funktionalitet och betalar f¨or den faktiska utvecklingen, s˚a finansierar Sverok Admin AB sin utveckling genom att licensiera sin mjukvara till sina kunder [42].

5

Relaterat arbete

Germundsson [13] beskriver en fallstudie gjord p˚a Combitech, i vilken hon unders¨oker hur f¨oretaget bedriver testning i agila utvecklingsprojekt. Hennes slutsats ¨ar att det inte finns ett s¨att att bedriva testning som passar f¨or alla mjukvaruprojekt. Detta st¨ammer v¨al ¨overens med vad litteraturen sl˚ar fast [27, 29, 31]. Hon f¨oresl˚ar i sin rapport elva f¨orb¨attringsomr˚aden f¨or Combitechs testverksamhet.

Hedin och Birgisson [16] unders¨oker i sin master-uppsats hur kravhantering kan fungera i en agil utvecklingsmilj¨o baserad p˚a scrum. De f¨oresl˚ar en modell i vilken de mappar tester mot krav redan innan implementationsfasen tar vid.

B˚ada dessa unders¨okningar har gjorts p˚a respektive f¨oretags utvecklingsavdelningar, vilka var f¨or sig ¨ar st¨orre ¨an den samlade personalstyrka som arbetat med Scoutnet och ScoutNet. Likas˚a medf¨or fokuseringen p˚a de interna processerna i b˚ada unders¨okningarna att best¨allarens perspektiv hamnar i skymundan. Resultaten kan d¨arf¨or inte utan problem f¨oras ¨over p˚a Scoutnet, men unders¨okningarnas uppl¨agg och resultat ¨ar icke desto mindre intressanta i det att de b˚ada i n˚agon mening ber¨or sambandet mellan krav och tester i agila mjukvaruprojekt.

Ghahrai [11] f¨oresl˚ar en mall f¨or agila teststrategier, i vilken han utg˚ar fr˚an acceptan-skriterier och acceptanstester som grund f¨or utvecklingen och verifieringen av mjukvaran. Hur dessa acceptanskriterier b¨or utformas skrivs i Ghahrais f¨orslag in i strategin. Han f¨oresl˚ar ¨aven att teststrategin ska inneh˚alla en beskrivning av vad olika testaktiviteter inneb¨ar, n¨ar de ska utf¨oras och vem som ansvarar f¨or att de g¨ors. Utvecklingen f¨oruts¨atts i hans strategimall ske med hj¨alp av kontinuerlig integration.

6

Analys av insamlad data

En analys av insamlat material i f¨orh˚allande till den teoretiska bakgrunden har f˚att ligga till grund f¨or den levererade teststrategin.

6.1 F¨oruts¨attningar

B˚ade Custard Labs och de tv˚a scoutorganisationerna har funnit sig till r¨atta i den ¨ over-gripande utvecklingsmodell som nu f¨oreligger i form av modifierad Scrum. D˚a alla parter ¨

ar n¨ojda med detta b¨or teststrategin ta sin utg˚angspunkt fr˚an denna.

Custard Labs, NSF och Scouterna ¨ar var och en f¨or sig sm˚a organisationer. Efter bytet av leverant¨or till Custard Labs och med de nya f¨oruts¨attningar f¨or utvecklingen som Scouterna inf¨orde i februari 2015 ¨ar den totala bemanningen i utvecklingen ungef¨ar tv˚a heltidstj¨anster. Detta inkluderar en knapp heltidstj¨anst, uppdelad ¨over tv˚a organisationer, som sysslar med best¨allning. Leverant¨orens resurser best˚ar av en enda person som sk¨oter all utveckling och testning. Att avlasta denna enda resurs skulle kunna ge en st¨orre utv¨axling av de resurser som spenderas p˚a utveckling. Detta m˚aste dock g¨oras utan ¨okade kostnader. Ett alternativ f¨or detta ¨ar att anv¨anda den vilande ideella arbetsgruppen eller en arvtagare till denna f¨or enklare sysslor.

6.2 F¨orh˚allandet mellan best¨allare och utf¨orare

Det ¨ar viktigt att ett gott f¨orh˚allande mellan best¨allare och utf¨orare uppr¨atth˚alls. Om f¨ortroende mellan parterna saknas kommer utvecklingen onekligen att drabbas negativt. Detta m˚aste tas h¨ansyn till i arbetet med framtagande av en teststrategi.

Custard Labs uppvisar ett tydligt intresse f¨or att f¨orb¨attra sin utvecklingsprocess j¨amf¨ort med hur utvecklingen utf¨ordes hos Redpill Linpro. Detta b¨or utnyttjas av b˚ade Scouterna och NSF. De f¨or¨andringar som f¨oresl˚as, vilka analyseras i avsnitt 6.3 nedan, f¨oruts¨atter att Custard Labs ges ¨okade befogenheter g¨allande mindre leveranser. Teststra-tegin b¨or d¨arf¨or utformas p˚a ett s¨att att ett s˚adant f¨orfarande underst¨ods.

Det framg˚ar tydligt att regressionsfelen varit en k¨alla till mycket irritation hos Scou-terna. Detta skulle relativt enkelt kunna ˚atg¨ardas med en svit regressionstester som k¨ors inf¨or leveranserna. Dessa kan utg¨oras av exempelvis enhetstester och ¨aldre, men fortfaran-de aktuella, acceptanstestfall. En teststrategi b¨or bidra till att identifiera dessa kandidater till regressionstestfall.

De snabba kommunikationsv¨agarna mellan best¨allare och leverant¨or lyfts av alla parter fram som en tillg˚ang f¨or utvecklingen. Det ¨ar av stor vikt att en f¨oreslagen teststrategi inte f¨orsv˚arar denna kommunikation.

6.3 F¨orenklingar och f¨orb¨attringar

Det framg˚ar av intervjuerna att parterna har en f¨ardig upps¨attning verktyg f¨or kommuni-kation, dokumentation och kravhantering. D˚a ingen av parterna uttrycker n˚agot missn¨oje med dessa verktyg, och de inte heller har n˚agon direkt inverkan p˚a testf¨orfarandet l¨amnas

dessa verktyg utan vidare analys. Verktygen bed¨omns inte heller ha n˚agon inverkan p˚a teststrategin.

Flynn [8] p˚apekar att bristen p˚a regressionstester och automatiserade tester varit till skada f¨or utvecklingen historiskt sett. Inget visar p˚a att detta f¨orb¨attrats, men en vilja att ˚atg¨arda detta yttras av Flynn. D˚a automatiserade tester ¨ar betydligt billigare och dessutom mindre felben¨agna ¨an manuella [27] borde en teststrategi adressera dessa. Au-tomatiserade tester l¨ampar sig v¨al f¨or regressionstestning [24], vilket ytterligare st¨arker argumenten f¨or automatiserade tester.

¨

Aven om regressionstestning och automatiserade tester ¨ar bra och f¨orh˚allandevis billiga b¨ar de en initial kostnad, som f¨or ett relativt moget projekt som Scoutnet kan vara v¨aldigt h¨og. Det faktum att utvecklingstid och resurser l¨aggs p˚a att ta fram tester g¨or att det kan vara attraktivt att f¨ors¨oka minimera arbetet med framtagande av testfall. En metod f¨or detta ¨ar att enbart skriva tester f¨or ny kod och kod som f¨or¨andras [11, 29]. Burnstein argumenterar f¨or att ¨aven skriva tester f¨or de delar av mjukvaran som oftast anv¨ands och d¨arf¨or ses som mest driftskritisk. Teststrategin b¨or d¨arf¨or f¨oresl˚a att n¨ar regressionstester f¨or de basala delarna av Scoutnet tagits fram, ska enbart tester f¨or ny och f¨or¨andrad kod tas fram.

Givet att all kod inte kommer att kunna testas i ett initialt skede kan det vara av godo att inf¨ora n˚agon form av sp˚arbarhet i testarbetet. Ett s¨att skulle kunna vara att koppa inf¨orandet av specifika testfall eller testsviter mot enskilda tickets i Redmine.

Flynn ber¨attar att han ¨ar intresserad av att unders¨oka om kontinuerlig integration och leverans kan passa i leveransprocessen. Om en leveransmodell av detta slag visar sig fungera finns det potential f¨or besparingar i form av tid och pengar, samtidigt som Scou-terna snabbare kan reagera p˚a felrapporter och eventuella ut¨okningar av produkten. F¨or att underst¨odja detta arbete b¨or teststrategin speciellt unders¨oka hur acceptanskriterier definieras och hur tester f¨or dessa tas fram. I samband med detta b¨or BDD f¨oresl˚as som en m¨ojlig metod.

Givet Flynns intresse f¨or kontinuerlig integration och leverans, samt minskade perso-nella resurser, ¨oppnas en m¨ojlighet f¨or ¨okat deltagande f¨or ideella medarbetare, s˚asom det st˚ar n¨amnt i avsnitt 6.2. Teststrategin b¨or ta detta i beaktande och f¨orklara hur en teststrategi kan anv¨andas f¨or att m¨ojligg¨ora ett ¨oppnare arbetss¨att och p˚a sikt ¨aven ett eventuellt upp¨oppnande f¨or hela eller delar av produkten.

Under leveransprocessen anv¨ands en stagingserver, p˚a vilken nya leveranser installe-ras och sluttestas innan de drifts¨atts i produktionsmilj¨on. Denna server skulle, mellan leveranserna, kunna anv¨andas f¨or att finna fel utan att riskera datan i produktionsmilj¨on.

6.4 Externa aktiviteter

Unders¨okningen av omr˚adet visade att Sverok har ett verksamhetsst¨odsystem liknande Scoutnet. ¨Aven om deras eBas inte har b¨aring p˚a teststrategin b¨or Scouterna unders¨oka om produkten kan tillf¨ora n˚agot i utvecklingsarbetet. En m¨ojlig v¨ag fram˚at skulle kunna vara att Scoutnet ers¨atts med en modifierad utg˚ava av eBas.

7

Resultat

Ett f¨orslag till teststrategi f¨or Scoutnets vidare utveckling (se bilaga 6) har tagits fram. F¨oreslagen teststrategi bygger p˚a resultaten som presenterats i analyskapitlet och h¨amtar mycket inspiration fr˚an Ghahrais mall f¨or agila teststrategier [11].

7.1.1 Inledning och avgr¨ansning

Teststrategin inleds med en beskrivning av dokumentet och fastsl˚ar tidigt dess avgr¨ansningar. Strategin avhandlar testarbetet p˚a en h¨og niv˚a och ger inga detaljerade f¨orslag p˚a hur f¨oreslagna aktivteter ska realiseas. En koppling till kravarbetet identifieras, men f¨orklaras vara utanf¨or dokumentets dom¨an. M˚alet med dokumentet fastsl˚as vara att bidra till veri-fiering av best¨alld produkt snarare ¨an validering av framlagd best¨allning.

7.1.2 F¨oruts¨attningar

Avsnittet listar de f¨oruts¨attningar, vilka de f¨oreslagna ˚atg¨arderna grundar sig p˚a. Dessa f¨oruts¨attningar beskriver utvecklingsprojektets ing˚aende parter och parternas inb¨ordes roller. Inga f¨or¨andringar f¨oresl˚as, men strategin h¨avdar sin giltighet ¨aven om leverant¨oren byts ut mot en leverant¨or som arbetar p˚a liknande s¨att som Custard Labs. F¨or Scouternas vidkommande f¨oresl˚as en f¨orst¨arkning av den egna organisationen genom ett ˚aterinf¨orande av en ideell arbetsgrupp, men med f¨or¨andrade uppgifter.

Ett nytt leveransf¨orfarande som bygger p˚a ATTD och kontinuerlig leverans f¨oresl˚as. Dokumentet f¨orklarar de vinster som st˚ar att finna vid ett inf¨orande av nytt leverans-f¨orfarande, men ¨oppnar upp f¨or m¨ojligheten att fr˚ang˚a detta i sin helhet eller i specifika fall om best¨allande organisation inte ¨ar bekv¨am med f¨orfarandet. Teststrategin h¨avdar sin giltighet ¨aven om leveransmodellen inte f¨or¨andras.

Behovet av en gemensam definition av vad att vara f¨ardig med en leverabel, vilket tas upp av bland andra Ghahrai och Laxman [11, 31], p˚apekas och kopplas till ATTD. ¨Aven behovet av sp˚arbarhet i testningen avhandlas och kopplas bland annat till f¨orenklingar av framtida projekt- eller organisationsf¨or¨andringar.

7.1.3 Metoder och teori

En introduktion till testdriven utveckling, inkluderande BDD och ATTD, ges till teststra-tegins l¨asare. Det format p˚a vilket acceptanstester b¨or formuleras presenteras.

Vidare ges en ¨overblick av Maricks testkvadranter [12]. Kvadranterna sammanfattas med ett tydligt ¨overgripande syfte, exempelvis teknikorienterade tester som st¨ottar ut-vecklingsteamet. Varje kvadrant populeras med ett antal test- och utv¨arderingsaktiviteter, vilka beskrivs kortfattat.

Utifr˚an testkvadranternas beskrivningar f¨oresl˚as tre distinkta entiteter ing˚a i test-ningsf¨orfarandet. Dessa ¨ar utvecklarna (Custard Labs), best¨allarna (Scouterna och i f¨ o-rekommande fall NSF), samt en refrensgrupp (den ideella arbetsgruppen). Entiteternas