Implementationen av testfall

Vilket av de undersökta testverktygen uppfyller främst de uppsatta utvärderingskriterierna och hur väl fungerar det att använda i praktiken vid utförande av regressionstester?

Som tidigare nämnt var Ranorex det testverktyg som uppfyllde störst antal av de sammanställda kriterierna och därför användes det verktyget till att implementera fyra stycken testfall mot ett webbaserat system. Fyra grundläggande funktioner för hantering av artiklar valdes ut för att de ansågs vara relevanta att prioritera och bör utföras under ett tidigt skede av testprocessen (Elbaum, Malishevsky & Rothermel, 2002).

Inspelningsfunktionen som Ranorex tillhandahåller är enkel och förståelig vid användning och att redigera de testfall som skapats är också på relativ simpel nivå. Exekvering av skapade tester kan utföras utan att användaren behöver ingripa manuellt men den dator som utför testerna kommer inte att kunna brukas till annat under tiden. Testfallen som skapas kan återanvändas under

kommande tester och de behöver inte återskapas eller redigeras för varje gång – under förutsättning att ingen layout eller uppbyggnad förändrats på webbapplikationen.

Exekveringen fortsätter kontinuerligt så länge testerna blir godkända och genomförda, däremot kan hinder uppstå om ett testfall delvis blivit genomförd men sedan misslyckas. Testkörningen kommer då att fortsätta från det utgångsläge där den senaste testen avbröts – vilket kanske inte alls passar i ihop med de följande testerna som även då kommer att anses vara misslyckade då de inte hittade rätt startläge för att kunna utföras. Denna del kräver att användarna tänker till när tester skapas och har i åtanke vad som bör hända om testfallet misslyckas och hur testerna ska kunna gå vidare från rätt startläge.

6 Slutsatser

Detta avsnitt berör de slutsatser som dragits rörande arbetets syfte och frågeställningar.

Arbetets syfte var att ta fram utvärderingskriterier för att välja ett testverktyg som går att tillämpa vid genomförandet av regressionstester av webbaserade systems GUI. Dessa kriterier utvärderades sedan genom att analysera två testverktyg mot dem och välja ut det verktyg som uppfyllde flest antal kriterier för att sedan implementera ett antal testfall mot ett webbaserat system. Arbetet utfördes

för att öka kunskap inom området och för att kunna lägga fram ett förslag på ett underlag på utvärderingskriterier som går att bruka vid val av testverktyg som fokuserar på regressionstester av GUI.

6.1 Utvärderingskriterier

De utvärderingskriterier som framtogs under detta arbete från de egenskaper och kännetecken tillhörande verksamheter vars fokus är att utveckla webbapplikationer är indelade i olika kategorier beroende på vilken funktion de uppfyller.

• Vilka utvärderingskriterier för val av testverktyg kan utvinnas från egenskaper och

kännetecken tillhörande verksamheter som utvecklar webbapplikationer?

Inom den första kategorien, testplanering och översikt, framtogs tre kriterier:

• Testverktyget stödjer miljöerna… • Testverktyget stödjer agila metoder.

• Testverktyget kan avgöra hur stor del av applikationens kod som testerna täcker.

Dessa utvärderingskriterier bidrar till valet av testverktyg genom att de två första kriterierna kollar om verktyget stödjer den metod och de miljöer som verksamheten använder. Att veta om ett verktyg har möjligheten att stödja sådant som redan är aktivt och används inom verksamheten kan vara en viktig del under beslutet. Stödjer inte testverktyget något av detta kommer förändringar att behöva ske inom verksamheten och sådant bör tas i beaktande om det blir aktuellt.

Det tredje utvärderingskriteriet underlättar om verksamheten är intresserade av att täcka alla delar ur den webbapplikation som ska testas med automatiserade tester. Kan testverktyget jämföra de tester som skapats mot vilka delar ur koden som de täcker så blir det enklare att upptäcka sådant som kan ha glömts bort eller missats.

Den andra kategorin, analys och design, innehåller ett kriterium:

• Inspelningar av tidigare testfall kan återupptas vid senare skede och utökas.

Detta kriterium kontrollerar om testfall som spelats in vid ett tidigare skede enkelt kan utökas genom att återuppta inspelningen vid ett senare skede. Det kan hjälpa verksamheten att enkelt utöka och förändra de testfall som de skapat utan att de behöver redigeras manuellt eller spelas in helt från början igen – vilket bidrar till hur enkelt det är att underhålla skapade testfall och tester.

• Tester kan köras mot testdata.

• Starttid för utvalda testexekveringar kan anges. • Testfall kan skapas manuellt.

• Inspelning av tester kan pausas och sedan återupptas inom samma session.

Utvärderingskriterierna inom denna kategori beskriver främst sådant som är önskvärt av ett testverktyg och som underlättar när det ska användas. Att tester kan köras mot testdata och att skapa testfall manuellt tillåter att mer målinriktade tester kan utformas och det ger även

verksamheten större frihet att anpassa testerna som de själva önskar. Starttid och paus av inspelning är två funktioner som underlättar för verksamheten när de ska använda verktyget.

Fjärde kategorin, testexekvering samt fånga och jämföra resultat, innehåller tio utvärderingskriterier:

• Testverktyget kan hantera tester som berör hela eller delar av ett system. • Prestandatest kan utföras.

• Inmatningstester kan utföras. • Dumb monkey-tester kan utföras. • Säkerhetstester kan utföras.

• Tester för att upptäcka memory leak kan utföras. • Antalet iterationer för ett testfall kan anges. • Testfallens uppspelningshastighet kan anges. • Testverktyget har en bildigenkännings-funktion.

• Testverktyget kan spela upp tester på flera olika webbläsare samtidigt.

För att kunna utvärdera hur väl applikationen fungerar i praktiken är det även viktigt att testa andra saker än att bara kontrollera att implementerade funktioner fungerar som förväntat. En

webbapplikation blir inte automatiskt bra för att dess funktioner fungerar som förväntat, utan det finns andra aspekter som inverkar på hur bra kvalité en webbapplikation egentligen har. Därför kan det vara relevant att ha möjligheten att utföra prestandatester, inmatningstester, dumb monkey- tester, säkerhetstester och tester för att upptäcka eventuell memory leak som kan uppstå.

Genomförandet av testerna bör fungera smidigt och det är önskvärt om de är så tidseffektiva som möjligt. Kan ett testverktyg utföra tester på flera olika webbläsare samtidigt kommer det att spara mycket mer tid än om testerna ska utföras på en webbläsare åt gången. Testerna kan fungera felfritt på en webbläsare – men det är samtidigt möjligt att de inte alls fungerar på en annan webbläsare vilket gör det viktigt att tester utförs på ett stort antal webbläsare. Något som även kan vara intressant under testningen är att kunna hantera tester som antingen berör hela eller delar av ett

system för att på så sätt enkelt kunna avgöra vad som är relevant att köra under den aktuella testkörningen istället för att köra genom alla existerande tester för varje omgång.

Övriga funktioner som kan bidra till att enklare kunna skapa anpassade tester är om verktyget stödjer inställningar för hur många gånger ett testfall ska spelas upp, vilken uppspelningshastighet det har och om testverktyget innehåller en funktion som kan känna igen bilder.

Den femte kategorin, testrapportering, innehåller ett kriterium:

• Statistik för hur stor del av testningen som utförts finns tillgänglig.

För att enkelt kunna avgöra hur stor del av testerna som utfördes och vad som är kvar är statistik för testerna en funktion som bidrar till enklare hantering av testkörningarna. Det är svårt att avgöra testers faktiska status om man inte vet om de blivit utförda eller inte under testexekveringen.

Den sjätte och sista kategorin, stöd för buggar samt underhåll, innehåller ett kriterium:

• Funktion för att enkelt kunna manövrera mellan skapade testfall finns.

Stora projekt kan innebära att stora mängder av testfall skapas. För att enkelt hitta och kunna underhålla dessa testfall kan en funktion som tillåter användaren att enkelt manövrera mellan dem vara till stor nytta. Bland flera hundratals skapade testfall är det inte alltid det lättaste att hitta ett specifikt testfall om man inte känner till dess placering.

Flera av de utvärderingskriterier som blivit framtagna är inte kritiska för att testverktyget ska gå att använda, utan de är snarare sådana som kan vara bra att ha. De kan underlätta vid skapandet och exekveringar av tester för att göra hela processen så smidig och tidseffektiv som möjligt – vilket är en av anledningarna till att manuell testning byts ut mot automatiserad testning från första början. Innehåller inte testverktyget sådana funktioner som bidrar till enkelt användande kan det istället vara mer komplicerad och tidskrävande att använda verktyget än att utföra testerna manuellt. Dessa utvärderingskriterier är nödvändiga för att kontrollera om de testverktyg som undersöks kan tillföra något till testprocessen och om de gör det möjligt för verksamheten att utveckla sin testprocess samtidigt som den även förenklas.

Den lösning som tagits fram i detta arbete är inte enbart begränsad till den verksamhet som

testverktygen användes hos. De kriterier som definierat och tagits ut går även att använda för andra verksamheter och kan ses som riktlinjer och stöd då ett testverktyg ska väljas. Kriterierna har även generaliserats och fler aspekter än de som blivit nämnda under intervjuerna har tagits fram, som exempel vilka webbläsare testverktyget har stöd för att utföra tester i.

Vissa kriterier som berör exempelvis vilka miljöer som används kan behöva förändras för att bli bättre anpassade till verksamheter som arbetar på ett annorlunda sätt. Dock går de flesta av

kriterierna att användas precis som de är just nu då de bara kan ha värdena uppfyllt och inte uppfyllt. De delar som inte är relevanta för andra verksamheter går enkelt att bortse från, exempelvis om de använder annorlunda miljöer under deras utvecklingsprocess går dessa enkelt att byta ut mot de miljöer den aktuella verksamheten är intresserade av – eller om verksamheten är öppen för förändringar och byten av verktyg.

6.2 Val av verktyg

Under arbetets gång har det framkommit att båda de undersöka testverktygen Ranorex och Sencha Test har olika styrkor och svagheter.

• Vilket av de undersökta testverktygen uppfyller främst de uppsatta utvärderingskriterierna

och hur väl fungerar det att använda i praktiken vid utförande av regressionstester?

Ranorex var det verktyg som uppfyllde flest antal kriterier och var därför det testverktyg som valdes ut till att testa ytterligare i praktiken.

Slutsatserna som tagits kring detta arbete är att båda testverktygen har framhävande styrkor och svagheter. Det testverktyg som uppfyller flest antal kriterier behöver inte vara det som är det mest lämpliga – istället kan det vara relevant att se på vilka kriterier som är uppfyllda och vilket verktyg som uppfyller de utvärderingskriterier som väger tyngst. Ranorex uppfyllde flest antal

utvärderingskriterier men detta testverktyg har samtidigt svagheter där Sencha Test istället uppvisar styrkor och även vise versa.

Slutsatsen för detta arbete är att bägge testverktygen fungerar väl vid användande i praktiken, men att valet som görs bör vara beroende på vilka kriterier som väger tyngst och anses vara viktiga – men även att det är relevant att se på integrerade testverktyg som en helhet för att kunna utnyttja de funktioner de tillsammans erbjuder fullt ut. Ett enda testverktyg kommer inte att uppfylla exakt alla önskemål och krav som ställs på det för inget testverktyg är specialanpassat på alla sätt för just den enda verksamheten som behöver det. Istället är det relevant att se på verktyg som kan integreras och tillsammans arbeta mot ett gemensamt mål. Detta kan liknas med de verktyg som används när hantverkare tillverkar en produkt. De har flera olika verktyg som hjälper till under processen, exempelvis en såg och en hammare, båda dessa verktyg har olika egenskaper och funktioner – men de används tillsammans under samma projekt för att tillsammans nå ett mål. Endast ett av dessa verktyg kan inte utföra allt som behöver göras och ensam nå målet, en hammare kan inte såga av en

bräda. På samma sätt kan inte testverktyg ensamma utföra alla funktioner, men tillsammans kan de utföra många fler funktioner - vilket är en anledning till att integration av testverktyg är relevant att ha i åtanke.

Alla deras sammanlagda funktioner kommer gå att nyttja vilket ökar antalet uppfyllda kriterier – därför har slutsatsen att metoder som enbart kollar på ett verktyg inte håller i längden. Istället måste det finnas i åtanke att flera olika verktyg bör finnas med i undersökningen som ett och samma objekt, en mängd verktyg som arbetar tillsammans.

De framtagna utvärderingskriterierna går att kombinera med sådana som sammanställts under tidigare forskningar. Utvärderingskriterierna i detta arbete är inte framtagna för att ersätta tidigare kriterier, utan de är tänkta att fungera som komplement för verksamheter som utvecklar

webbaserade system och som vill hitta testverktyg som har funktioner som passar deras behov.

6.3 Arbetets framtida relevans

Detta arbete kommer även att fungera att använda som underlag flera år framåt i tiden. Alla de kriterier som tagits fram är inte uppfyllda då det inte finns testverktyg med sådana implementerade funktioner i dagsläget. Dessa kriterier kommer att vara relevanta längre fram i tiden då det är sådana funktioner som kan underlätta vid skapandet och utförandet av tester. Människor strävar efter att förbättra och hitta nya lösningar på problem som kan bidra till en enklare användning av en produkt, vilket även innebär att sådant som i dagsläget är manuellt kan i framtiden istället bli automatiskt. Då kommer de framtagna utvärderingskriterierna att bli mer aktuella och eventuellt uppfyllda, just för att människor strävar efter förbättring, förenkling och nya lösningar som gör att olika uppgifter kan lösas på ett så smidigt sätt som möjligt.

6.4 Metoddiskussion

Till detta arbete valdes en kvalitativ metod för att den ansågs kunna bidra till ett bättre resultat än vad en kvantitativ metod skulle åstadkomma. Utvärderingskriterierna är nu begränsade till sådana som känts relevanta och är brukbara för att undersöka testverktyg inom detta område. En kvalitativ metod går mer på djupet och intresserad sig för sammanhang och strukturer (Holme & Krohn Solvang, 1997). En kvantitativ metod kunde istället ha tagit fram betydligt fler utvärderingskriterier, men istället skulle deras relevans inte vara lika betydande för det mål som de ska uppfylla.

För att kunna få ett bättre resultat hade det varit relevant att intervjua fler personer från andra verksamheter inom samma område för att kunna skapa en bredare bild. Då inga verksamheter

fungerar likadant hade de kunnat ge annorlunda input som kunde bidra till fler och annorlunda utvärderingskriterier. Istället för enbart intervjuer kunde de kombinerats med enkäter. På så sätt skulle en djupare inblick kunnat fås samtidigt som fler aspekter kunnat samlas in via enkätsvaren.

Resultatet hade även kunnat bli bättre och tydligare om fler än ett testverktyg hade testats i praktiken för att kontrollera att utvärderingskriterierna är relevanta och fungerar som tänkt. Det hade bidragit med en bredare bild samt fler aspekter som hade styrkt de framtagna kriterierna och påvisat att de är viktiga att ha i åtanke vid val av testverktyg.

7 Referenser

Amannejad, Y., Garousi, V., Irving, R. & Sahaf, Z. (2014) A Search-based Approach for Cost-Effective Software Test Automation Decision Support and an Industrial Case Study.

Base36 (2013). Automated vs. Manual Testing: The Pros and Cons of Each. Hämtad 2017-02-25, från: http://www.base36.com/2013/03/automated-vs-manual-testing-the-pros-and-cons-of-each/ Behkamal, B., Kahani, M. & Akbari, M. K. (2009) Customizing ISO 9126 quality model for evaluation of B2B applications.

Börjesson, E. & Feldt, R. (2012) Automated System Testing using Visual GUI Testing Tools: A Comparative Study in Industry.

Carvallo, J. P. & Franch, X. (2006) Extending the ISO/IEC 9126-1 Quality Model with Non-Technical Factors for COTS Components Selections.

Elbaum, S., Malishevsky, A. G. & Rothermel, G. (2002) Test Case Prioritization: A Family of Empirical Studies.

Eriksson, U. (2008) Test och kvalitetssäkring av IT-system. Lund: Studentlitteratur.

Grindal, M., Offutt, J. & Mellin, J. (2006) On the Testing Maturity of Software Producing Organizations.

Hallnemo, M. (2013) Processen att välja ett verktyg för automatiserad GUI-testning: En fallstudie. (Kandidatuppsats) Skövde: Institutionen för kommunikation och information, Högskolan i Skövde Tillgänglig: http://his.diva-portal.org/smash/record.jsf?pid=diva2%3A630602&dswid=-4768

Hass, A. M. J. (2008) Guide to Advanced Software Testing. Noorwood: Artech House.

Heitlager, I., Kuipers, T. & Visser, J. (2007) A Practical Model for Measuring Maintainability.

Holme, I. M. & Krohn Solvang, B. (1997) Forskningsmetodik. Lund: Studentlitteratur.

Illes, T., Herrmann, A., Paech, B. & Rückert, J. (2005) Criteria for Software Testing Tool Evaluation – A Task for Oriented View.

Konsultbolag1 (2011) Att lyckas med Testautomatisering. Hämtad 2017-03-03, från: https://konsultbolag1.se/bloggen/att-lyckas-med-testautomatisering

Lewis, W. E. (2005) Software Testing and Continuous Quality Improvement. Boca Raton: Auerbach Publications.

Memon, A. M. (2002) GUI Testing: Pitfalls and Process.

Memon, A. M. (2008) Automatically Repairing Event Sequence-Based GUI Test Suites for Regression Testing.

Onoma, A. K., Tsai, W-K., Poonawala, M. H. & Suganuma, H. (1998) Regression Testing in an Industrial Environment.

Poston, R. M. & Sexton, M. P. (1992) Evaluating and Selecting Testing Tools.

Randhawa, R. & Pandey, L. (2006) Automated Regression Testing Framework using Keyword Driven Approach.

Rothermel, G., Untch, R. H., Chu, C. & Harrold, M. J. (1999) Test Case Prioritization: An Empirical Study.

Software Testing Help (2016) Automated Testing – How to Choose the Best Automation Testing Tool. Hämtad 2017-03-02, från:

http://www.softwaretestinghelp.com/choosing-automation-tool-for-your-organization/ Tiitinen, M. (2013) Key Factors for Selecting Software Testing Tools.

8 Bilagor

8.1 Intervjufrågor

Verksamhet

1) Varför vill ni införa automatiserade tester?

2) Hur arbetas testning med i dagsläget, vem har ansvaret för att utföra den? 3) Hur mycket tid läggs på testningen?

4) Av den testning som genomförs nu, hur stor del av den är återkommande? 5) Dokumenteras de tester som genomförs nu? Om ja; hur?

6) Vad förväntas testverktyget kunna bidra med? 7) Hur ser utvecklingsprocessen ut i dagsläget? 8) Vilka miljöer används under utvecklingsprocessen?

Testverktyg

1) Vilka typer av tester bör verktyget ha stöd för att utföra?

2) Vilka funktioner och egenskaper vill ni att testverktyget ska kunna bidra med? 3) Ska testverktyget kunna samarbeta med andra verktyg? Om ja; vilka?

4) Vilka metoder bör kunna användas för att skapa testfall? 5) Hur bör skapade testfall kunna hanteras?