<p>När dagens datorsystem utvecklas ökar i de flesta fall också dess komplexitet under utvecklingens gång. Detta för med sig negativa konsekvenser i form av svårare testning och felsökning av systemen. Denna uppsats har för avsikt att förklara vilka fel som kan uppstå och varför. Även lösningar i form av modifieringar av system kommer att tas upp.</p><p>Beställaren av undersökningen, Saab, ser möjligheter i att på ett enkelt sätt återskapa fel i deras datorsystem på Gripen. Detta skulle kunna minska kostnaderna för felsökning drastiskt. Då mycket tid ägnas åt verifiering av ny programvara för datorsystemet blir detta också en stor kostnad i utvecklingsarbetet. Därför är det också ett önskemål att undersöka huruvida regressionstest av nya programvaror skulle kunna automatiseras. </p><p>Till en början studerades artiklar inom området och marknaden avsöktes efter färdiga verktyg. Efter en sammanställning av teorin bakom problemen så kunde en analys av det befintliga datorsystemet påbörjas, vilka problem som kunde uppstå och ifall det var möjligt att lösa dessa undersöktes med hjälp av systemets dokumentation. Vissa problem uppdagades där en del kunde avhjälpas med ett genomtänkt verktyg. Vissa problem var dock inte möjligt att deterministiskt visa lösbara, vilket leder till att målet om ett fullständigt regressionstest troligen blir svårt att genomföra. Däremot så kommer andra sorters tester för att testa robustheten i systemet att vara genomförbara. Framförallt så kommer det finnas ett underlag för framtida system där man redan från början kan ta hänsyn till problemen.</p><p>De på marknaden förekommande verktyg som har analyserats har alla visat sig ha funktioner som är användbara, men inget av verktygen kan ensamt hantera de önskningar som finns.</p>

När dagens datorsystem utvecklas ökar i de flesta fall också dess komplexitet under utvecklingens gång. Detta för med sig negativa konsekvenser i form av svårare testning och felsökning av systemen. Denna uppsats har för avsikt att förklara vilka fel som kan uppstå och varför. Även lösningar i form av modifieringar av system kommer att tas upp. Beställaren av undersökningen, Saab, ser möjligheter i att på ett enkelt sätt återskapa fel i deras datorsystem på Gripen. Detta skulle kunna minska kostnaderna för felsökning drastiskt. Då mycket tid ägnas åt verifiering av ny programvara för datorsystemet blir detta också en stor kostnad i utvecklingsarbetet. Därför är det också ett önskemål att undersöka huruvida regressionstest av nya programvaror skulle kunna automatiseras. Till en början studerades artiklar inom området och marknaden avsöktes efter färdiga verktyg. Efter en sammanställning av teorin bakom problemen så kunde en analys av det befintliga datorsystemet påbörjas, vilka problem som kunde uppstå och ifall det var möjligt att lösa dessa undersöktes med hjälp av systemets dokumentation. Vissa problem uppdagades där en del kunde avhjälpas med ett genomtänkt verktyg. Vissa problem var dock inte möjligt att deterministiskt visa lösbara, vilket leder till att målet om ett fullständigt regressionstest troligen blir svårt att genomföra. Däremot så kommer andra sorters tester för att testa robustheten i systemet att vara genomförbara. Framförallt så kommer det finnas ett underlag för framtida system där man redan från början kan ta hänsyn till problemen. De på marknaden förekommande verktyg som har analyserats har alla visat sig ha funktioner som är användbara, men inget av verktygen kan ensamt hantera de önskningar som finns.

Regressionstester är en viktig del under ett utvecklingsprojekts gång. De används för att kontrollera att nya versioner av en befintlig programvara fungerar som förväntat och att inga plötsliga fel har uppstått. Syftet med detta arbete har varit att ta fram utvärderingskriterier för val av ett testverktyg som ska fungera att använda vid regressionstester av webbaserade systems grafiska användarsnitt. Arbetet utfördes genom att använda en kvalitativ metod där litteratur och intervjuer användes som stöd för utformandet av utvärderingskriterierna. De två testverktygen som analyserades i detta arbete var Ranorex och Sencha Test. Analys av resultatet av arbetet påvisar att enbart välja ett testverktyg kommer inte att uppfylla alla de önskemål och krav som finns, utan att det är relevant att kolla på integrerade verktyg som en helhet för att kunna få ut det maximala av testautomatiseringen. Att välja det verktyg som uppfyller flest kriterier är inte heller alltid det lämpligaste, utan de utvärderingskriterier som väger tyngst bör vara i fokus när ett val ska göras. Alla testverktyg har sina egna styrkor och svagheter, valet är beroende på vad som anses vara viktigast i sammanhanget.

Denna studie undersöker tidsvinsterna med en investeringen av automatiserade regressionstester i förhållande till manuellt genomförande. Syftet med detta är att skapa ett beslutsunderlag av ROI och break-even beräkningar med avsikten att minska osäkerheten ifall investeringen kommer resultera i en tidsvinst under systemets livslängd samt hur stora dessa vinster kan bli. För att undersöka detta har automatiska regressionstester utvecklats, där en mätning av tidsåtgången för detta användes som den investerade tiden. De automatiska testernas tid för genomförandet av studiens testfall jämfördes med den manuella motsvarigheten. Detta har tillsammans med empiriskt material från intervjuer stått som grund för ROI och break-even beräkningar gällande investeringen av automatiska regressionstester. Det empiriska materialet bidrog till beräkningarna med parametrarna testfrekvens, testmängd och livslängd. Till skillnad från tidigare forskning genomför studien beräkningar med flera testfrekvenser, vilket resulterade i att även vid en relativt låg testfrekvens har automatiska regressionstester goda förutsättningar för ett positivt ROI. Vid en medel till hög testfrekvens kunde break-even punkten uppnås inom ett år med möjligheter för stora tidsvinster. Det empiriska materialet har även påvisat att uppstartsfasen, systemtypen, testfallens komplexitet och återanvändning är faktorer som kan påverka tidsvinsterna. / This study examines the time savings of an investment in automated regression tests relative to a manual approach. The purpose of this is to produce an underlay for decision making consisting of ROI and break-even calculations which has the intention of reducing uncertainty in case the investment will result in time savings within the systems life span as well as how big these savings can become. To examine this, automated regression tests have been developed where time spent was measured to be used as the invested time. The time it took for the automated tests to execute the studies test cases were compared with the manual counterpart. This has, together with the empirical material from the interviews, formed the basis for ROI and break-even calculations regarding the investment of automated regression tests. The empirical material contributed to the calculations with parameters for test frequency, test amount and life span. Unlike previous research, this study uses calculations with a higher amount of test frequencies which showed that even with a relatively low test frequency, automated regression tests have good opportunities for a positive ROI. With a medium to high test frequency, the break-even point was reached within one year with possibilities for great time savings. The empirical material has also shown that the start-up phase, system type, test case complexity and reusability are factors that can affect the time savings.

ROI och break-even finns för att beräkna vinster i verksamheter men det är svårt att veta hur dessa metoder kan appliceras på automatiserade GUI-test. Genom en utförd fallstudie där litteraturstudier, dokumentstudier, enkäter och intervjuer använts har det visat sig att dessa metoder kan anpassas för att beräkna vinster med automatiserade GUI-tester. Nackdelarna med dessa metoder är att de är svåra att använda om inte automatiseringen är gjord. Det behövs konkreta uppgifter över till exempel tidsåtgång för körning av både manuella och automatiserade testfall. Även om metoderna kan visa att det finns ekonomiska vinster med automatiserade GUI-tester så kan det vara många andra vinster som inte kan identifieras genom att metoderna appliceras. Dessa immateriella vinster och förluster har i arbetat identifierats genom intervjuer och enkäter och resultatet presenteras med en SWOT-analys. Flera viktiga immateriella vinster som till exempel ökad kvalitet och tidsvinst har framkommit. Även några materiella förluster har framkommit som att det kan vara kostsamt att införa automatiserade GUI-tester. Även immateriella förluster har identifierats, en av dessa är att det krävs särskild kompetens för att konstruera och köra de automatiserade testerna. / ROI and break-even are available for calculating profits in operations, but it is difficult to know how these methods can be applied to automated GUI tests. By a conducted case study in which literature review, document studies, questionnaires and interviews have been used, it has been shown that these methods can be adapted to calculate the profits with automated GUI-tests. The disadvantages with these methods are that they are difficult to use unless the automation is made. There is a need for concrete data on, for example, the time taken for the execution of both manual and automated test cases. Although the methods can show that there are financial gains with automated GUI tests, there may be many other gains that cannot be identified by applying the methods. These intangible profits and losses have been identified in the work through interviews and surveys and the results are presented with a SWOT analysis. Several important intangible benefits such as increased quality and time savings have emerged. Some material losses have also come to light as it can be costly to introduce automated GUI tests. Even intangible losses have been identified, one of these is that it requires special skills to design and run the automated tests.

Test av mjukvara görs i syfte att se ifall systemet uppfyller specificerade krav samt för att hitta fel. Det är en viktig del i systemutveckling och involverar bland annat regressionstestning. Regressionstester utförs för att säkerställa att en ändring i systemet inte medför att andra delar i systemet påverkas negativt. Dokumenthanteringssystem hanterar ofta känslig data hos organisationer vilket ställer höga krav på säkerheten. Behörigheter i system måste därför testas noggrant för att säkerställa att data inte hamnar i fel händer. Dokumenthanteringssystem gör det möjligt för flera organisationer att samla sina resurser och kunskaper för att nå gemensamma mål. Gemensamma arbetsprocesser stöds med hjälp av arbetsflöden som innehåller ett antal olika tillstånd. Vid dessa olika tillstånd gäller olika behörigheter. När en behörighet ändras krävs regressionstester för att försäkra att ändringen inte har gjort inverkan på andra behörigheter. Denna studie har utförts som en kvalitativ fallstudie vars syfte var att beskriva utmaningar med regressionstestning av roller och behörigheter i arbetsflöden för dokument i dokumenthanteringssystem. Genom intervjuer och en observation så framkom det att stora utmaningar med dessa tester är att arbetsflödens tillstånd följer en förutbestämd sekvens. För att fullfölja denna sekvens så involveras en enorm mängd behörigheter som måste testas. Det ger ett mycket omfattande testarbete avseende bland annat tid och kostnad. Studien har riktat sig mot dokumenthanteringssystemet ProjectWise som förvaltas av Trafikverket. Beslutsunderlag togs fram för en teknisk lösning för automatiserad regressionstestning av roller och behörigheter i arbetsflöden åt ProjectWise. Utifrån en kravinsamling tillhandahölls beslutsunderlag som involverade Team Foundation Server (TFS), Coded UI och en nyckelordsdriven testmetod som en teknisk lösning. Slutligen jämfördes vilka skillnader den tekniska lösningen kan utgöra mot manuell testning. Utifrån litteratur, dokumentstudie och förstahandserfarenheter visade sig testautomatisering kunna utgöra skillnader inom ett antal identifierade problemområden, bland annat tid och kostnad. / Software testing is done in order to see whether the system meets specified requirements and to find bugs. It is an important part of system development and involves, among other things, regression testing. Regression tests are performed to ensure that a change in the system does not affect other parts of the system adversely. Document management systems often deals with sensitive data for organizations, which place high demands on safety. Permissions in the system has to be tested thoroughly to ensure that data does not fall into the wrong hands. Document management systems make it possible for organizations to pool their resources and knowledge together to achieve common goals. Common work processes are supported through workflows that contains a variety of states. These different permissions apply to different states. When a permission changes regression tests are required to ensure that the changes has not made an impact on other permissions. This study was conducted as a qualitative case study whose purpose was to describe the challenges of regression testing of roles and permissions in document workflows in a document management system. Through interviews and an observation it emerged that the major challenges of these tests is that workflow states follow a predetermined sequence. To complete this sequence, a huge amount of permissions must be tested. This provides a very extensive test work that is time consuming and costly. The study was directed toward the document management system ProjectWise, managed by Trafikverket. Supporting documentation for decision making was produced for a technical solution for automated regression testing of roles and permissions in workflows for ProjectWise. Based on a requirement gathering decision-making was provided that involved the Team Foundation Server (TFS), Coded UI and a keyword-driven test method for a technical solution. Finally, a comparison was made of differences in the technical solution versus today's manual testing. Based on literature, document studies and first hand experiences, test automation provides differences in a number of problem areas, including time and cost.

Testning är en nödvändig men kostsam del av mjukvaruutveckling. Test utförs på olika abstraktionsnivåer och kan vara manuella eller automatiserade. På lägsta abstraktionsnivå, enhetsnivå, är automatiserad testning vanligt och relativt okomplicerat, medan systemtester är svårare att automatisera. I synnerhet gäller detta tester på ett grafiskt användargränssnitt (GUI) som kräver speciella verktyg.   Triona vill undersöka möjligheterna att automatisera regressionstester från GUI:t av sin produkt C-Load, en molnbaserad webbtjänst för avtalsbaserad transportbokning.    Det primära syftet med denna fallstudie är att med en anpassad urvalsprocess utvärdera ett möjligt verktyg i förhållande till C-Load-förvaltningens förväntningar på automatiserad GUI testning (AGT) och att utifrån resultatet föreslå hur C-Loadförvaltningen kan gå vidare med val av verktyg för AGT. För att uppfylla syftet användes litteraturstudier, intervjuer och observationer av praktiska test.    Verktyg för GUI-testning kan delas in i tre huvudkategorier: skriptbaserade, modellbaserade och skriptlösa. Baserat på tidigare forskning drogs slutsatsen att ett skriptbaserat verktyg där koden i testskripten skrivs manuell bäst passar C-Loadförvaltningens krav och förutsättningar. Det mest använda verktyget av denna typ, Selenium WebDriver, utvärderades kvalitativt gentemot identifierade krav.    Av tidigare forskning framgår att vanliga utmaningar med skriptbaserade GUI-tester är att arbetsinsatsen för att skapa och underhålla testskript är stor och att testen kan vara opålitliga. Dessa problem framkom också i studiens intervjuer och observationer.   Slutsatsen är att det vore möjligt att automatisera regressionstester av C-Load med hjälp av Selenium Webdriver, och att det på sikt skulle kunna frigöra tid. Initialt krävs dock en omfattande insats för att implementera automatiserade tester i förvaltningen och Selenium Webdriver uppfyller bara delvis C-Load-förvaltningens förväntningar på AGT. C-Load-förvaltningen rekommenderas att utvärdera fler verktyg innan beslut fattas. I en kommande urvalsprocess bör Triona beakta hur väl olika verktyg fungerar i förhållande till moderna webbramverk. / Testing is a necessary but costly part of software development. Tests are performed at different abstraction levels and can be either manual or automated. On the lowest level of abstraction, where unit testing is performed, automated testing is commonplace and relatively uncomplicated, whereas system testing is more difficult to automate. This is especially true for GUI-testing, which requires special tools.      Triona wished to investigate possibilities to automate regression testing of the GUI for its C-load product, which is a Cloud-based web-service for contract-based transport booking.      The purpose of this case study was to evaluate one tool for automated GUI-testing (AGT) against the C-Load team’s expectations on AGT, and based on the result recommend Triona how to proceed in the process of implementing AGT. Literature studies, observations and interviews were conducted to fulfil the purpose.      GUI-testing tools can be classified into three categories: script-based, model-based and scriptless. One conclusion was that a script-based tool, where test scripts are manually coded would best suit Triona’s needs. The most used tool in that category, Selenium WebDriver, was tested and evaluated against requirements.       Prior research shows that common challenges encountered when using script-based GUItests are the workload required to create and maintain test scripts and that the tests can deliver inconsistent or “flaky” results. These challenges were confirmed during our analysis.       Our conclusion is that it is possible to automate C-Load regression tests with Selenium WebDriver, and that it would eventually free up time. However, a considerable effort is initially required to implement automated testing. Selenium Webdriver only partly fulfills the C-Load team’s expectations on AGT. Before a decision is taken, the C-Load team should evaluate more tools. When evaluating tools for AGT, Triona should take note that Selenium Webdriver can be deficient when it comes to testing applications based on modern web frameworks.