I dagens utveckling av webbapplikationer, vilka blir alltmer komplexa, är det viktigt att testa sina webbapplikationer grundligt. En kort exekveringstid av testerna är särskilt viktigt, då de komplexa webbapplikationerna tar allt längre tid att testa manuellt. Det är angeläget att använda automatiserade GUI tester, för att stödja Agila arbetssätt med korta tider för leverans av nya versioner. För att säkerställa att de kan användas vid varje hopslagning av grenar i utvecklingsspåren inför en leverans av den kommande versionen. Ett problem med automatiserade GUI tester är att det alltid har varit svårt att underhålla testfallen när webbapplikationen har ändrats. Därför är det viktigt att det är lätt att underhålla testfallen i testverktygen. I den här studien har två testverktyg för automatiserade GUI tester utvärderats avseende underhållbarhet och exekveringstid. Fördelar och utmaningar med att introducerade automatiserade GUI tester har även de lyfts fram och analyserats. För att undersöka vilka fördelar och utmaningar som finns med att introducera automatiserade GUI tester utfördes en litteraturstudie på tidigare studier. Ett antal fördelar och utmaningar med automatiserade GUI tester har lyfts fram. Den genomgående största utmaningen med automatiserade GUI tester är underhållbarheten av testfallen. När webbapplikationen vidareutvecklas och framförallt i ett tidigt stadium i dess livscykel när mycket ändrar sig är det kostsamt att underhålla testfallen. Det är även en utmaning att implementera testfallen på ett sådant sätt att det blir lätta att underhålla. Vad gäller fördelar är den absolut främsta tidsvinsten i exekveringstid av testfall samt ökad kvalitet genom att tester utförs oftare. Det första experimentet som har utförts var att jämföra exekveringstiden mellan Cypress och Selenium Webdriver. Ett antal testfall har skapats som återspeglar hur webbapplikationen används. Experimentet visar att Selenium Webdriver presterar bättre än Cypress när det exekveras på en utvecklingsdator. Ytterligare jämförelse av prestandan i en CI miljö bör utföras för att se hur Cypress presterar med parallell exekvering av testfall. Det andra experimentet som utförts jämför underhållbarhet mellan Cypress och Selenium Webdriver. Resultatet av det här experimentet har visat att det finns fördelar och nackdelar med båda testverktygen och hur testfallen är skrivna. Cypress är i det här fallet något mer robust när strukturen på sidan ändras. Cypress klarade av ändringen utan några uppdateringar i testkoden. Selenium Webdriver visades vara lite bättre på att hantera när texten på elementen ändras. Det här beror primärt på hur testfallen är skrivna. Experimentet ger ingen tydlig indikation på vilket testverktyg som är bäst. Det visar mest hur olika svårt det är att skriva testfallen och att komma igång med dem i de båda testverktygen. Problemet med underhållbarhet finns fortfarande kvar. Cypress som ett nytt testverktyg lyckas inte lösa det fullständigt. Resultatet av experimentet visar att det inte finns ett testverktyg som kan klassas som bäst. Däremot har Cypress en lovande framtid som ett testverktyg, det är lättare att komma igång med och har bra verktyg vilket underlättar arbetet som testare.

Context. GUI-based automation testing is a costly and tedious activity in practice. As GUIs are well-known for being modified and redesigned throughout the development process, the corresponding test scripts are not valid anymore thereby being a hindrance to automation. Hence, substantial effort is invested in maintaining GUI test scripts which often leads to rework or waste due to improper decisions. As a result, practitioners have identified the need for decision support regarding when should GUI automation testing begin and how to make it easier and also identify what are the factors leading to waste in GUI-based automation testing. The current literature provides solutions relating to automation in general and few answers for GUI based-automation testing. Such generic answers might not be applicable to GUI test automation and also industries new to GUI development and testing. Thus, it is necessary to validate if the general solutions are applicable to GUI test automation and find additional answers that are not identified previously from practitioners opinions in an industrial context. Objectives. Capture relevant information regarding the current approach for GUI test automation within the subsystems from a case company. Next, identify the criteria for when to begin automation, testability requirements and factors associated with waste from literature and practice. Methods. We conducted a multiple-case study to explore opinions of practitioners in two subsystems at a Swedish telecommunication industry implementing GUI-automation testing. We conducted a literature review to identify answers from scientific literature prior to performing a case study.A two-phased interview was performed with different employees to collect their subjective opinions and also gather their opinions on the evidence collected from the literature. Later, Bayesian synthesis method was used to combine subjective opinions of practitioners with research-based evidence to produce context-specific results. Results. We identified 12 criteria for when to begin automation, 16 testability requirements and 15 factors associated with waste in GUI test automation.Each of them is classified into categories namely SUT-related,test-process related, test-tool related, human and organizational, environment and cross-cutting. New answers which were not present in the existing literature in the domain of the research are found. Conclusions. On validating the answers found in literature, it was revealed that the answers applicable for software test automation, in general, are valid for GUI automation testing as well. Since we incorporated subjective opinions to produce context specific results, we gained an understanding that every practitioner has their own way of working. Hence, this study aids in developing a common understanding to support informed subjective decisions based on evidence.

Ziel der Arbeit war es, die Systemtestautomatisierung zu vereinfachen. Gerade in Hinblick auf Stabilität und Wiederverwendbarkeit konnten die in der Praxis eingesetzten Möglichkeiten nicht vollständig überzeugen. Der in der Abhandlung erarbeitet Zielzustand, die „strukturierte Automatisierung des SystemTests“ (SAST) integriert den Systemtest in „MOdel Compiler for generating Complete Applications“ (MOCCA), ein modelgetriebenes Anwendungsgenerierungsframework. MOCCA generiert aus Struktur- und Verhaltensmodellen voll-ständige Softwaresysteme. Er wurde an der TU Bergakademie Freiberg entwickelt. Zur leichtgewichtigen Modellierung des Anwendungsverhaltens wurde es durch die Dissertation von Dr. Liang (vgl. [Lian2013]) u. a. um eine Action Language eXtended Object Constraint Language (XOCL) erweitert. Diese Verhaltensbeschreibungsmöglichkeit wurde in SAST ebenso für die Verhaltensabbildung des Systemtests genutzt und bildet einen Pfeiler in dem erstellten Prototyp zur Systemtestgenerierung. SAST bezieht sich auf GUI-basierte Softwaresysteme. Sie bildet, wie es für den Systemtest charakteristisch ist, Fachprozesse anhand der Oberfläche ab. Zur Lösung wurden, neben dem Testverhalten, Artefakte zur Teststrukturierung, Schlüsselwortbildung und eine Ausführungs-Engine erstellt und in den bestehenden Generierungspro-zess von MOCCA eingefügt. Mit den grundlegenden Charakteristika der Lösung – modellgetrieben, schlüssel-wort-orientiert und in Testfällen strukturiert – unterstützt die Arbeit die angestrebten Verbesserungen: Wiederverwendbarkeit, Wartungsarmut und frühzeitige Testfallentwicklung. Eine Ausgestaltung für konkrete Testfälle ermöglicht schnelle Testschwerpunkte und -reduzierungen im Rahmen des risikobasierten Tests.:1 Einleitung 2 Theoretisches Fundament 3 Analyse bekannter Methoden für den Systemtest 4 Strukturierte Automatisierung des SystemTests 5 Prototypische Systemtestmodellierung 6 Proof of Concept: Anwendung ,TranscriptGenerator' 7 Abschließende Bewertung und weitere Möglichkeiten

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.