The Need for Automated Acceptance Testing in XP

Transkript

1 The Need for Automated Acceptance Testing in XP 14 Mars 1 Johan Astborg LTH, Lund University dt5ja7@student.lth.se ABSTRACT Automatisk acceptanstestning inom agil utveckling är något som kommit att bli avgörande i effektiva team och projekt. I den här artiklen undersöks från ett XP perspektiv i ett team bestående av tio utvecklare under sju hela dagar. Vikten av automatisering lyfts fram och författaren tar hjälp av en enkätundersökning för att fastställa vad som är bra och vad som kan förbättras med inom agil utveckling. En tämligen kontroversiell gränsöverskridning görs då författaren låter utvecklarna ansvara helt för acceptanstesterna, vilket betyder att en dedikerad testare helt tagits bort. Detta strider mot traditionell XP, men var nödvändigt för att få metodiken att passa in i vårt team. Slutligen noteras att mycket finns att göra på området och verktygen, FIT och, är inte riktigt mogna. Det finns utrymme för en hel del forskning och utveckling på området, där en standard vore lämplig. 1. INLEDNING Testning är en av de viktigaste faktorerna inom mjukvaruutveckling [3]. Extreme Programming tar testning till ytterliggare en nivå med TDD, Test Driven Development [3]. Test Driven Development skrivs testerna före själva funktionaliteten börjar implementeras i form av kod [4]. Trenden att automatisera stora delar av utvecklingsprocessen och integrera dessa i utvecklingsmiljön där utvecklingen äger rum. Automatiska acceptanstester är nu på tapeten och blir allt mer uppmärksammat i rapporter och artiklar. Någon självklar standard för automatiska acceptanstester finns dock inte i dagsläget [7]. Den finns en rad verktyg för olika ändamål inom automatiskerad acceptanstestning, några av dem tas upp här och FIT och undersöks närmare. Som stöd för utarbetningen har författaren tillgång till skrivet material, artiklar och böcker, och en grupp utvecklare in ingår i kursen PVG på LTH. Kursen ges obligatoriskt och i varje grupp ingår tio utvecklare. Teamet har tillgång till Coach för Team9 två coacher, äldre teknologer från LTH, som läser en fortsättningskurs av PVG parallellt, där författaren utgör en av coacherna i ett av teamen. I rapporten kommer tillgången till utvecklarna utnyttjas för undersökning hur väl det utvalda verktyget fungerar i praktiken. Detta gör det hela mer intressant än uteslutande skrivet material. Författarens frågeställning inför denna studie var: I vilken omfattning behövs verktyg som stödjer automatisk acceptanstestning inom XP? Från personlig erfarenhet, tror författaren att stöd och verktyg för automatiserade acceptanstester kan vara till stor hjälp och undvika stress och panik nära releaser. De flesta mjukvaror släpps som release när under % av dess funktionalitet täcks av tester [1]. Inom XP är det till stor hjälp att på ett säkert och entydigt sätt försäkra sig om att en story är korrekt, så till vida att kundens funktionella tester går igenom [9]. Som en ledstjärna inom XP, brukar man inte betrakta en story som komplett förän alla tillhörande acceptanstester går igenom [8]. Nya acceptanstester måste skapas i och med varje ny iteration med nya stories för att arbetet skall fortskrida framåt. För att garantera att acceptanstester körs och för att öka produktiviteten kan ett team ta hjälp av verktyg för att automatisera acceptanstester och även skapandet av dessa. Det finns idag en uppsjö verktyg och ramverk som stödjer acceptanstestning. De befinner sig olika långt i mognadsfasen. De verktyg som verkar någorlunda användbara kommer kort beskrivas i artikeln, och det eller de verktyg som verkar mest lämpliga enligt vissa kriterier, se avsnitt 5 för kriterier, kommer studeras närmare i den praktiska studien av PVGteamet. 2. METOD 2.1 Teori I den här delen kommer acceptanstestning att beskrivas utifrån ett mer teoretiskt perspektiv med hänsyn till artiklar och annat befintligt material. 2.2 Studie Studien på PVG-teamet bestod av dels en praktisk iaktagelse av gruppens arbete med det utvalda verktyget och dels helt utan verktyg och automatiserat stöd. De tre första iterationerna, i vårt fall de tre första måndagarna under tre veckor, använde teamet enkla och odefinierade arbetssätt för att accpetanstesta. Mycket av arbetet bestod i att jämföra

2 innehållet mellan textfiler, där det är lätt att göra misstag. Under den fjärde iterationen, infördes det utvalda verktyget i utvecklingsteamet. Utvecklarna hade fått i uppgift att läsa in sig på verktyget och gå igenom en enkel guide om författaren satt ihop rörande delaljer kring exekvering och inläggning av acceptanstester. Det var självklart ett medvetet val att vänta tre iterationer, dels för att kunna jämföra med något i studien och dels för att författaren då fick insikt och kunde lättare välja ut ett passande verktyg med några iterationer i ryggen. Ett par satt tillsammans med författaren under iteration fyra för att överföra de nuvarande acceptanstesterna till det nya ramverket,. Den här processen upplevdes relativt enkel och intuitiv av de två utvecklarna som satt med under processen, mycket tack vare wiki-gränssnitt och det något mekansika upplägg författaren förberett. 3. ACCEPTANSTESTNING I XP För att citera författaren till XP Installed, Ron Jeffries: Successful acceptance tests are, among other things, customerowned and automatic. However, customer-owned does not necessarily mean customer-written. In fact, as Kent Beck points out in Extreme Programming Explained, customers typically can t write functional tests by themselves, which is why an XP team has a dedicated tester: to translate the customers ideas into automatic tests. Han påpekar bland annat att lyckad acceptanstestning är automatisk och att kunden nödvändigtvis alltid är kapabel att skriva sina egna tester, som i vårt fall i PVG-kursen. Ron Jeffries menar att ett XP-team ska ha en dedikerad testare som översätter testerna från kunden till automatiska sådana. Delar av detta togs i beaktelse vid valet var verktyg. Det skulle vara enkelt att editera och lägga in nya tester i verktyget. Acceptanstestning är en benämning på funktionell testning eller black box testning inom mjukvaruutveckling. Benämningen används även inom XP-utveckling där det mer pekar på den slutliga bekräftelsen på att en story är korrekt implementerad, eller rättare sagt att den tänkta funktionaliteten är korrekt hos programvaran. De största möjligheterna vad gäller förbättring i hur mjukvara testas avgörs då acceptanstesterna tas fram [1]. 4. ACCEPTANSTESTNINGSPROCESSEN Acceptanstestningsprocessen inom XP är ganska enkel. Den består av ett mjukvarusystem som ska testas, och en eller flera acceptanstester som ska köras. Ofta är acceptanstesterna exempel på ett förväntat beteende eller utdata från systemet. Systemet körs och det verkiga resultatet jämförs sedan med det förväntade. 5. VERKTYG FÖR AUTOMATISK ACCEP- TANSTESTNING Antalet verktyg som stödjer automatisk acceptanstestning i stort är många, för många för att ta upp i den här artikeln. De mest förekommande är kort beskrivna nedan. Inte alla av dem uppfyller kraven ställda för den praktiska studien. I slutet av den här delen, motiverar författaren valet av ett utav verktygen. Under urvalsprocessen fanns en rad kritierier i åtanke. Listan nedan nämner dessa i grova drag. Även värt att nämna är att för många av verktygen fanns väldigt lite information, både på internet och i publicerad form. Är det lätt att använda för gruppmedlemmarna? Har det stöd kundanpassning och utökningar som krävs? Hur är stödet för Java? Förfarandet kan vara helt automatiserade? Finns det något behov av speciell programvara för att installera? 5.1 FIT Wikis urfader Ward Cunningham utvecklade FIT [16], som är ett ramverk för automatiserade acceptanstester skrivet i Java tillgängligt via öppen källkod. Iden bakom FIT är att enkelt integrera testare, utvecklare och intressenter i testprocessen. FIT ger möjlighet att visa upp testresultat som t ex HTML-sidor, vilket gör det enkelt för icke tekniska personer att förstå testernas utfall och syfte [1]. FIT kan då färga celler i tabeller efter utfallet av testerna, rött symboliserar fel av något slag och grönt att testet gick igenom utan några fel. FIT är i sin tur baserat på JUnit och utökar detta ramverk för stöd för något som heter fixtures. Det finns tre inbyggda grundläggande fixtures som räcker ganska långt vid generell testning. Dessa tre är: RowFixture, ColumnFixture och en ActionFixture. För detaljer kring dessa tre, se avsnitt 6.4. Ytterliggare funktionalitet läggs enkelt till dessa tre fixtures genom arv i Java. FIT kommer vidare användas i den här studien som en del av, se nedan. 5.2 [19] är ett serverbaserat verktyg skrivet i Java med ett wiki-gränssnitt som ger testare och utvecklare möjlighet att skriva tester med en wiki syntax [12]. använder FIT som sin underliggande testmotor. Detta betyder att i stort sett all funktionalitet som finns i FIT är tillgängligt i. Ramverket distribueras i form av ett JAR-arkiv som gör installationen intill obefintlig och plattformsoberoende. Detta möjliggör snabb och smidig uppstart av på vilket system som helst där Java är förinstallerat. använder så kallade fixtures, [intern referens], som står för själva exekveringen av testerna och länkar med artefakten som ska testas. Fixtures ger utvecklaren stor frihet och flexibilitet. 5.3 Selenium Selenium [17] är ett open-source ramverk för testning av webbapplikationer skrivet utvecklat av personer på Thought- Works[11], bl a Jason Huggings [22]. I Selenium ingår en samling verktyg för som stödjer webbaserad automatisk testning på en rad olika plattformar [9], i stort sett alla där det

3 Test cases Wiki pages Standard tools and libs User written applications/code Web server, storage & Wiki FIT Server & Runner Figure 1: overview Fixtures Artefact går att köra en webbläsare. Selenium kan t ex används för att upptäckar browser-inkompatilibitet av den utvecklade produkten i JavaScript och HTML. Selenium kan användas för att återskapa inspelade scenarion och emulera en användares interaktion med en webbsida, med knapptryckningar och inmatning av text[9]. Detta kan vara väldigt användbart i många sammanhang, speciellt vid agil utveckling av produkter för webben där TDD, Test Driven Development, är önskvärt. Eftersom Selenium har sitt fokus på komplicerade webbaserade produkter, svarar det inte mot de krav som är ställda för studien i den här artikeln. 5.4 Test Automation FX Test Automation FX [21] är ett ramverk som stödjer testing av Windows GUI från Visual Studio 5 och Visual Studio 8 [13]. Detta ramverk har sitt fokus på Microsoft Windows med stöd för språk som C, VB.NET etc. Med tanke på den här stora begränsning i användningsområden, utesluts Test Automation FX helt ur den här studien. 5.5 EasyAccept EasyAccept [] är ett verktyg för skrivet i Java för automatisk acceptanstestning bestående av två delar, en skriptmotor och en så kallad Runner. Upplägget är tänkt att underlätta skrivandet och öka uttrycksfullheten av tester [6]. Tester skrivs i ett icke objekt orienterat språk och exekveras efter översättning i Runner. Tanken är god att låta användare skriva tester i ett specifikt språk, nackdelen är att det krävs att det nya skriptspråket lärs in. Bristen på dokumentation och skrivet material om EasyAccept ledde till valet att inte vidare studera verktyget i den här rapporten. 5.6 Anledningar till valet av Valet av motiveras av en rad faktorer. Först och främst verkade det moget och väl använt. Det är baserat på FIT som är det mest välkända verktyget inom acceptanstestning[6]. Sedan är skrivet i Java vilket gör att det är enkelt för personer med goda kunskaper inom Java att använda det, t ex studenter på LTH. Slutligen använder sig av ett wiki gränssnitt mot FIT, vilket författaren från början tyckte lät lockande för sin utspridning och enkelhet. En av kriterierna för urvalsprocessen var just enkelhet och möjligheten att snabbt komma igång med verktyget utan för mycket inläsning. 6. FITNESSE I VÅRT TEAM I den här delen introduceras metodiken kring hur användes i vårt team tillsammans med övriga verktyg och rutiner. Vårt team var det enda teamet under kursens gång som använde ett alternativ till SVN. Det beror på att min par-coach gjorde sin djupstudie inom området distribuerad versionshantering [14] med praktisk fokus på GIT. Eftersom vårt team använde en distribuerad metodik, behövdes vissa saker modifieras och läggas till. 6.1 Kort om GIT GIT [18] är ett distribuerat versionshanteringssystem till motsats mot vanliga oftast centraliserade system som CVS och SVN. Detta betyder att alla utvecklare har sitt eget repositorie lokalt, där av distribuerat. GIT skalar tydligen bra, eftersom det fungerade väl i vårt team som endast bestod av tio utvecklare, dvs fem par som programmerade samtidigt. GIT stödjer en rad finesser som man kan behöva vid versionshantering, så det är inte alls svårt att gå över till GIT från SVN. Genom sin distribuerade arkitektur, behövs ingen central server. Detta kan underlätta installation då teamet inte har tillgång till en server. 6.2 Vår utvecklingsmetodik Vår metodik skiljer sig i den bemärkelse att versionshanteringen är distribuerad och varje team har sitt eget repositorie. Detta är motsatsen till hur det brukar vara i XP, där en central server lagrar den senaste aktuella versionen av programmet som utvecklas. GIT möjliggjorde att vi kunde ha lokala repositorien på varje maskin, där två utvecklare satt och parprogrammerade på en given story. Paren utförde lokala commits, och gjorde detta förhållande vis ofta, jämfört med traditionell versionshantering enligt kursledningens statistik. När ett team tycktes vara klara med en story, granskade min par-coach implementationen och kollade att testerna gick igenom och agerade gatekeeper[15]. Såg allt bra ut och testerna gick igenom, publicerades den nya versionen och övriga par i teamet kunde uppdatera sin kodbas och lösa eventuella merge-konflikter. Detta arbetssätt tvingade delar av ursprungliga upplägg och syfte att modifieras en aning. Vanligtvis har ett XP-team en dedikerad testare som översätter acceptanstesterna från kunden till körbara tester i någon form, se figur 2. Tillvägagångssättet kräver samspel mellan den del av teamet som skriver kod och testaren. Varje gång en story anses klar, måste testaren köra de berörda acceptanstesterna och fatta beslut efter utfallet. Detta arbetssätt kan kan utgöra en flaskhals i utvecklingsarbetet. Ett alternativt sätt är att låta utvecklarna själva köra igenom testerna och fatta beslut efter dessa. Att följa detta arbetssätt, som visas i figur 3, eliminerar behovet av en dedikerad testare och tiden kan då användas mer effektivt. Testarens tid och den tid testaren inte är sysselsatt, kan användas till att producera kod istället. Utvecklarna är nu helt ansvariga för dels testning, som innebär att köra enhetstester (JUnit) kontinuerligt under arbetets gång och till sist köra acceptanstesterna (),

4 Story 2 Story 3... Story 1 SVN Repository Story X root Dedicated tester Figure 2: Centraliserad versionshantering och testning 6.4 Fixtures Två så kallade fixtures behövdes för att få att testa vårt program i projektet. Lite kort kan fixtures beskrivas som det kit som fogar samman tabellerna i med logiken i artefakten [2], programmet som testas i vårt fall. Dessa två fixtures var skrivna i Java och använder FITs färdiga fixtures som bas genom arv, se Appendix A för detaljer. De tre grundläggande fixtures som ingår i FIT och är: RowFixture, ColumnFixture och en ActionFixture. Nedan följer en kort beskrivning av varje, följt av en beskrivning av de två som skrevs specifikt för vårt projekt. Dessa två använder och utökar (extends i Java) ColumnFixture respektive ActionFixture RowFixture RowFixture används för att testa iterativa datatyper som listor, träd och datastrukturer i allmänhet [7]. RowFixture användes inte i vårt projekt, och därför hänvisas läsaren till FITs hemsida [16] för mer information. root Git Repository root Git Repository... root Git Repository ColumnFixture ColumnFixture används då man vill testa ett givet utfall av en operation, tex addition eller division, då givna indata ska resultera i givna utdata [7]. Ett enkelt exempel är en metod som dubblar ett heltal. Given indata respektive utdata kan då vara, indata: 2, utdata: 4. ColumnFixture läs in den givna indatan, förväntade utfallet, exekverar metoden, och jämför utdatan, resultatet, med det som står i kolumnen för utdata. Stämmer dessa går testet igenom, annars inte. Story 1 Story 2 Story X Figure 3: Distribuerad versionshantering och testning och dels för själva programmeringen, som innefattar att skriva testfall och produktionskod. Teamet kan nu arbeta mer fokuserat på att skriva bra kod och slipper de problem som centralisering kan medföra. 6.3 Varför behövde finjusteras Trots att var designat för att användas av ett team eller organisation, behövdes vissa saker modifieras. När det kommer till acceptanstestning, är det meningen de ska avgöra om en story är klar eller ej [5]. Den enklaste lösningen som var aktuell just då när skulle introduceras, var att låta varje par köra sin version av lokalt. är inte i sig självt versionshanterat, utan författaren lät Fit- Nesse ligga i en mapp i vårt repositorie där alla wiki-sidor tillsammans med testfallen lagrades. När en story var klar, publiserades den tillsammans med den tillhörande acceptanstesterna under GITs kontroll. På det här sättet kunde varje par lägga in nya tester, köra sina tester separat från övriga par medan risken för kollisioner och problem var minimal. Nu kunde varje par köra sina versioner av acceptanstesterna parallellt, snabbt och enkelt ActionFixture En ActionFixture tar innehållet i en tabell, en specifik cell, och tolkar detta innehåll som ett kommando som exekveras [16]. ActionFixture används således för att anropa kommandon, dessa kan vara alltifrån navigering i ett GUI till kommandorads program i Linux. Kodexemplet i Appendix A visar hur man utökar ActionFixture genom arv och egen kod i Java SmartFixture StartNr; Namn; #Varv; Totaltid; 1; Bengt Bsson; ; ; ; 2; Anders Asson; ; ; ; StartNr; Namn; #Varv; Totaltid; 1; Bengt Bsson; ; ; ; 2; Anders Asson; ; ; ; Match? Figure 4: SmartFixture bestämmer om två filers innehåll matchar Den så kallade SmartFixture användes för att jämföra innehållet mellan två filer, se figur 4, filen från kunden och filen som genererades från vårt program. SmartFixture läste helt enkelt in två filer från filsystemet och jämförde innehållet med Javas inbyggda compareto-metod. Nackdelen med compareto är att den inte är förlåtande vad gäller teckenkodning, något man måste vara medveten om. Fixturen

5 Table 1: SmartFixture exempeltabell i wikin Expected Result Match? expected.txt result.txt TRUE jämförde filerna tecken för tecken, vilket fungerade tillfredställande, när teckenkodningen var lika. Tabell 1 visar hur det kunde se ut i vår wiki. Expected anger den indatafil som vi fick från kunden med förväntat resultat, Result anger utdatan från vårt program Sorter och Match? anger som de två filerna matchar varandra enligt metoden som beskrivs ovan CommandLineFixture The CommandLineFixture was used to execute the Sorter program with given parameters for the acceptance test to produce the output file. The output file was then used as an argument together with the expected result to SmartFixture to compare the contents of the files. The CommandLineFixture executes the given program that it gets as an argument from the wiki page in. Ytterliggare en fixture som döptes till CommandLineFixture användes för att exekvera vårt huvudprogram, Sorter. Sorter var namnet på den produkt vi skulle ta fram åt vår kund för sortering av tidsdata. Sorter gavs parametrar som var specificerade för varje acceptanstest via konfigurationsfiler. CommandLineFixture exekverade Sorter-programmet med en given konfigurationsfil som då genererade en utdatafil. Utdatafilen jämfördes sedan i SmartFixture med en förväntad utdatafil. CommandLineFixture exekverar det program som den får som inargument från en wiki sida i Fit- Nesse under det aktuella systemet. Do you prefer automated acceptance testing over manual? 1 1 % Figure 6: Enkätfråga nummer 1 Do you think has helped our work? 1 9 % % Wiki page Test execution FIT Fixture Sorter program result.txt Figure 7: Enkätfråga nummer 2 Was it easier to remember to use the acceptance tests after the introduction of? Figure 5: CommandLineFixture exekverar artifakten, Sorter Figur 5 visar hur en wikisida inuti exekverar Sorter genom CommandLineFixture via FIT och som slutligen genererar en utdatafil result.txt. 7 5 % 7. RESULTAT I den här delen presenteras resultaten från den enkätundersökning som gjordes på utvecklarna i PVG-teamet under sista långlabben. Alla tio deltagarna var med och enskilt besvarade de frågor som lades ut på en wiki sida, se Appendix B. 7.1 Sammanfattning av enkät 3 1 % Figure 8: Enkätfråga nummer 3

6 Did you experience GUI as intuitive? Did you test more often with? 5 5 % 5 % 7 5 % % Figure 11: Enkätfråga nummer 6 Figure 9: Enkätfråga nummer 4 Was the guide on sufficient to get going? 7 7 % % Would you be able to add new tests to the wiki? % 3 % Figure 1: Enkätfråga nummer 5 Figure 12: Enkätfråga nummer 7 Undersökningen visar, se figur 6, att alla utvecklarna i teamet föredrog automatiserade acceptanstester med framför manuella tester med JUnit and Eclipse. Det är också väldigt positivt att nästan alla tyckte det var enklare att komma ihåg acceptanstesta med. Den guide som skrevs för att utvecklarna skulle läsa in sig på behöver förbättras, se figur 12. I enkäten fanns även utrymme för egna reflektioner och fria formuleringar. Där kunde det utläsas att bättra koppling till Definition of Done behövs för att få att fungera bättre. Enklast görs detta genom att lägga till de steg som behövs i en checklista, t ex att ska exekveras och verifieras. Vissa utvecklare menade på att även mer automatisering av acceptanstesterna, då speciellt skapandet av dem, vore önskvärt i kommande projekt. Därpå kunde wiki-gränssnitt varit lite enklare och många saker användes aldrig, vilket bara skapade onödig förvirring.

7 Was easy to gain insight into? % 3 % Figure 13: Enkätfråga nummer 8 Det är dock intressant och roligt att notera att nästan alla kan tänkta sig överväga användandet av i kommande XP-projekt. Dessutom fick ett sammanvägt betyg ur ett XP perspektiv på hela 4.1 av 5 möjliga, vilket motsvarar över % i betyg av utvecklarna, se figur Fördelar med Fördelen med är att den låter dig arbeta med acceptanstester i flera nivåer, dvs det är enkelt för kunden att vid behov använda wiki sidorna och modifiera eller köra testerna själv. En mer tekniskt kunnig person, t ex en utvecklare, kan implementera fixtures och skriva domänspecifik kod som stödjer de tester som behövs. och FIT erbjuder stor valfrihet och flexibilitet, men till ett pris. Olika fixtures låter dig testa vad du kan tänkta dig testa, räcker inte de medföljande till, är det någorlunda smidigt att skriva egna. När väl dina fixtures och behoven är täckta, är det bara att köra igång och testa. Would you consider using in a future project? 1 1% Figure 14: Enkätfråga nummer 9 Overall rating of from an XP perspective? 7 7% % 1 % Figure 15: Enkätfråga nummer 1

8 7.3 Nackdelar med Det finns även några nackdelar med. Den största är brisen på tydliga exempel i dokumentationen och det är inte helt intuitivt hur man kommer igång med att skriva egna fixtures för FIT och. Att skriva egna fixtures kräver en del Java kunskaper och en portion tålamod. Eftersom använder ett wiki-gränssnitt till de underliggande testfallen, krävs det kunskaper i den valda wiki kodningen för att kunna editera testfallen. Att editera wiki sidor kan låta enkelt, men blir en aning bökigt i längden då nya testfall skapas, borde finnas stöd för färdiga och egna mallar så man enkelt skapar ett nytt testfall utifrån hur man brukar lägga upp den strukturen. 8. SLUTSATSER Det distribuerade förhållningssätt vårt team använt sig utav har visat sig vara lyckosamt inom stora delar av Extreme Programming. När var någorlulnda integrerat i arbetet, var det enkelt att använda och levererade snabbt testresultaten tydligt och överskådligt. Varje par i teamet hade möjlighet att använda sin egna version av wiki, dvs ett par kunde testa sin egna story separat från vår huvudbranch och samtidigt modifiera och testfallen i wiki sidan utan att störa andras arbete. Detta upplägg var uppskattat av utvecklarna, som nästan omedelbart började kika på Fit- Nesse för att testa sina stories. Det finns fortfarande utrymme för förbättringar hos Fit- Nesse, och man kan ifrågasätta om ett wiki-gränssnitt är det ultimata, här finns en hel del att göra. Författaren tycker att det genomsnittliga betyg utvecklarna gav verktyget på över % är välidigt bra. Utan tvekan är användbart och på rätt väg i sin utveckling, men fortfarande finns mycket att göra för att reducera komplexiteten som är involverad med att skapa nya tester och köra dem. 9. REFERENCES [1] J. L. Fernández. Acceptance testing of object oriented systems. In Ada-Europe 99: Proceedings of the 1999 Ada-Europe International Conference on Reliable Software Technologies, pages , London, UK, Springer-Verlag. [2] B. Haugset and G. K. Hanssen. Automated acceptance testing: A literature review and an industrial case study. In AGILE 8: Proceedings of the Agile 8, pages 27 38, Washington, DC, USA, 8. IEEE Computer Society. [3] R. C. Martin. Professionalism and test-driven development. IEEE Softw., 24(3):32 36, 7. [4] S. S. Park and F. Maurer. The benefits and challenges of executable acceptance testing. In APOS 8: Proceedings of the 8 international workshop on Scrutinizing agile practices or shoot-out at the agile corral, pages 19 22, New York, NY, USA, 8. ACM. [5] K. Read, G. Melnik, and F. Maurer. Student experiences with executable acceptance testing. In ADC 5: Proceedings of the Agile Development Conference, pages , Washington, DC, USA, 5. IEEE Computer Society. [6] J. P. Sauvé, O. L. Abath Neto, and W. Cirne. Easyaccept: a tool to easily create, run and drive development with automated acceptance tests. In AST 6: Proceedings of the 6 international workshop on Automation of software test, pages , New York, NY, USA, 6. ACM. [7] I. C. Society. Automated acceptance testing using fit. In HICSS 9: Proceedings of the 42nd Hawaii International Conference on System Sciences, pages 1 8, Washington, DC, USA, 9. IEEE Computer Society. [8] D. Talby, O. Nakar, N. Shmueli, E. Margolin, and A. Keren. A process-complete automatic acceptance testing framework. In SWSTE 5: Proceedings of the IEEE International Conference on Software - Science, Technology & Engineering, pages , Washington, DC, USA, 5. IEEE Computer Society. [9] X. Wang and P. Xu. Build an auto testing framework based on selenium and fitnesse. In ITCS 9: Proceedings of the 9 International Conference on Information Technology and Computer Science, pages , Washington, DC, USA, 9. IEEE Computer Society. [1] R. Mugride and E. Tempero. Retrofitting and Acceptance Test Framework for Clarity. In ADC 3: Proceedings of the Agile Development Conference. [11] A. Holmes and M. Kellogg. Automating Functional Tests Using Selenium. In AGILE 6: Proceedings of AGILE 6 Conference. [12] F. Fannizzo, G. Marcionetti and P. Moser. Evolution of the Tools and Practices of a Large Distributed Agile Team. In AGILE 8: Proceedings of the Agile Conference. [13] E. Kim, J. Na and S. Ryoo. Implementing an Effective Test Automation Framework. In 33rd Annual IEEE International Software and Application Conference 9: Proceedings of the Conference. [14] D. Arve. Distributed version control in agile teams. In Djupstudier 1. [15] C. Hedin and S. Birgersson. Introducing the Agile Requirements Abstraction Model - Requirements Engineering in a Scrum Environment. In page 69. [16] FIT, [17] Selenium, [18] GIT, [19], [] EasyAccept, [21] Test Automation FX, [22] Selenium Wikipedia,

9 APPENDIX Appendix A - Källkodsutdrag för fixtures public class SmartFixture extends ColumnFixture { public String input ; public String output ; public boolean match () {... i f ( correct. compareto( our ) == ) return true ; return f a l s e ; } } public class CommandLineFixture extends ActionFixture {... } private Process execute ( String command) throws IOException { i f ( isverbose ) System. out. println ( command = + command ) ; Process p = Runtime. getruntime ( ). exec (command ) ; return p ; } Appendix B - Frågor till enkätundersökning Är automatiska acceptanstester bättre än manuella? (Ja / Nej) Tycker ni underlättat arbetet? (Ja / Nej) Kände ni att ni testade oftare med än vid manuell testning? (Ja / Nej) Var det lättare att komma ihåg att acceptanstesta efter införandet av? (Ja / Nej) Skulle ni kunna lägga till egna tester i wikin? (Ja / Nej) Om NEJ: Varför: (Fri formulering) Kändes användargränssnitt intuitivt? (Ja / Nej) Var guiden på projekt-wikin tillräckligt utförlig? (Ja / Nej) Var det lätt att sätta sig in i? (Ja / Nej) Är något ni kan tänka er använda i framtida projekt? (Ja / Nej) Vad får för betyg av er ur ett XP perspektiv? ( till 5) Vad kan förbättras? (Fri formulering)