To test software over a remote desktop is an increasingly common practice since outsourcing and offshoring of testing activities are on the rise. Most companies useproprietary testing tools which require an agent to be installed on the remote machine.This installation opens several attack surfaces and has thus the potential to compromise security. In addition license, support and other proprietary test tool costs might reduce the return on investment of automated tests to an unprofitable level, especially for relatively short projects.Robot Framework with Sikuli integration (RFSI) is a concept based on two open source tools which offer solutions concerning the security and cost issues. RFSI based tests do not need any further installations, access rights or network configurations on the remote machine, because of the fact that the tests are based on visual input. Therefore tests with RFSI cannot access the AUT (Application Under Test) or the remote machine in any other way than a manual tester could. Open-source tools, being freely available, also escape the problem of licence costs. The purpose of the proof of concept pilot study wasto give an answer on the question if RFSI can furthermore be considered an alternative to proprietary tools in terms of requirements for tool quality characteristics and for the external context of test automation projects.The methodology of this research followed the broader Goal-Question-Metrics method(GQM) described by Rini van Solingen and Egon Berghout, based on the GQM approachby Victor Basili and David Weiss. The requirements and metrics for the evaluation of RFSI in the study were selected through a literature study of ISO/IEC-TR9126-3 and other articles in the field. They comprehend six categories: functionality, reliability,maintainability and stability, efficiency, understandability and portability. For each category,metrics were established and adapted to the context of the proof of concept. The scope of the project was given by six use cases and test specifications, established in cooperation with system experts at the company CGI Sundsvall. These were then translated into RFSI test scripts and implemented with the requirements for successful remote GUI testing in mind.The results of the measurements for the proof of concept study showed that RFSI fulfilles the internal and external requirements for successful automated testing completely for functionality, understandability and portability. The requirements are partially satisfiedfor reliability, maintainability and stability, and efficiency.In conclusion, RFSI satisfies enough requirements to be considered a viable alternative to commercial testing tools for tests of GUI (Graphical User Interface) desktop applications over a remote desktop.

This thesis deals with the methodology used for application testing, using the Robot Framework. Its main objective is to develop a methodology which describes an approach to automated testing using this tool. An important part of the methodology is to design a user guide for the Robot Framework - at the time of writing this thesis assignment, this guide does not exist in the Czech language. In this thesis the basic concepts and approaches to automation testing in accordance with defined objectives are explained. An integral part of this is the description of the Robot Framework, its architecture and tools used, libraries, other built-in tools and the syntax used for creating test cases.

Software testing is widely considered to be one of the most important parts of software development life-cycle. In this research, we investigated potential improvements in the testing process and design of automated test scripts inside Bombardier Transportation. For the creation of automated test scripts BT is using a group of programs called TAF (Test Automation Framework). These scripts are used for testing Train Control Management System (TCMS), software that is used for managing the train. TAF can export its test scripts in XML format. XML scripts are analyzed in order to identify the most frequent changes. To better understand the life cycle of automated Test scripts official documentation that defines the Verification and Validation process inside BT was analyzed. Also, an interview was conducted with one of the responsible persons for testing. We believe that we have found a possible solution for improving testing process and creation of automated test scripts in BT, and to evaluate it proof of concept tool was developed. The main idea behind the tool is to write the test script using keywords which are based on analysis that was conducted on test specification documentation. These keywords represent frequent actions that are being tested on the train. By storing those actions in keywords re-usability of test script is being increased. Also, because they are based on naturally language, they are having positive effect on readability and maintenance of the test script.

Saab want to examine Hardware In the Loop method as a concept, and how an infrastructure of Hardware In the Loop would look like. Hardware In the Loop is based upon continuously testing hardware, which is simulated. The software Saab wants to use for the Hardware In the Loop method is Jenkins, which is a Continuous Integration, and Continuous Delivery tool. To simulate the hardware, they want to examine the use of an Application Programming Interface between a Raspberry Pi, and the programming language Robot Framework. The reason Saab wants this examined, is because they believe that this method can improve the rate of testing, the quality of the tests, and thereby the quality of their products.The theory behind Hardware In the Loop, Continuous Integration, and Continuous Delivery will be explained in this thesis. The Hardware In the Loop method was implemented upon the Continuous Integration and Continuous Delivery tool Jenkins. An Application Programming Interface between the General Purpose Input/Output pins on a Raspberry Pi and Robot Framework, was developed. With these implementations done, the Hardware In the Loop method was successfully integrated, where a Raspberry Pi was used to simulate the hardware. / Saab vill undersöka metoden Hardware In the Loop som ett koncept, dessutom hur en infrastruktur av Hardware In the Loop skulle se ut. Hardware In the Loop baseras på att kontinuerligt testa hårdvara som är simulerad. Mjukvaran Saab vill använda sig av för Hardware In the Loop metoden är Jenkins, vilket är ett Continuous Integration och Continuous Delivery verktyg. För attsimulera hårdvaran vill Saab undersöka användningen av ett Application Programming Interface mellan en Raspberry Pi och programmeringsspråket Robot Framework. Anledning till att Saab vill undersöka allt det här, är för att de tror att det kan förbättra frekvensen av testning och kvaliteten av testning, vilket skulle leda till en förbättring av deras produkter. Teorin bakom Hardware In the Loop, Continuous Integration och Continuous Delivery kommer att förklaras i den här rapporten. Hardware In the Loop metoden blev implementerad med Continuous Integration och Continuous Delivery verktyget Jenkins. Ett Application Programming Interface mellan General Purpose Input/output pinnarna på en Raspberry Pi och Robot Framework blev utvecklat. Med de här implementationerna utförda, så blev Hardware Inthe Loop metoden slutligen integrerat, där Raspberry Pis användes för att simulera hårdvaran.