Tesis sobre el tema "Automatiserad testning"

Företag arbetar ofta efter hårda krav från kunder där lösningar måste levereras på ett tidseffektivt sätt och samtidigt hålla en hög kvalitet. Detta i form av felfria och robusta system vilket delvis kan åstadkommas med hjälp av testning. Kraven på snabb leverans och hög kvalitet är däremot motpoler till varandra; snabb leverans genomförs ofta på bekostnad av kvalitet och tvärtom. Agila arbetsmetoder med tidiga och frekventa leveranser har ändrat på detta, men kräver samtidigt en ständig kvalitetsförsäkring under arbetets löptid. Under utveckling av mjukvara enligt dessa metoder förekommer därför en kontinuerlig kvalitetssäkringsprocess för att säkerställa att produkten dels uppfyller vad kravspecifikationen avser samt att levererad produkt håller en hög tekniskt kvalitet i form av buggfri och robust kod som innehar stor pålitlighet för framtiden. Då manuell testning är en kostnad- och resurskrävande metod har automatiserad testning blivit ett aktuellt alternativ för ökad effektivitet och hållbar utveckling. Målet med det här arbetet har varit att för Precio Systemutveckling AB utreda möjligheterna för en implementation av automatiserad testning av användargränssnitt, i en hos företaget redan existerande och etablerad utvecklingsprocess. Arbetet har genomförts med en inledande förstudie om testning med fokus på varför det är en extra viktig faktor i dagsläget. Detta följs av ett avsnitt där existerande teori och teknik för testning i generell mening avhandlats, följt av en närmare studie på hur automatiserad testning är rekommenderad att utföras ur ett perspektiv från utveckling av produkter inom Microsoft-teknologi.<br>Software companies work under a strict pressure from customers where solutions must be delivered in a timely manner as well as providing high quality and value. The products should be robust and without errors, which partially can be accomplished by testing during the development process. The requirement for an early delivery and a high quality does not always come hand in hand, but with the increased use of agile software development methods, this can be achieved. During agile development of software, there is a continuous process to ensure the quality of what is being developed, both to make sure that all the functional requirements are fulfilled, but also that the code behind is robust and dependable for the future. Since manual testing can be both time and resource consuming, automated testing has become a modern alternative to increase productivity and to maintain a sustainable development process. The goal of this thesis work has been to investigate the possibilities of implementing a solution for automated UI testing in an already existing development process at the company Precio Systemutveckling AB. The work has been conducted in three steps, starting with a literature study about testing in general, followed by an extensive research into suitable tools and technology for testing that exists today. After this, a deeper look was made at what the recommended solutions for implementing automated testing in a Microsoft-oriented enviroment were. The work was concluded with an actual implementation of automated testing on premise at Precio.

While the technological infrastructure that enables collaboration between municipalities, counties and private health care providers improves, so does the need for health-care providers to gain access to the right patient journal at the right time. For doctors, nurses and other health-care organization employees this goal is achieved by NPÖ, National Patient Summary. NPÖ effectively enables health-care records to be shared across organizational boundaries. This thesis is based on a demand by a mobile application that can give district nurses access to health-care records wherever they are. This thesis describes the development of a prototype of a mobile application aimed for NPÖ. This includes investigating a suitable mobile platform, investigating available card readers for reading electronic identification from SITHS cards and the ability to connect to external services such as NPÖ. The thesis also analyzes use of the security services that NPÖ is based on. From interviews with Jan Edquist, IT architect at Örebro County Council and Lennart Holeby, project manager of NPÖ roll out, the appropriate information sets for the mobile application has been identified. The thesis includes an investigation of two test frameworks for automated testing of the mobile application. Both frameworks could automate about 70 percent of the test cases that were identified for the application. The test frameworks proved rather different with respect to the requirements an organization has regarding learning curve, support and the mobile platforms the testing frameworks supports. During the implementation part of this thesis, the mobile application could not be finished due to some limitations regarding security and compatibility. The security services required for connections to NPÖ could not be implemented because SITHS card readers do not yet support mobile devices. Also, the SDK required on the mobile devices to implement security requirements cannot yet run in the mobile devices available to the market. Additionally, NPÖ does not support connections from public networks which are required for a mobile application.<br>Samtidigt som den tekniska infrastrukturen som möjliggör samverkan mellan kommuner, landsting och privata vårdgivare växer, ökar behovet för vård- och omsorgsgivaren att kunna komma åt rätt patientinformation vid rätt tidpunkt. För personal på sjukhus möjliggörs detta genom ett gemensamt journalsystem som kan ge tillgång till kritisk patientinformation över organisationsgränserna. Denna tjänst kallas nationell patientöversikt, NPÖ. Detta examensarbete grundar sig på en efterfrågan av en mobil applikation som kan ge distriktssjuksköterskor tillgång till patientinformation, var de än befinner sig. Examensarbetet beskriver framtagandet av en prototyp för en mobil applikation mot NPÖ. Inledningsvis analyseras möjligheter som finns för att utveckla applikationen. Detta innefattar utredning av lämplig mobil plattform, utredning av tillgängliga kortläsare för läsning av elektronisk identifikationshandling i form av SITHS-kort och möjligheten att ansluta sig till externa tjänster så som NPÖ. Rapporten beskriver även användning av de säkerhetstjänster som NPÖ bygger på. Med hjälp av en intervju med Jan Edquist, IT-arkitekt vid Örebro läns landsting och Lennart Holeby, projektledare vid införandet av NPÖ, har lämpliga informationsmängder för mobil applikationen valts ut. Examensarbetet har utrett två testramverk för automatiserad testning av den utvecklade applikationen. Båda ramverken kunde automatisera ca 70 procent av de testfall som var skrivna för applikationen. Testramverken skiljer sig främst med avseende på vilka krav en organisation har på bland annat testramverkens inlärningströskel, support och vilka mobilplattformar testramverken har stöd för. Det har i examensarbetet inte varit möjligt att utveckla en färdig applikation. Detta främst i och med att säkerhetslösningen inte har kunnat implementeras på grund av begräsningar i kortläsare. Säkerhetslösningen är inte heller kompatibel med mobila enheter. Därtill finns ännu inte NPÖ tillgängligt över publika nätverk.

I detta examensarbete utreddes huruvida elektriska tester av styrenheter för tunga fordon kan automatiseras på befintliga testmiljöer. Arbetet utfördes på uppdrag av Scania CV AB för arbetsgruppen Electronic Hardware som utför tester vid utveckling och verifiering av krav på styrenheter. Genom en automatiserad testprocess kan testarbetet effektiviseras och kvaliteten höjas. Testarbetet sker på testriggar som innehåller fullskalig hårdvara från lastbilar för att kunna emulera styrenhetens autentiska arbetsmiljö. För att komma fram till ett testsystem som kunde leva upp till de krav och behov som formulerats inom kravprocessen i arbetet användes utvecklingsmodeller. Utvärderingsmatriser användes för att välja den mjuk- och hårdvara som skulle vara mest lämplig för det automatiserade testsystemet utifrån kraven. Resultatet visade att testsystemet skulle bestå av en testprogramvara som körs på en vanlig persondator och ett inbyggt system med elektroniska komponenter för att kunna utföra de elektriska testerna. För att demonstrera testsystemets möjligheter i ett helhetstest konstruerades en prototyp som har funktionalitet att utföra ett testfall som kan dra stor nytta av att automatiseras, nämligen att testa omslagsnivåer för en digital ingång. Prototypen baserades på ett mikrokontrollerkort från Arduino och ett kretskort konstruerades till detta för att kunna utföra elektriska tester med högre spänningsnivåer som krävs för styrenheter på Scaniafordon. För att utforma testfall och hantera testprocessen valdes LabVIEW, en programvara där tester designas med ett grafiskt programmeringsspråk. Testresultaten för prototyptestsystemet visade att verifieringen av kraven för omslagsnivåer förenklas radikalt vid ett automatiserat förfarande, eftersom testtiden kunde minskas drastiskt, i synnerhet vid ett repetitivt förfarande.<br>This thesis work intends to study the possibilities to automate electrical testing of electronic control units in an existing test environment. The work was executed on behalf of Scania CV AB for the department Electronic Hardware, who run tests in development and verification of requirements for electronic control units. By using an automated testing system, the testing process could be made more effective and raise the quality. The testing work is done on test rigs which are equipped with full-scale hardware from real trucks to emulate the working environment the electronic control unit operates into. Development models were used to be able to create a testing system which could meet the requirements that were defined during the requirement engineering process. Evaluation matrices were used to choose the soft- and hardware that could be considered the most appropriate for the automated testing system according to the requirements. The result shown that the testing system should consist of a testing software that runs on an ordinary computer and an embedded system equipped with electronic components to enable the testing system for electrical tests. To demonstrate the possibilities of the whole testing system a prototype was manufactured which was designed to execute a test case that could greatly benefit from the advantages that comes with automation. It was a test case set out to measure voltage levels when switching in a digital input. The prototype was based on a microcontroller card from Arduino and was joined by a printed circuit board to be able to run electrical tests with the higher voltage levels that were demanded by electronic control units. To design test cases and manage the test process, LabVIEW was chosen, a software in which tests are designed in a graphical programming language. Test results for the prototype test system showed that verification of the requirements for voltage levels when switching was radically simplified by an automated procedure, as the test time could be drastically reduced, particularly in a repetitive procedure.

Under två decennier har utvecklare inom mjukvarutestning utvecklat testtekniken Modell-baseradtestning. Tekniken bygger på att man genererar testfall från en modell (tex i UML), istället föratt manuallet skriva testfall. Detta kan göra testprocessen mer effektiv, vilket leder till att merarbeten kan göras på kortare tid. Det kan också ses som en ekonomiskt fördel för företag därtestning är huvudområdet. Modell-baserad testning har goda omdömen och teorin för teknikenär väl dokumenterad i artiklar, arbeten samt böcker. Mycket tyder på att tekniken rent teoretisktär användbar i praktiken dessutom finns det väldigt lite kritik mot tekniken. Men trots alltdetta har Modell-baserad testning inte blomstrat inom IT-industrin.Syftet med detta arbete är att ta reda på vad anledningarna skulle kunna vara till att MBT intelyckats bättre inom industrin. I arbetet används tre olika MBT-verktyg för att testa och sedanjämföra om resultatet i praktiken blir som teorin beskriver tekniken. Studiens resultat pekar påatt tekniken fortfarande är omogen och många brister kring Modell-baserad testning stöts på.<br>For two decades, software testing developers have developed the Model-based testing technique.The technology is based on generating test cases from a model (e.g. in UML) instead of manuallywriting test cases. This can make the test process more efficient, which leads to more workcan be done in less time. It can also be seen as an economic benefit for companies where testingis the main area. Model-based testing has good reviews and the theory of the technique is welldocumented in articles, works and books. There are many indications that the technology istheoretically useful in practice, with a very few criticisms of the technology. Despite all this,Model-based testing has not expanded in the IT industry.The purpose of this study is to find out what the reasons could be to the fact that MBTdid not succeed better in the industry. In this thesis, three different MBT tools are used totest and then compare whether the result in practice becomes as the theory describes the technique.The result of the study indicates the opposite direction and many shortcomings regardingModel-based testing come across.

Denna uppsats behandlar skapandet av en mjukvarusandlåda, en metod med syfte att automatiskt kunna installera programvara och avlyssna trafiken som skickas på nätverket i händelse av att programvaran gör anslutningar under eller efter installationen som inte begärts av användaren och som kan vara oönskade. När beteenden som kan klassas som olämpliga uppdagas i proprietär programvara finns det ofta ett företag som står bakom programvaran, men i många fall av programvara med öppen källkod finns det ingen att lägga skulden på. Därför är det viktigt att själv kunna utvärdera programvara och av denna anledning skapas denna metod för att en användare ska kunna testa programvara innan den driftsätts. För att uppfylla denna funktionalitet skrevs ett skript som sedan används för att testa en grupp olika programvaror. Resultaten av testerna visar på att vissa programvaror inte gjorde några anslutningar, vissa gjorde anslutningar som var nödvändiga och vissa gjorde anslutningar som kan ifrågasättas beroende på vilka krav som finns.

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.

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.

Background. One important part of creating quality games is to make sure thegames work as intended. It is done by testing the game, often by playtesters that play the game repeatedly to identify problems. It is a time-consuming task, and some of the testing can be automated. Objectives. This thesis explores two different automated testing approaches. The approaches selected are Record and Replay, and Script-Based Testing. The testing approaches are evaluated on a commercial FPS game. Methods. The scientific method used in this thesis was an experiment to collect data on the two testing approaches. The testing approaches were implemented and then tested on the game. The data collected was the time to create a test case andthe execution time of the test. Results. Creating tests with the Script-Based approach was significantly slower compared to Record and Replay. There was no significant difference in execution time between Record and Replay and Script-Based Testing, but the Script-Based approach is slightly faster in most tests. Conclusions. Record and Replay and Script-Based Testing have different strengths and weaknesses. Record and Replay is fast at creating tests but is not adaptable to changes in the 3D world. Script-Based Testing is slow at creating tests but is adaptable, and therefore less maintenance is required.<br>Bakgrund. En viktig del av att göra ett bra spel är att säkerställa att spelet fungerar som det ska. Det görs genom testning, oftast av speltestare som spelar spelet om och om igen för att hitta fel. Det är en tidskrävande uppgift och en del av testningen kan automatiseras. Syfte. Denna avhandling undersöker två olika automatiserade testmetoder. De valda metoderna är spela in och spela upp och skriptbaserad metod. Testmetoderna utvärderas på ett kommersiellt FPS-spel. Metod. Den vetenskapliga metoden som användes i denna avhandling var ett exper-iment för att samla in data om de två testmetoderna. Testmetoderna implementerades och testades sedan på spelet. Den insamlade datan var tiden för att skapa ett testfall och testets exekveringstid. Resultat. Att skapa tester med det skriptbaserade metoden var betydligt långsammare jämfört med spela in och spela upp. Det fanns ingen signifikant skillnad i exekveringstid mellan spela in och spela upp och skriptbaserad testning, men den skriptbaserade metoden är något snabbare i de flesta tester. Slutsatser. Spela in och spela upp och den skriptbaserad metoden har olika styrkor och svagheter. Spela in och spela upp är snabbt att skapa tester men kan inte anpassas till förändringar i 3D-världen. Skriptbaserade metoden är långsam när det gäller att skapa tester men är anpassningsbar och därför krävs mindre underhåll.

We live in a society where automatization is becoming more common, whether it be cars or artificial intelligence. Software needs to be updated using patches, however, these patches have the possibility of breaking components. This study takes such a patch in the context of Ericsson, identifies what needs to be tested, investigates whether the tests can be automated and assesses how maintainable they are. Interviews were used for the identification of system and software parts in need of testing. Then tests were implemented in an automated test suite to test functionality of either a system or software. The goal was to reduce time of troubleshooting for employees without interrupting sessions for users as well as set up a working test suite. When the automated testing is completed and implemented in the test suite, the study is concluded by measuring the maintainability of the scripts using both metrics and human assessment through interviews. The result showed the testing suite proved maintainable, both from the metric point of view and from human assessment.

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.<br>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.

Test benches are commonly used to simulate events to an embedded system for validation purposes. Microcontrollers can be used for making test benches and can be programmed with a bare-metal style, i.e. without an Operating System (OS), for simple cases. If the test bench would be too complex for a microcontroller, then a Real-Time Operating System (RTOS) could be used instead of a more complex hardware. A RTOS has limited functionalities to guarantee high predictability. A General-Purpose Operating System (GPOS) has a vast number of functionalities but has low predictability. The literature study looks therefore into approaches to improve the real-time predictability of Linux. The result of the literature study finds an approach called Xenomai Cobalt to be the optimal solution, considering the target usecase and project resources. The Xenomai Cobalt approach was evaluated on a Raspberry Pi (RPi) 3 using its General-Purpose Input/Output (GPIO) pins and a latency test. An application was written using Xenomai's Application Programming Interface (API). The application used the GPIO pins to read from a function generator and to write to an oscilloscope. The measurements from the oscilloscope were then compared to the measurements done by the application. The result showed the measured dierences between the RPi 3 and the oscilloscope. The result of the measurements showed that reading varied 66:20 μs, and writing varied 56:20 μs. The latency test was executed with a stress test and the worst measured latency was 82 μs. The resulting measured dierences were too high for the project requirements. However, the majority of the measurements were much smaller than the worstcases with 23:52 μs for reading and 34:05 μs for writing. This means the system could be used better as a rm real-time system instead of a hard real-time system.<br>Testbänkar används ofta för att simulera händelser till ett inbyggt system för validering. Till simpla testbänkar kan mikrokontroller användas. För mer avancerade testbänkar kan RTOS användas på mer komplex hårdvara. RTOS har begränsad funktionalitet för att garantera en hög förutsägbarhet. GPOS har stora mängder funktionaliteter men har istället en låg förutsägbarhet.Litteraturstudien undersökte därför möjligheterna till att få Linux att hantera realtid. Resultatet av litteraturstudien fann ett tillvägagångssätt vid namn Xenomai Cobalt att vara den optimala lösningen för att få Linux till Real-Time Linux.Xenomai Cobalt utvärderades på en RPi 3 med hjälp av dess GPIO-pinnar och ett fördröjningstest. En applikation skrevs med Xenomai’s API. Applikationen använde GPIO-pinnarna till att läsa från en funktionsgenerator och till att skriva till ett oskilloskop. Mätningarna från oskilloskopet jämfördes sen med applikationens mätningar.Resultatet visade mätskillnaderna mellan RPi 3 och oskilloskopet med systemet i viloläge. Resultatet av mätningarna visade att läsningen varierade med 66.20 µs och skrivandet med 56.20 µs. Fördröjningstestet utfördes medstresstestning och visade den värsta uppmätta fördröjningen, resultatet blev82 µs.De resulterande mätskillnaderna blev dock för höga för projektets krav. Majoriteten av mätningarna var mycket mindre än de värsta fallen med 23.52 µs för läsning och 34.05 µs för skrivning. Detta innebar att systemet kan användas med bättre precision som ett fast realtidssystem istället för ett hårt realtidssystem.

This paper addresses the question formulation “Is it possible to implement automated testing in an existing client-server game in order to pinpoint faults and achieve credibility to tests?” The gaming industry’s goal, in most cases, is to release games that appeal to both their financial goals and the enjoyment factor of the players. In order to fulfill these goals, the game will need to function properly and the process to assure this is testing the game to find possible faults. This process is time and cost consuming in an exponential rate in accordance to game extensiveness, which makes this problem a very important decision in the process of development. The problem is most commonly tackled by using massive manual testing session, called alpha or beta sessions. In these session the game is at an early stage of development and gets released to a set player base to test and report issues encountered. We believe that the process of testing games could be more effective by utilizing automated testing. This thesis will investigate the possibilities to our claim. The result is a visual representation of the tests we managed to apply, while focusing on the client-server connectivity of Quake 3 and a graph of measurements for our improvised fault localization. This paper describes a solution in form of automated tests within a existing client-server game and a start to what could be early stages of a pattern obtained throughout this project.

Rapporten har som mål att skapa en fördjupad förståelse kring utvecklingsmetoder, tester och automatisering inom programvaruutveckling. Innehållet i rapporten berättar vad som påverkar valet av dessa samt går igenom de teoretiska grunderna i en omfattande teoridel. Rapporten tar också upp hur valet av utvecklingsmetod påverkar möjligheten till att testa och automatisera ett projekt. Förutom den grundliga teoretiska delen finns det intervjuer med personer och företag som är insatta inom ämnet. Huvudfrågan har varit hur deras organisation anpassar utvecklingsmetoderna, testerna och automatiseringen till de olika projekt de jobbar med. För de tre första intervjuerna finns det en mer ingående analys av arbetssätt samt förslag till förbättringar. I slutsatserna har skribenterna gjort en bedömning huruvida dessa olika faktorer påverkar varandra och vad som bör tänkas på vid val av utvecklingsmetod, tester och automatisering.

Automating test processes is becoming more and more up-to-date and one of the reasons is that manual tests are time-consuming and complicated. The aim of the study is to identify the manual test process in integration systems to see if there can be a value in automating them and which requirements can then form the basis of an automation. Pros and cons of both manual and automated tests are highlighted in the study in order to make a fair comparison between them. The advantages of the automation that has been highlighted have since, together with collected empirical data at the company Pulsen Integration, been used to produce a requirement list for automation. The study addresses whether it is worth automating all processes or whether some of the test activities work better as manual. By looking at Pulsen Integration's testing processes, one could see that some flexible processes are better as manual, while more general activities can be more easily automated. The study has had a qualitative approach and the chosen respondents from Pulsen Integration contributed with information to be able to produce a relevant list of requirements. We believe that the result presented can be generalized to companies in similar context.