No description available.

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.

Testning av programvara utgör i många fall en stor del av den totala utvecklingstiden. Då testning drar mycket resurser finns det en önskan om att testningen ska kunna utföras så effektivt som möjligt. Ett steg mot en effektivare testning är automatisering, då detta, om korrekt utfört, medför att fler fel kan identifieras på kortare tid. Det finns däremot risker och fallgropar på vägen mot automatiserad testning. I det här arbetet ges en översikt av 21 krav som forskning och litteratur ställer på en utvecklingsprocess för att automatiserad testning ska kunna genomföras lyckat. Därefter presenteras en metodik som tagits fram för hur översikten kan användas i en organisation för att få en lägesbild av möjligheterna till automatisering. Denna metodik har validerats i en fallstudie, som påvisat att kraven tillsammans med metodiken kan användas för att diskutera en organisations möjligheter till automatiserad testning.

Idag arbetar allt fler företag inom agil systemutveckling vilket innebär att utvecklingsarbetet sker i korta iterationer. Att arbetet sker i korta iterationer innebär att det är mycket som ska göras på kort tid både inom utveckling och test. För att hinna med testarbetet krävs det därför att man arbetar med automatiserade tester. Automatiserade tester är en typ av automation som i sig är ett problematiskt område då människor misslyckas med att förlita sig på automation. Om människor inte litar på automatiserade tester leder det till att manuell testning ändå kommer att ske för att säkerställa resultaten av de automatiserade testerna vilket gör att värdet av att automatisera tester uteblir. Syftet med denna uppsats är att svara på hur tillit till automatiserade tester påverkas utifrån kunskap om automatiserade tester, tillit till personen som skapar automatiserade tester samt feedback från automatiserade tester. En kvalitativ undersökning i form av intervjuer har genomförts för att besvara frågeställningen. Undersökningen har genomförts på ett undersökningsföretag som levererar ekonomiprogram och internetlösningar till företag och redovisnings- och revisionsbyråer. Resultatet av den empiriska undersökningen visade att kunskap om automatiserade tester, tillit till personen som skapar automatiserade tester och feedback från automatiserade tester är aspekter som påverkar människors tillit till automatiserade tester. Brist på kunskap påverkar tillit då människor antingen skapar sig en övertro eller undertro till automatiserade tester. Har människor kunskap om automatiserade tester känner de också tillit till testerna. Att känna tillit till personen som skapar automatiserade tester påverkar tillit då människor känner mer tillit till automatiserade tester om de vet vem personen är, känner tro till personen samt dennes kunskap. Feedback från automatiserade tester påverkar människors tillit då utebliven feedback leder till att de inte vet vilka tester som finns och vad de gör. Detta gör att människor inte känner tillit till dem. / Today, an increasing number of companies’ uses agile system development which means that the development work is done in short iterations. Short iterations means that there is much to be done in a short time both in development and testing. To keep up with the testing it is required to use automated testing. Automated tests are a type of automation that in itself is a problematic area because people fail to rely on automation. If people have a lack of trust in automated testing it will cause them to still use manual testing, which will make the value of automating tests fail. The purpose of this paper is to respond to how people ́s trust in automated testing is affected based on knowledge of automated testing, trust in the person creating automated tests and feedback from automated testing. A qualitative study and interviews have been conducted to answer the question. The survey has been conducted on a research company that delivers finance software and internet solutions to companies and accountancy firms. The result of the empirical survey shows that knowledge of automated testing, trust in the person who creates automated testing and feedback from the automated tests are aspects that affect people's trust in automated testing. Lack of knowledge affects people ́s trust in automated testing in a way that leads to that people either create an overtrust or mistrust to the automated tests. People that have knowledge of automated tests feels trust in the tests. To have trust in the person that creates automated tests affects people's trust in that way that people feel more trust in automated testing if they know who the person is, feel the confidence to the person and his or her knowledge. Feedback from automated testing affects people's trust when no-feedback is taking place. This leads to that they do not know which tests there is and what they do. This means that people do not trust them.

Inom dagens systemutvecklingsprojekt har testning en viktig roll för att ett företag ska kunna lyckas leverera en produkt. Testning har ofta nedprioriteras pågrund av att det största fokuset har legat på nyutveckling. Testrollen är väldigt viktig för att kunna försäkra om sin produkt är redo för marknaden.   Syftet med uppsatsen är att ta reda på utmaningar och problem med testautomatiseringens startprocess i en agil systemutvecklingsmiljö. Vad företag och undersökningsföretaget som startar med testautomatiseringen kan förbereda sig på för att kunna lyckas.   Undersökningen som uppsatsen bygger på har använt en induktiv ansats. Undersökningen har skett på ett undersökningsföretag som arbetar agilt inom systemutveckling. Målet är att undersöka verkligheten utan att söka svar och undersöka orsakssambanden. Syftet är att påståenden från teori och tidigare undersökningar ska jämföras med resultatet. Kvalitativ metod har använts för datainsamling i form av intervjuer.   Resultatet av undersökningen bevisar att testautomatiseringen är väldigt viktigt inom den agila systemutvecklingsmiljön och att det finns en många problem och utmaningar som behövs tänkas på när ett system ska börja med testautomatisering. Den agila utvecklingsmetoden har blivit vanligare inom utvecklingsbranschen och därför kommer också testautomatisering bli vanligare. Många av problemen och utmaningarna håller inte ihop, utan påverkas av olika konsekvenser. Resultatet av uppsatsen kom fram till utmaningar och problem med: testdata/testmiljö, förståelse, struktur, verktyg och kompetens.   Målet med uppsatsen är att bidra med nyttig information till ökad medvetenhet om vad som krävs för att starta igång testautomatisering. / Within today´s system development projects, testing have been an important role within company to be able to successfully deliver their product. Testing has often given a lower priority unfortunately, because focuses have been on new development. The test role is very important in order to insure their product is ready for the market.   The purpose of this paper is to find out the challenges and problems with test automation start-up process in an agile system environment. What companies that start with test automation could prepare in order to succeed.   For the survey on which the essay is based on an inductive approach has been used. The investigation has taken place at a research company that works with agile in system. The objective is to investigate reality without getting any answers. The aim is to claims from theory and previous information will be compared with the results. Qualitative methods were used for data collection in the in the form of interviews.   The survey results prove that test automation is very important in the agile system development environment and that there are a lot of problems and challenges that need arise when a system should start with test automation. The agile development methodology has become more prevalent in businesses and test automation will be development. Many of the problems or challenges do not hold together, without affected by different consequences. The results of the thesis came to the challenges and problems with: test data/test environment, understanding, structure, tools and skills.   The goal of this paper is to provide useful information to increase awareness of what is required to start running with test automation.

This project was designed to help Hi3G Access AB’s IT department to get a better overview of the testing state in the different cross functional teams. Furthermore it was designed to identify teams and system where regression tests had the potential and the need of being automated. This information was gathered by conducting a survey designed for all the software testers at the company, followed by performing semi-structured interviews with one tester from each team. For the most suitable system and test case, an automation solution prototype was created with an automation tool using an agile test automation process model. The automation tool was evaluated regarding complexity, userfriendliness, available documentation and performance. The team and the system decided to be most prioritized and suitable was the team that worked with the Enterprise resource planning (ERP) system. The automation tool used for the prototype was Oracle applications testing suite (OATS). The project revealed that many teams at Hi3G Access AB were quite far in the automation process. The tool evaluated in the project presented itself to be straightforward and easy to learn/use. However the tool was missing a widespread discussion board and also lacked free support. / Projektet var utformat för att hjälpa Hi3G Access ABs IT-avdelning få en bättre överblick gällande de olika korsfunktionella gruppers testsituation. Vidare var målet att identifiera team och system där regressionstester hade potential och behov av automatisering. Denna information samlades in genom att utföra en enkät avsedd för alla mjukvarutestare på företaget, följt av att utföra semistrukturerade intervjuer med en testare från varje team.För det mest lämpliga system och testfall skapades en automatiserad prototyplösning genom en agil testautomatiseringsmodell. Automatiseringsverktyget utvärderas gällande komplexitet, användarvänlighet, tillgänglig dokumentation och prestanda.Teamet och systemet som valdes som mest prioriterat och lämpligt var teamet som arbetade med Enterprise resource planning (ERP) systemet. Automatiseringsverktyget som användes för prototypen var Oracle Applications Testing Suite (OATS).Projektet visade att många team på Hi3G Access AB hade kommit ganska långt i automatiseringsprocessen. Verktyget som utvärderades visade sig vara okomplicerat och lätt att både lära sig och att använda. Däremot så var avsaknaden av ett utbrett diskussionsforum ett faktum samt att produkten saknade fri support.

Quality assurance is becoming increasingly important to implement in expanding development projects. The components being built must be tested regularly to ensure the functionality of the whole product. Leeroy applies scrum as a development method along with manual GUI tests that only are performed when all components belonging to each sprint are completed. This leads to shortage in time for a tester to apply the assigned test scenarios. Testers are therefore subjected to stress in their work as testing requires high accuracy and speed in order to effectively ensure that the components end up in a production environment. The purpose of this study is to streamline current test processes by replacing manual GUI tests with automated GUI regression tests using BDD principles. Specification of the requirements was carried out using data collection methods that were chosen for this study. The specifications were used both to evaluate the construction as well as the results obtained. The results show that it is important that both the tester and the rest of the agile team cooperate during each sprint, as the components are developed incrementally and tested regularly. The results show even the importance of prioritizing the test scenarios; this is done to ensure the efficiency of the workflow by first choosing the most important components to test. The tested aspects in this study have also proven that both frameworks Cucumber and Puppeteer have the potential to contribute to a smooth implementation of BDD in an agile development team. This is due partly to the reasonable results from the performance tests that measured the speed of feedbacks as an efficiency test, partly to a high degree of both usability and reusability. This study is limited to few test scenarios due to shortage of time given for this course and therefore the performance results doesn’t express all kind of testing scenarios. / Kvalitetssäkring blir allt viktigare att genomföra i växande utvecklingsprojekt. Komponenterna som byggs måste testas regelmässigt för att garantera funktionaliteten av produkten som utvecklas. Leeroy tillämpar idag Scrum som utvecklingsmetod med manuella tester som genomförs när alla komponenter är färdigbyggda vid slutet av varje sprint. Detta leder till att testaren har kortare tid på sig för att utföra testscenarierna. Testaren utsätts därför för stress i sitt arbete då uppdraget kräver en hög noggrannhet med snabbhet för att effektivt försäkra att komponenterna hamnar i en produktionsmiljö. Syftet med undersökningen är att effektivisera nuvarande testprocesser genom att ersätta de manuella GUI-tester med automatiserade GUI- regressionstester som tillämpar BDD principer. Specificering av kraven genomfördes med hjälp av datainsamlingsmetoder som valdes till denna undersökning. Kravspecifikationerna användes dels för utvärdering av konstruktionen och dels för utvärdering av de erhållna resultaten. Resultaten visar att det är viktigt att både testaren och resten av det agila teamet samarbetar under varje sprint, då komponenterna utvecklas inkrementellt och testas regelmässigt. Resultaten visar vikten av att prioritera testerna som kommer att utvecklas för att säkra effektiviteten i arbetsflödet och även säkra att de viktigaste funktionerna testas först. Undersökningen har visat att både Cucumber och Puppeteer kan bidra till en smidig implementation av BDD i ett agilt utvecklingsteam. Detta beror dels på de rimliga resultaten från prestandatesterna som mäter effektiviteten, dels en hög användbarhetsgrad vad gäller både läsbarhet och skrivbarhet i syntaxen och dels en hög återanvändbarhetsgrad. Denna studie avgränsades till få antal testscenarier på grund av brist på tid i undersökningen och därför visar resultaten från prestandatesterna inte alla slags testscenarier.

Information systems are used by most organisations today and are critical to the business. Many organisations got one or more legacy systems which have been used for a long period of time. Failures and disruption in these systems can lead to great consequences and it is important to test the systems to avoid them. Manual testing requires much resources. To automate the tests are a possibility and our partner in this study, Stora Enso Skog, wanted to look into the possibilities.The purpose of this study is to describe what challenges you meet when automating tests for legacy systems. The purpose is also to describe what factors you need to consider when implementing test automation. To do this we have used a case study and gathered data through interviews and study of documents. The interviews have been conducted with experienced experts within the testing area.Our conclusions shows that there are a number of challenges to consider when automating tests for legacy systems. The challenges include problems trying to automate some sort of tests for legacy systems due to the code being unstructured and not prepared for tests. There’s also a risk of spending too much resources in automating the tests instead of improving the systems.A number of factors to consider when implementing automated tests for legacy systems have also been found. Examples given are that automating tests can never fully compensate for a bad architecture and design. Focus should also be on the most important tests and start automating small parts. Also to improve the possibility to test in legacy systems instead of just adopting the testing tool to the system is to be considered.Finally we have noted that there are different types and levels of legacy systems and because of that challenges and factors to consider when automating tests may vary. Many challenges and factors presented in this study also applies to systems not considered legacy. / Informationssystem används idag av de flesta organisationer och är kritiska för att verksamheten skall fungera väl. Många organisationer har ett eller flera så kallade legacysystem som funnits i verksamheten en tid. Fel i systemen kan leda till stora konsekvenser och för att undvika detta är det viktigt att de testas. Att manuellt testa är resurskrävande. Möjligheter finns att automatisera tester i informationssystem vilket vår samarbetspartner Stora Enso Skog velat undersöka.Syftet med detta examensarbete är att beskriva vilka utmaningar som finns vid automatisering av tester för legacysystem. Syftet är vidare att beskriva vilka faktorer som behöver beaktas vid implementering. Arbetet har genomförts som en fallstudie och datainsamling har skett genom intervjuer och dokument. Intervjuer har genomförts med erfarna och kunniga inom testområdet.Slutsatserna är att det finns ett antal utmaningar vid automatisering av test av legacysystem. Exempel på utmaningar är att det kan vara svårt att automatisera vissa typer av test då koden i legacysystem ofta är ostrukturerad och inte förbered för test. Det finns också risk att man lägger för mycket resurser på automatiserade tester istället för att förbättra informationssystemet.Faktorer att beakta vid implementering är bland annat att automatisering av test aldrig kan kompensera för en dålig arkitektur och design. Man bör också fokusera på det viktigaste delarna och börja i mindre omfattning. Att utveckla testbarheten i legacysystem istället för att bara anpassa testverktyg efter systemet är en annan faktor.Vi har slutligen konstaterat att det finns olika typer eller nivåer av legacysystem och beroende på det kan utmaningar och faktorer vid automatisering av test variera. Många av de utmaningar och faktorer som presenteras i examensarbetet gäller även system som inte klassas som legacysystem.

A lot of time is spent on manual software testing. When software can interact with exponentially more and more components the number of tests required will increase at the same rate. Automation of these manual tests has been previously shown that a time-saving can occur with test automation. When tests need to be done on software that interacts with physical components the results of testing automation are harder to predict. This thesis aims to explain the impact of physical components on the development and the result of test tools developed for use on automated tests on objects with physical components. In this work, a test tool for automatic regression testing for height adjustable table legs were developed. The method used to design the tool was Design Science Research where, for example, TESLA was adapted for use in automated tests with physical components. TESLA is a language for specifying test cases and allowing test automation with embedded systems that was implemented in the test tool's design which could be used to automatically generate scripts and automatically executes test cases. With the development and design of the testing tool, the thesis attempted to answer how a test tool should be designed when physical components are included in the test object and how the measurement accuracy of the tool may affect the test result. Experiments have been carried out during the development process where regression tests have been performed according to a test protocol. During these experiments a test protocol is executed. One manually by hand and one is done automatically with the testing tool. The results of the experiments show that the execution of the test protocol execution with the test tool gave a time saving of 35% compared to the manual tests. The physical components of the test object were shown to affect the automatic execution time negative and further analysis of previous research has shown that this result is insufficient to justify the large initial time that is required to automate tests. / Mycket tid spenderas ofta på manuell testning av mjukvara. Då en mjukvara kan interagera med exponentiellt mer komponenter så kommer antalet tester att öka i samma takt. Automatisering av dessa manuella tester har med tidigare forskning bevisat att en tidsbesparing kan ske med testautomatiseringen. Då tester måste utföras på mjukvara som interagerar med fysiska komponenter så är resultaten av testautomatisering inte lika klara och arbetet syftar på att förklara de fysiska komponenternas påverkan på utveckling och resultatet för testverktyg som används till automatisk testning av testobjekt med fysiska komponenter. I detta arbete så framtogs ett testverktyg för automatiska regressionstest för höj och sänkbara bordsben. Metoden som användes för att utveckla verktyget var Design Science Research där till exempel TESLA anpassades för användning i automatiska tester med fysiska komponenter. TESLA är ett språk för att specificera testfall och möjliggöra testautomatisering i inbyggda system implementerades i testverktygets design och kunde då automatisk generera skript och automatiskt exekvera testfall. Med utvecklingen och design av testverktyget så försökte arbetet svara på hur ett testverktyg bör vara designat när fysiska komponenter ingår i testobjektet och hur testverktygets mätnoggrannhet kan påverka testresultatet. Experiment har utförts under arbetets gång där regressionstester har utförts enligt ett testprotokoll. Under experimenten utfördes ett testprotokoll manuellt för hand och ett automatiskt med testverktyget. I båda situationerna så mättes testprotokollets utförande i tid. Testverktyget gav en tidsbesparing på 35% visavi de manuella testerna. Testobjektets fysiska komponenter hade en negativ påverkan på den automatiska exekveringstiden och vidare analys av tidigare forskning har visat att detta resultat inte räcker för att motivera den stora initiala tidsinvestering som krävs för att automatisera tester.

The focus of this study is on examining when employees in the IT industry experience that it is more favorable to use automated tests and manual tests, respectively. The purpose of this study is to investigate how different companies in practice, use, work with and think about the two different test methods. Four factors that influence the choice of test method have been developed as a workframe based on five articles, all of which discuss the requirements and criteria for the two different test methods. By conducting an interview study with semi-structured interviews, data has been retrieved from two different companies. The data has in turn been analyzed based on the four factors that have been developed, namely: the number of test cases/test runs, technical aspects, what functions that are to be tested and resources. Based on the analyzes, it has been clear that the opinions from the different respondents and from previous research often remain on the same track. Thus, the various criteria could be discussed and the motivation for when the respondents use each method could be outlined. However, it also becomes clear that in the end it is mainly resources, often the number of working hours and the monetary cost, that determines what practice of testing is to be used. / Denna studie riktar in sig på att undersöka när anställda inom IT-branschen upplever att det är mer gynnsamt att använda sig av automatiserade tester respektive manuella tester. Syftet med studien är att undersöka hur olika företag använder sig, arbetar med och ser på de två olika testmetoderna i praktiken. Fyra stycken faktorer som påverkar valet av testmetod har tagits fram som ramverk som är baserad på fem artiklar där samtliga diskuterar krav och kriterier för de två olika testmetoderna. Genom att utföra en intervjustudie med semi-strukturerade intervjuer har data samlats in från två olika företag. Den insamlade datan har i sin tur analyserats utifrån de olika faktorerna som tagits fram nämligen: Antalet testfall/testkörningar, tekniska aspekter, funktioner som ska testas samt resurser. Utifrån analysen har det varit tydligt att åsikterna från de olika respondenterna samt från tidigare forskning ofta är på samma spår. Därmed har de olika kriterierna kunnat diskuterats och motiveringarna till när respondenterna använder sig av respektive metod kunnat benas ut. Dock blir det också tydligt att i slutändan är det resurser, oftast antalet arbetstimmar och den monetära kostnaden, som styr vad som borde väljas.