No description available.

O desenvolvimento de versões móveis de sistemas corporativos que já executam em plataformas Desktop e/ou Web tem se tornado comum. No entanto, o processo de migração tanto da lógica de programação quanto dos testes pode ser bastante complexo, embora muitas funcionalidades permaneçam as mesmas no novo ambiente. Este trabalho propõe o reúso de cenários de teste automatizados como uma alternativa para diminuir este esforço de migração. Para isso, propõe-se uma metodologia para o reúso de cenários de teste suportada por um framework de automação de testes. A metodologia propõe que cenários BDD sejam escritos uma única vez e executados em diferentes plataformas, como Desktop, Web, Móvel ou outra que venha a existir. Para dar suporte à metodologia proposta, o framework dbehave foi estendido para permitir a execução de cenários de teste em plataformas móveis. Uma segunda extensão no framework permite ainda que cenários específicos de uma plataforma possam ser escritos junto aos demais cenários mas executados apenas na plataforma de interesse, permitindo ao desenvolvedor uma maior autonomia na organização e manutenção dos cenários. A metodologia proposta foi utilizada em dois estudos de caso e se mostrou útil, uma vez que uma média de 81.2% dos cenários de aplicações reais foram reutilizados, havendo uma redução considerável no esforço de migração entre plataformas e na escrita de cenários. / The development of enterprise applications in multiple platforms (Desktop and/or Web and/or Mobile) has become a trend. However, the process of migrating both programming logic and software tests can be very complex, although many functionalities remain the same in the new environment. This work proposes the reuse of automated test scenarios as an alternative to reduce this migration effort. We propose a test methodology that is supported by a test automation framework. The methodology proposes the developer writes BDD scenarios only once and executes such scenarios on different platforms, such as Desktop, Web, Mobile or other that may exist. The dbehave framework was extended to support the execution of test scenarios in mobile platforms. Furthermore, the framework now allows the selection of which scenarios should be executed in which platforms, i.e., platform-specific scenarios can be written next to the other scenarios and run only on the platform of interest. This provides the developer greater autonomy in the organization and maintenance of the scenarios. The proposed methodology was used in two case studies and proved useful, since an average of 81.2% of the real application scenarios were reused, with a considerable reduction in the effort for cross-platform migration and scenario writing.

Current national dietary policy recommends that half, or three, of the six daily servings of grain foods be consumed as whole grains. However, most American children prefer to consume enriched, refined over whole grains. One way of increasing the consumption of whole grain foods to children is through school meals. Why children and adolescents prefer enriched, refined grains over whole grain foods is thought to be due to product color and texture, but no literature exists that quantifies this, especially within the context of the National School Lunch Program. Information and research is therefore needed to examine and address this issue. Since each school district's child nutrition department determines whether whole grain foods are offered in their schools, we conducted a roundtable discussion with Texas school dietitians to understand their experiences with providing whole grains. A phenomenological analysis of this discussion's transcript exposed how Texas school dietitians balance serving nutritious meals in their cafeterias, while maintaining customer acceptance of the foods. Whether or not students consume whole grains determines if these foods are served again. Input from participants determined which whole grain were foods tested in this study: hamburger buns, sandwich bread, tortillas and spaghetti. Focus groups were conducted with 137 elementary, middle and high school students in our targeted school district. Transcripts of these focus groups revealed the vocabulary students use to characterize their perceptions of whole grain foods tested. Using this vocabulary, consumer acceptance ballots were then developed and tested. Consumer acceptance testing of whole grain foods was conducted during scheduled lunch periods in three different schools. The main objective of this study was to determine at what percent do whole grains contained in grain foods served in school meals become unacceptable to students. Our study determined that a 51% whole grain food product was acceptable to students and a 100% whole grain product was not. Color, taste and texture of a whole grain food can influence its acceptance by these students, but that acceptance is dependent on the percent whole grain content of the food and whether it is made with white or red whole wheat flour.

O desenvolvimento de versões móveis de sistemas corporativos que já executam em plataformas Desktop e/ou Web tem se tornado comum. No entanto, o processo de migração tanto da lógica de programação quanto dos testes pode ser bastante complexo, embora muitas funcionalidades permaneçam as mesmas no novo ambiente. Este trabalho propõe o reúso de cenários de teste automatizados como uma alternativa para diminuir este esforço de migração. Para isso, propõe-se uma metodologia para o reúso de cenários de teste suportada por um framework de automação de testes. A metodologia propõe que cenários BDD sejam escritos uma única vez e executados em diferentes plataformas, como Desktop, Web, Móvel ou outra que venha a existir. Para dar suporte à metodologia proposta, o framework dbehave foi estendido para permitir a execução de cenários de teste em plataformas móveis. Uma segunda extensão no framework permite ainda que cenários específicos de uma plataforma possam ser escritos junto aos demais cenários mas executados apenas na plataforma de interesse, permitindo ao desenvolvedor uma maior autonomia na organização e manutenção dos cenários. A metodologia proposta foi utilizada em dois estudos de caso e se mostrou útil, uma vez que uma média de 81.2% dos cenários de aplicações reais foram reutilizados, havendo uma redução considerável no esforço de migração entre plataformas e na escrita de cenários. / The development of enterprise applications in multiple platforms (Desktop and/or Web and/or Mobile) has become a trend. However, the process of migrating both programming logic and software tests can be very complex, although many functionalities remain the same in the new environment. This work proposes the reuse of automated test scenarios as an alternative to reduce this migration effort. We propose a test methodology that is supported by a test automation framework. The methodology proposes the developer writes BDD scenarios only once and executes such scenarios on different platforms, such as Desktop, Web, Mobile or other that may exist. The dbehave framework was extended to support the execution of test scenarios in mobile platforms. Furthermore, the framework now allows the selection of which scenarios should be executed in which platforms, i.e., platform-specific scenarios can be written next to the other scenarios and run only on the platform of interest. This provides the developer greater autonomy in the organization and maintenance of the scenarios. The proposed methodology was used in two case studies and proved useful, since an average of 81.2% of the real application scenarios were reused, with a considerable reduction in the effort for cross-platform migration and scenario writing.

Automated acceptance testing is the testing of software done in higher level to test whether the system abides by the requirements desired by the business clients by the use of piece of script other than the software itself. This project is a study of the feasibility of acceptance tests written in Behavior Driven Development principle. The project includes an implementation part where automated accep- tance testing is written for Touch-point web application developed by Dewire (a software consultant company) for Telia (a telecom company) from the require- ments received from the customer (Telia). The automated acceptance testing is in Cucumber-Selenium framework which enforces Behavior Driven Development principles. The purpose of the implementation is to verify the practicability of this style of acceptance testing. From the completion of implementation, it was concluded that all the requirements from customer in real world can be converted into executable specifications and the process was not at all time-consuming or difficult for a low-experienced programmer like the author itself. The project also includes survey to measure the learnability and understandability of Gherkin- the language that Cucumber understands. The survey consist of some Gherkin exam- ples followed with questions that include making changes to the Gherkin exam- ples. Survey had 3 parts: first being easy, second medium and third most difficult. Survey also had a linear scale from 1 to 5 to rate the difficulty level for each part of the survey. 1 stood for very easy and 5 for very difficult. Time when the partic- ipants began the survey was also taken in order to calculate the total time taken by the participants to learn and answer the questions. Survey was taken by 18 of the employers of Dewire who had primary working role as one of the programmer, tester and project manager. In the result, tester and project manager were grouped as non-programmer. The survey concluded that it is very easy and quick to learn Gherkin. While the participants rated Gherkin as very easy.

Context: Acceptance testing is an important activity that verifies the conformance of a system to its acceptance criteria. It aims to provide a detailed communication of domain knowledge and is used to evaluate whether the customer requirements are met. Existing literature lacks empirical evidence for acceptance testing. Especially in the context of industry practice, it is not in the authors' consideration, except for a few studies, where the authors have investigated the state of practice in a specific domain. Objective: This study aims to recognize the state of research and practice of acceptance testing in Agile Software Development and investigate the similarities and differences in both perspectives. The study contributes to identify the industry-academia gap in the context of acceptance testing. Research Method: To identify the acceptance testing practices and challenges from research, I have conducted a literature review. For the industry perspective on acceptance testing practices and challenges, I have conducted an interview-based survey of the practitioners working in the Agile Software Development environment. I followed the snowball search strategy to search the primary studies, whereas to select the respondents, I used the convenience and snowball sampling method. For data analysis, I followed the approach of thematic synthesis. Results: The results of this thesis are the outcome of a literature review of 20 selected studies and an interview-based survey with 12 practitioners representing10 companies. I identified acceptance testing practices and challenges from research and industry. In the research, the most recommended form of acceptance testing is acceptance test-driven development (ATDD), and the majority of the studies are referring to the use of FIT for acceptance testing. Customer involvement in different phases of acceptance testing is recommended in research. From the interviews, I come across that acceptance testing is manual at large in the industry, and the most challenging aspect is the customer’s involvement. Conclusions: From the findings of this thesis, it is concluded that there is a gap between the research and industry perspective of acceptance testing practices. Currently, acceptance testing in the industry is mostly manual, the research is not focusing on this aspect of acceptance testing. Despite the differences, there are some commonalities as well. Especially, most challenges of acceptance testing are similar in both perspectives. Researchers have to consider the commonalities, and they have to look at how they can minimize the acceptance testing challenges from the perspective of the industry.

The field of software engineering consists of complex processes to deliver valuableand useful software to end users. Requirements discovery and software testing hasevolved significantly over the last decades with an increased focus on agility anddelivering customer value. Behavior-Driven Development (BDD), an extension ofTest-Driven Development, is a test-first requirements collection and acceptance test-ing framework. Despite a high practitioner interest within the industry, there arecurrently only a limited number of studies within academia available on the feasibilityof BDD. The aim of this thesis is to investigate the impact of BDD on software qualityand stakeholder collaboration. This is done by studying a quality assurance teamconsisting of management and development resources as BDD activities are practicedin the development of a new application. Semi-structured interviews are then heldwith participants to identify perceived and expected benefits as well as identifiedchallenges throughout the process. Responses are finally collected and coded into athematic map from which conclusions are drawn and discussed. As we have found in our study, many practical and organizational aspects areraised when BDD is implemented. Benefits include increased team collaboration,team alignment, and software quality. Challenges include management and teammotivation issues, increased workload, loss of productivity, BDD benefit visibilityissues, and the need for experience to be able to implement BDD successfully.

I nuläget utförs acceptanstester på Trafikverket utan att veta testprocessens styrkor och svagheter. Denna fallstudie tar genom Test Maturity Model (TMM) fram en mognadsgrad för testprocessen inom acceptanstester. Mognadsgraden visar hur processen ligger till i nuläget och visar testprocessens svagheter och styrkor. Den mognadsgrad som påträffades vid en utvärdering av acceptanstester inom ProjectWise var mognadsgrad tre. Förbättringsförslagen som presenterades var att utföra kontinuerliga workshops i utbildningssyfte så att inte kunskaperna inom testområdet stagnerar och att kvantifiera kvalitetsfaktorer för mätning av tester. Dock är ingen modell fullkomlig. Genom metodanalysen MA/SIMM (Metod Analys och SIMM står för Samverkan & Situationsanpassning, Ifrågasättande & Idéutveckling, Meningsskapande & Målstyrning och Metodisk & Metod) så visar vi modellens styrkor och svagheter. Några svagheter i TMM modellen är att det inte krävs en erfaren utvärderare av kriterierna. Kriterierna besvaras med frågor och enkäter som kan misstolkas. Svaren i frågeformulären är fördefinierade vilket kan begränsa respondenten, eller göra den osäker på vilket alternativ som passar bäst. Dessa svagheter kan i slutändan påverka mognadsgraden. Några fördelar är att det finns väl dokumenterade riktlinjer när utvärderingen pågår, så att det går att komma in som student och ändå kunna utöva denna modell godtyckligt. Den största styrkan är att TMM baseras på en vetenskaplig grund. Den har även baserats på 40 år av erfarenhet av test i från verksamheten, vilket gör den till en välgrundad modell som kan ge väl motiverade förbättringsförslag. / Currently at Trafikverket acceptance testing is done without knowing the test process strengths and weaknesses. This case-study uses Test Maturity Model (TMM) to identify a maturity level for the test process in acceptance testing. The maturity level show how the current process operate and present the test process current weaknesses and strengths. Acceptance testing within ProjectWise reached a maturity level of three. The improvement proposals were to perform continuous workshops for education purposes, so the knowledge within the testing area does not stagnate, and to quantify quality factors for measurement of test. Though no model is perfect this study will attempt to do a method analysis based on MA/SIMM, to show the strengths and weaknesses. Some of the weaknesses are the lack of experience within the use of the criterias of the TMM model. The criterias are fulfilled by interviews and questionnaires and can be misinterpreted. The answers in the questionnaires are predefined and may confuse the respondent. These weaknesses may eventually cause the wrong maturity level being set. There are well documented guidelines when the TMM process has begun so even a inexperienced student may perform a TMM evaluation. The greatest strength in TMM is that it has a scientific background, combined with 40 years of experience within the testing industry, makes it a well-founded model with trustworthy improvement proposals.

Auddly provides a music management tool that gathers all information about a musical piece in oneplace. The acceptance testing on their web application is done manually, which has become bothtime and money consuming. To solve this problem, an evaluation on automated acceptance testingwas done to find a testing tool suitable for their web application. The evaluation was performed byfinding the current existing testing strategies to later compare the tools implementing these strategies.When analyzing the results it was found that two testing strategies were best suited for automatedacceptance testing. The Visual Recognition strategy that identifies components using screenshotsand the Record and Replay strategy that identifies them by their underlying ID. The choice betweenthem depends on which of these properties are modified more often.It was also found that automating acceptance testing is best applied for regression testing, otherwiseit should be performed with a manual approach.It was made clear that the Selenium tool, which uses the Record and Replay strategy, was best suitedfor Auddly’s acceptance testing. Selenium is able to test AJAX-calls with a manual modificationand is a free and open source tool with a large community. / Auddly tillhandahåller ett musikverktyg som samlar all information om ett musikstycke på ett endaställe. Acceptanstestningen på deras webbapplikation sker manuellt, som både blir tidskrävande ochdyrt. För att lösa detta problem har en utvärdering av automatiserade acceptanstestverktyg genomförtsför att hitta det verktyg som passar deras webbapplikation bäst. Utvärderingen utfördesgenom att hitta existerande teststrategier för att sedan jämföra de verktyg som implementerar dessastrategier.I analysen av resultatet framkom det att två av strategierna var mest passande för automatiseradeacceptanstester. Strategin Visual Recognition som identifierar komponenter genom skärmdumparoch strategin Record and Replay som identifierar de via deras underliggande ID. Valet mellan demberor på vilka av dessa egenskaper som ändras oftare.Det framkom även att automatisering av acceptanstester är mest lämpligt i regressionstestning, iandra typer av testning bör det ske manuellt.Det klargjordes att verktyget Selenium, som använder strategin Record and Replay, var det bästpassande för Auddly’s acceptanstestning. Selenium kan testa AJAX-anrop med en manuell modifieringoch är ett gratis verktyg med öppen källkod samt ett stort forum.

In der Leit- und Sicherungstechnik sollen die Bauausführung und Abnahmeprüfung deutlich beschleunigt und wegen des Fachkräftemangels auch ressourcenschonender durchgeführt werden. Es wird eine Methodik zur Optimierung und Teilautomatisierung dieser Aufgabenstellungen vorgestellt. Nach Darlegung der aktuellen Herausforderungen wird ein IT-gestütztes Verfahren beschrieben, welches neben der Ablaufbeschleunigung auch die Automatisierung der Daten- und der Qualitätssicherung verwirklicht. Ferner werden ergänzende Werkzeuge inklusive ihrer Mindestanforderungen vorgestellt, mit welchen die datenbankgestützte Sicherung der Ergebnisse und deren Bereitstellung für nachfolgende Arbeitsschritte ermöglicht wird. Die Datenbanklösung ist Grundlage für eine durchgängige, digitale Datenhaltung während der gesamten Projektumsetzung. Abschließend wird eine Sicherheits- und Zuverlässigkeitsbewertung durchgeführt und es werden Vorschläge zur Systemeinführung gegeben.:1 Einleitung 11 1.1 Motivation 11 1.2 Handlungsbedarf 11 1.3 Zielstellung 13 1.4 Methodik und Struktur 14 1.4.1 Methodische Herangehensweise 14 1.4.2 Struktur der vorliegenden Arbeit 15 2 Definition des Betrachtungsumfangs 16 2.1 Ausgangspunkt der Betrachtungen 16 2.1.1 Grundlagen für LST-Planungen 18 2.1.2 Ergebnisse der digitalen Planung 19 2.1.3 Grundlagen für die Signalbauindustrie 20 2.1.4 Grundlagen der Bauüberwachung und Abnahmeprüfung 20 2.2 Bearbeitungsschwerpunkte 21 2.2.1 Innenanlage von LST-Projekten 21 2.2.2 Außenanlage von LST-Projekten..21 2.2.3 Ressourcenbedarf bei LST-Projekten 24 2.3 Projektaufträge und Arbeitskreise 26 2.3.1 Vorstandsauftrag der DB Netz AG vom 28.07.2015 26 2.3.2 Beschleunigung von Abnahmeprozessen der Stellwerkstechnik 27 2.3.3 Expertennetzwerk Projektrealisierung STE .28 2.4 Betrachtungsbereich der vorliegenden Arbeit 28 2.5 Zusammenfassung 30 3 Analyse der Bauausführung von LST-Projekten 32 3.1 Umsetzung von LST-Projekten bei ausgewählten Eisenbahninfrastrukturunternehmen (EIU) 33 3.2 Vorgaben für die Projektumsetzung bei der SBB 34 3.3 Vorgaben für die Projektumsetzung bei der ÖBB 35 3.4 Vorgaben für die Projektumsetzung bei der DB AG 37 3.4.1 Prozesse zur Bauausführung bei der DB AG 37 3.4.2 Regelwerk zur Bauausführung bei der DB AG 40 3.4.3 Fazit der Betrachtung Prozesse und Regelwerk der DB AG 42 3.5 Zusammenfassung 43 4 Teilautomatisierung der Abnahmeprüfung 45 4.1 Betrachtungsbereich und Schnittstellen 45 4.1.1 Einführung 45 4.1.2 Eurobalise - Verwendete Begriffe und Abkürzungen 45 4.1.3 Vertiefter Betrachtungsbereich 48 4.2 Grundlagen Bauausführung 49 4.2.1 Vorschlag für ein Prüf- und Dokumentationsblatt Balise 49 4.2.2 Differenzierung Prüfungen aus dem Merkblatt Eurobalise S21 52 4.2.3 Generierung der Arbeitsinformationen Balise 56 4.2.4 Unverwechselbarkeitskennzeichnung der Balisen 59 4.2.5 Übernahme Daten aus der digitalen Planung 65 4.2.6 Anforderungen an eine LST Datenbank. 67 4.2.7 Architektur der LST-Datenbank 69 4.2.8 Synchronisierung des Baufortschritts über die LST-Datenbank. 72 4.2.9 Positionsbestimmung des Einbauortes der Balisen 73 4.3 Leistungsanteile bei der Signalbauindustrie 77 4.3.1 Materialisierung von Bauteilen und Komponenten 77 4.3.2 Projektierung der Balise durch die Signalbauindustrie 79 4.3.3 Programmierung Balise durch die Signalbauindustrie.81 4.3.4 Montage der Balise durch die Signalbauindustrie .85 4.4 Bauüberwachung 90 4.5 Abnahmeprüfung durch den Prüfsachverständigen .92 4.6 Übernahme Anlage durch Anlageverantwortlichen .98 4.7 Qualifikation der einzusetzenden Mitarbeiter 99 4.8 Zusammenfassung 101 5 Auswirkungsbewertungen . 105 5.1 Auswirkungen auf vorhandene Richtlinien und Prozesse . 105 5.1.1 Datenpunkttabelle 1 der Ril 819.1344 [RIL819e] 105 5.1.2 Arbeitsinformationen Balise 105 5.1.3 Prüf- und Dokumentationsblatt Balise .. 106 5.1.4 Auswirkungen auf vorhandene Prozesse ... 106 5.2 Auswirkungen auf genutzte Programme ... 106 5.2.1 Digitale Bearbeitungsblätter Balise .... 107 5.2.2 Ergänzung der DiAapp .... 111 5.2.3 Anforderungen an das Datenbanksystem ... 111 5.3 Auswirkungen auf die Sicherheit .. 112 5.3.1 Allgemeines .... 112 5.3.2 Sicherheitsbetrachtungen .112 5.3.3 Zuverlässigkeitsbetrachtungen ... 117 5.3.4 Datenschutz und Datensicherheit . 118 5.4 Auswirkungen auf die Effizienz .... 119 5.4.1 Teilautomatisierung Materialisierung durch SBI .. 119 5.4.2 Archivierung von Datentelegrammen im DBS .... 119 5.4.3 Arbeitsinformationen Balise ..... 119 5.4.4 Digitale Bearbeitungsblätter Balise .... 120 5.4.5 Datenbereitstellung für Instandhaltungssteuerung .... 120 5.4.6 Prognose Effekte durch Teilautomatisierung .. 120 5.5 Zusammenfassung .. 123 6 Umsetzungsplanung ... 124 6.1 Praxistest der Forschungsergebnisse ... 124 6.1.1 Auswahlkriterien für einen Praxistest 125 6.1.2 Organisatorische Voraussetzungen 125 6.1.3 Technische Voraussetzungen . 128 6.1.4 Qualifikation der Projektbeteiligten ... 129 6.2 Umsetzung in der Bauausführung und Abnahmeprüfung . 130 6.2.1 Veränderte Vorgaben an die Signalbauindustrie ... 130 6.2.2 Anpassungen der Vorgaben an die Bauüberwachung ... 131 6.2.3 Anpassung der Vorgaben für die Abnahmeprüfung ..... 133 6.3 Zusammenfassung .......134 7 Schlussbetrachtungen und Ausblick ... 135 Abkürzungsverzeichnis... 142 Abbildungsverzeichnis .. 146 Tabellenverzeichnis .. 148 Literaturverzeichnis ..... 150 Glossar .... 159 Anhang: Vorbemerkungen ... 161 Anhang A: Zusammenfassung der Voraussetzungen der Abnahmeprüfung 162 Anhang B: Vorgaben an die Bauüberwachung 163 Anhang C: Vorgaben an die Abnahmeprüfung 164 Anhang D: Analyse von Mängellisten aus Abnahmeprüfungen 165 Anhang E: Differenzierung Merkblatt Eurobalise S21 69 Anhang F: Arbeitsinformationen (AI) Eurobalise S21 174 Anhang G: Digitale Bearbeitungsblätter (DBB) Balise 182 Anhang H: Anforderungen an ein Georeferenzsystem für LST 189 Anhang I: Datenpunkttabelle 1 mit Ergänzungen 192 Anhang J: Teilautomatisierungen bei der Signalbauindustrie 193 Anhang K: Positionsbestimmung in der LST 194 Anhang L: Strukturierte Interviews und Expertengespräche 198