Behavior-Driven Development (BDD) is an emerging agile development approach where all stakeholders (including developers and customers) work together to write user stories in structured natural language to capture a software application's functionality in terms of re- quired "behaviors". Developers then manually write "glue" code so that these scenarios can be executed as software tests. This glue code represents individual steps within unit and acceptance test cases, and tools exist that automate the mapping from scenario descriptions to manually written code steps (typically using regular expressions). Instead of requiring programmers to write manual glue code, this thesis investigates a practical approach to con- vert natural language scenario descriptions into executable software tests fully automatically. To show feasibility, we developed a tool called Kirby that uses natural language processing techniques, code information extraction and probabilistic matching to automatically gener- ate executable software tests from structured English scenario descriptions. Kirby relieves the developer from the laborious work of writing code for the individual steps described in scenarios, so that both developers and customers can both focus on the scenarios as pure behavior descriptions (understandable to all, not just programmers). Results from assessing the performance and accuracy of this technique are presented. / Master of Science

Background: In current software development, agile development approaches are widely used. One of these methods is Test-driven development (TDD). TDD is said to be a perfect fit for development as it is highly collaborative and is said to improve productivity and accuracy in development. However, it is not a widely used process because people have different perceptions of TDD (mostly negative). In this study we will investigate the expectations about TDD and if these expectations are being met in practice and understand what makes TDD a not-so-usable process. Objectives: The objectives of this study include: To understand the expectations of practitioners about TDD. To investigate if the expectations for TDD are met in practice. To identify the factors that limit the use of TDD. Methods: We have performed a review of the state of the art, from where we have gathered the most common expectations about TDD. These expectations have been used in the survey to see if these expectations are met from the perspective of practitioners simultaneously, we have also conducted interviews. We have collected qualitative data and analyzed the data. Additionally, we have also conducted a sentiment analysis of Reddit comments. Results: From the survey and interviews, we found that the overall perception of TDD is positive and it can provide benefits in certain contexts, We also identified the factors like lack of knowledge or training, perceived difficulty, and resistance to change among others that limit the use of TDD in industry. In the sentiment analysis, we found that the overall sentiment of the comments is mostly neutral and some of them negative. Conclusions: In conclusion, from our study, we identified that TDD can provide benefits but organizations must be willing to invest the time and effort to train their people and see the results using TDD. There are examples of successful projects using TDD but it is not necessarily the best approach in all situations and should be used judiciously to match the specific needs of the project and the organization. Keywords: Agile, Software testing, Test Driven Development, Expectations, Limitations.

Test-driven development (TDD) has been the target of many articles in which the authors try to reveal the impact of TDD compared to the traditional iterative test-last approach (ITL). Most of the existing articles conducts case studies in academic setting or in industrial setting with focus on metrics of little relevance for the industry. The metrics Defect Density per 1000 lines of code (DD/KLOC) and McCabe’s cyclomatic complexity number are frequently used to show differences between ITL and TDD in quality. However, these metrics are outdated and irrelevant in today’s industry according to several articles regarding TDD. The reason is the introduction of high-level programming languages such as Java, C# and Python. To compare these languages with assembler languages is not feasible. In this master thesis, the author suggests measuring defect density per hour instead (DD/h) of per 1000 lines of code to establish the quality and success of a software project. DD/h together with total hours needed to develop the software is a better measurement and is not dependent on programming language and complexity as DD/KLOC is to describe quality and the scope of the development project. By examine DD/h from five case studies comparing ITL and TDD the author shows a possible positive change in quality and resources needed in software development projects. / Testdriven utveckling (TDD) har varit i fokus många artiklar där författarna försöker kartlägga TDD: s inverkan jämfört med det traditionella tillvägagångssättet där tester körs sist i utvecklingsprocessen (ITL). De flesta av de befintliga artiklarna genomför fallstudier i akademisk miljö eller i industriella miljöer med fokus på mätvärden som saknar relevans för industrin. Defektdensitet per 1000 linjer kod (DD/KLOC) och McCabes cyklomatiska komplexitetsnummer används ofta för att visa skillnader mellan ITL och TDD i kvalitet. Dessa mätvärden är emellertid föråldrade och irrelevanta i dagens bransch enligt flera akademiska artiklar. Anledningen är introduktionen av programmeringsspråk så som Java, C #och Python. Att jämföra dessa språk med assembler-språk är inte möjligt. I detta examensarbete föreslår författaren att man mäter defektendensitet per timme (DD/h) istället för DD/KLOC för att fastställa kvaliteten för ett mjukvaruprojekt. DD/h tillsammans med de totala timmar som behövs för att utveckla programvaran är ett bättre mätvärde och är inte beroende av programmeringsspråk och komplexitet som DD/KLOC är för att beskriva kvaliteten och omfattningen av utvecklingsprojektet. Genom att undersöka DD/h från fem fallstudier som jämför ITL och TDD visar författaren en möjlig positiv förändring av kvalitet och resurser som behövs för att genomföra ett mjukvaruutvecklingsprojekt.

WebIDE is a web-based online learning environment. WebIDE has been used successfully to teach CS0 and CS1 students Java and C concepts and software engineering best practices, specically Test Driven Development. Previous Web- IDE development has concentrated on developing functionality. The main goal of this eort is to improve two non-functional aspects of WebIDE. The rst is to design a more delightful user interface. The second is to add a scoring mecha- nism that encourages students to develop best practices. The scoring mechanism rewards students who answer the question correctly on the rst attempt, dis- couraging them from spamming the answer button. Our objective is to motivate the students to think before answering. The innovations are evaluated through a semi-controlled experiment that was conducted during the Fall quarter of 2012 at Cal Poly.

The usage of a graphical user interface (GUI) in software often make up for a greatexperience for the user and is often not an issue, until the only way to run a programis through a GUI. Such a dependency will make development of a project very hardas the only way to perform tests is to execute them manually. This is the case for asimulator that the company Creone uses and it is where we will perform our work.Creone works with smart key management systems and cabinets that allow for a safeand convenient way to store and handle keys. Registered users can open the cabinetswith a pin code that is entered on the dial on the cabinet door. Keys are assigned tousers and what keys that a user can take from a cabinet is seen on the display abovethe dialpad. We are to create a new core implementation that will remove the GUIdependency and allow the simulator to perform automated tests to some extent.

Effective software testing identifies potential bugs and helps correct them, producing more reliable and maintainable software. As software development processes have evolved, incremental testing techniques have grown in popularity, particularly with introduction of test-driven development (TDD). However, many programmers struggle to adopt TDD's "test a little, code a little" approach and conventional computer science classrooms neglect evaluating software development as a process. In response, we explore influences on students' testing behaviors, effects of incremental testing strategies, and describe approaches to help computer science students adopt good testing practices. First, to understand students' perspectives and adoption of testing strategies, we investigated their attitudes toward different aspects of TDD. In addition, we observed trends in when and how thoroughly students tested their code and how these choices impacted the quality of their assignments. However, with insight into why students struggle to adopt incremental testing, we identified a need to assess their behaviors during the software development process as a departure from traditional product-oriented evaluation. By building upon an existing automated grading system, we developed an adaptive feedback system to provide customized incentives to reinforce incremental testing behaviors while students solved programming assignments. We investigated how students react to concrete testing goals and hint reward mechanisms and found approaches for identifying testing behaviors and influencing short-term behavioral change. Moreover, we discovered how students incorporate automated feedback systems into their software development strategies. Finally, we compared testing strategies students exhibited through analyzing five years and thousands of snapshots of students' code during development. Even when accounting for factors such as procrastinating on assignments, we found that testing early and consistently maintaining testing throughout development helps produce better quality code and tests. By applying our findings of student software development behaviors to effective testing strategies and teaching techniques, we developed a framework for adaptively scaffolding feedback to empower students to critically reflect over their code and adopt incremental testing approaches. / Ph. D.

Currently published statistics focused on the area of software projects are very disturbing. It is alarming that, according to research company Standish Group only 32% of IT projects end successfully. The percentage of cancelled projects, 24%, is even more disturbing. The applied methodology should contribute to the increase success of the software engineering projects. Statistics show that the methodology applied in the work sphere, is currently used by more than 50% of firms. This work shows the development of specific software in a small IT company, which currently is not supported by any methodology of IS / ICT. The primary objective of this work is the evaluation of the methodology best suited to the needs of business presented. The first chapter of the theoretical part deals with the issues of software engineering and is focused mainly on the area of IT projects success rates and related critical factors of software engineering. The second chapter is then devoted to the history of software engineering and describes the important milestones leading to the development of the most well-known life cycle models and methodologies. The main part of the theoretical block is devoted to methodologies of IS / ICT. This passage is particularly concentrating on the meaning of methodologies in the management of development projects. It also focuses on comparing agile and rigorous methodologies and deals with the assessment of appropriate methodologies for the development of IS / ICT in small businesses. The first part of the practical unit focuses on the introduction of the presented company. The following chapters are devoted to analyzing the current state of software engineering of the client, leading to the detection of the major problems of current development. The analysis is followed by chapter, which is devoted to the presentation of five agile methodologies which were selected on the basis of criteria based on client's specific requirements and needs. The final part is devoted to the evaluation of methodologies based on meeting the given criteria and according to the level of support solutions to the problems analyzed. Based on the resulting findings the client is recommended specific methodology and the appropriate procedure outlined in the implementation of the chosen methodology.

<p>Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas.</p><p>Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.</p>

Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas. Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.

[pt] Nesse trabalho foi criado um framework para a realização de testes automatizados de acordo com as práticas de desenvolvimento dirigido por testes, o qual pode ser estendido com novas linguagens de especificação, utilizando idéias de desenvolvimento dirigido por comportamentos. Espera-se que, ao utilizar esse framework, equipes de projetos de software possam especificar testes em uma linguagem mais adequada para o domínio de sua aplicação, através do suporte de uma ferramenta que permita tal nível de personalização. O framework foi instanciado com a criação de uma linguagem baseada em máquinas de estado, utilizada para a aplicação da ferramenta em um projeto real. O objetivo deste trabalho é avaliar os impactos da aplicação dessas técnicas, através da experiência de utilização da ferramenta no projeto. A motivação para esse trabalho surgiu da experiência no desenvolvimento de sistemas de controle, usualmente reativos e com requisitos de tempo real, nos quais muitas vezes a descrição de seus comportamentos é feita através de máquinas de estado, que possivelmente é a melhor linguagem para este domínio. / [en] In this work we create a framework for automated testing according to test driven development practices that can be extended to support new specification languages, following ideas from behavior driven development. We expect that, by using this framework, software development teams will be able to specify tests in more proper languages for the application domain, with the support of a tool that allows such level of customization. The framework was instantiated with the creation of a language based on state machines, and used on a real-life project. The goal of this work is that software project teams become able to specify tests in the most fitting language for their application domain, through the support of a tool that makes possible such level of customization. The motivation for this work comes from the experience with the development of control systems, usually with real-time requirements, which often have their behaviors described by state machines, possibly the best language for this domain.