Context: In recent times, many organizations have started using agile software development methodologies instead of using traditional methodologies. The main reason for this shift is the ability of agile approaches to cope with changes in the requirements, customer satisfaction and assurance of on-time delivery of quality products [19]. Test-Driven Development (TDD) is a software development methodology that is considered to be one of the most prominent practices of eXtreme Programming (XP) (an agile methodology) [1][9][10]. Test-list in TDD is considered as a temporary repository in which test items are stored and later by using those items test cases are developed. Requirements Traceability is also a major problem in agile development mainly because of lack of formal requirements specification and frequent requirements change. Objectives: This study explores the utilization of test-list and possibility of using test-list for requirements traceability in TDD. This study describes concept of test-list, its formation and exploring its utilization in TDD. Methods for implementing requirements traceability in and identification of possibility of utilizing test-list for requirements traceability in TDD is also explored. Methods: Methods used in this study are systematic literature review, surveys and interviews. Systematic literature review was done using seven electronic databases, including Inspec, IEEE Xplore, ACM Digital Library, Springer, Science Direct and Scopus. Studies were selected on the bases of preliminary, basic and advanced developed criteria. Survey was conducted using online questionnaire from TDD practitioners. Findings from literature review and surveys were used to develop interview questionnaires. Interviews were conducted from the same practitioners that were involved in surveys. Results: Based on the findings of literature review, questionnaire and interviews, we obtained TDD practices for test-list development and requirements traceability. Analysis was performed on results of SLR and questionnaire and possibility of using test-list for requirements traceability was identified. Based on the analysis of literature review and surveys, interview questionnaire were developed to further investigate the area of interest. We have found that in literature there is no defined method to develop test-list. and survey participants also confirms it. Majority of survey participants create test-list temporarily and informal. On question of whether test-list can be use for requirements traceability around 70% of participants are agree for its use. Interview respondents also confirm the findings of survey. Conclusions: Literature has not provided any test-list development method and practitioners also have no clear guideline to develop test-list prior to Test development. Systematic literature review and practitioner’s survey and interviews confirm it. Literature is also silent for any specific requirements change management or requirements traceability method in TDD. We identified requirements traceability practices in agile and management through literature and survey. After analysis of gathered data we found TDD lacks in test-list formalization, none of the study focuses on requirements traceability in TDD. In this study our contribution is exploration of test-list creation and utilization through literature and state of the practice; after practitioners feedback we also explored that test-list can be used for requirements traceability. / hasmkh@gmail.com, ibrararshad@gmail.com

Context: Test-Driven development (TDD) is a software development approach where test cases are written before actual development of the code in iterative cycles. TDD has gained attention of many software practitioners during the last decade since it has suggested several benefits in the software development process. However, empirical evidence of its dominance in terms of internal code quality, external code quality and productivity is fairly limited. Objectives: The aim behind conducting this study is to explore what has been achieved so far in the field of Test-driven development. The study reports the benefits and limitation of TDD compared to TLD and the outcome variables in all the reported studies along with their measurement criteria. Additionally, an experiment is conducted to see the impact of Test-driven development (TDD) on internal code quality, external code quality and productivity compared to Test-Last development (TLD). Methods: In this study two research methodologies are used specifically systematic literature review according to Kitchenham guidelines and controlled pilot experiment. In systematic literature review number of article sources are considered and used, including Inspec, Compendex, ACM, IEEE Xplore, Science direct (Elsevier) and ISI web of science. A review protocol is created first to ensure the objectivity and repeatability of the whole process. Second, a controlled experiment is conducted with professional software developers to explore the assumed benefits of Test-Driven development (TDD) compared to Test-Last development (TLD). Results: 9 distinct categories related to Test-driven development (TDD) are found that are investigated and reported in the literature. All the reported experiments revealing very little or no difference in internal code quality, external code quality and productivity in Test-Driven development (TDD) over Test-Last development (TLD). However, results were found contradictory when research methods are taken into account because case studies tend to find more positive results in the favor Test-Driven development (TDD) compared to experiments possibly due to the fact that experiment are mostly conducted in artificially created software development environment and mostly with students as a test subjects. On the other hand, experimental results and statistical analysis show no statistically significant result in the favor TDD compared to TLD. All the values found related to number of acceptance test cases passed (Mann-Whitney U test Exact Sig. 0.185), McCabe’s Cyclomatic complexity (Mann-Whitney U test Exact Sig. 0.063), Branch coverage (Mann-Whitney U test Exact Sig. 0.212), Productivity in terms of number of lines of code per person hours (Independent sample Ttest Sig. 0.686), productivity in terms number of user stories implemented per person hours (Independent sample T-test Sig. 0.835) in experiment are statistically insignificant. However, static code analysis (Independent sample T-test Sig. 0.03) result was found statistically significant but due to the low statistical power of test it was not possible to reject the null hypothesis. The results of the survey revealed that the majority of developers in the experiment prefer TLD over TDD, given the lesser required level of learning curve as well as the minimum effort needed to understand and employ TLD compared to TDD Conclusion: Systematic literature review confirms that the reported benefits of TDD development compared to Test-Last development are very small. However, case studies tend to find more positive results in the favor of Test-Driven development (TDD) compared to Test-Last development (TLD). Similarly, experimental findings are also confirming the fact that TDD has small benefits over TLD. However, given the small effect size there is an indication that (Test-Driven development) TDD endorses less complex code compared to Test-Last development (TLD). / Systematic literature review confirms that the reported benefits of TDD development compared to Test-Last development are very small. However, case studies tend to find more positive results in the favor of Test-Driven development (TDD) compared to Test-Last development (TLD). Similarly, experimental findings are also confirming the fact that TDD has small benefits over TLD. However, given the small effect size there is an indication that (Test-Driven development) TDD endorses less complex code compared to Test-Last development (TLD). / hassanmunirr@hotmail.com, mm1844@gmail.com

The emerging industrial trend towards agile software development processes brings forth new concerns, challenges as well as opportunities. One of the main concerns is with respect to the achievable quality levels of the final product, for which testing is the well-known assurance mechanism. However, it is not well defined for the community on how to perform testing using existing expertise in an agile environment. This uncertainty may create confusion and contra productivity that can lead to testing teams and their practices considered as an obstacle for full implementation of agile processes within an organisation.   This thesis outlines our current research activities towards identifying and addressing important organisational and technical challenges in the agile environment.  In this context, we propose a new role for traditional testers which will enable them to integrate into the agile team as well as to fully exploit their knowledge in the new context. We have conducted an elaborate industrial survey on the preferences and practices with respect to the contemporary aspects of software testing and identified test-driven development as an important technical area for improvement.  A systematic review on empirical evidences related to test-driven development was performed subsequently, which revealed a list of factors limiting its widespread industrial acceptance. Knowledge of testing was identified as one of those factors and was further investigated in a controlled experiment performed with undergraduate students.   Our future works aim to confirm these research findings in wider as well as industrial settings and investigate other limiting factors in detail, with the aim of providing guidelines for achieving better utilisation of testers and testing practices.

Agile methods and Test-Driven Development are well established methodologies within the software development industry. As a large part of today’s software development is done in Object-Oriented languages like Java it’s only natural that agile best practices have evolved to fit into the Object-Oriented paradigm. Clojure is a relatively young programming language that greatly differs from Object-Oriented languages and it’s thus not certain that these best practices can be directly applicable in Clojure development. This thesis attempts to identify key differences between Clojure and Java that may affect unit testing and the Test-Driven Development process. It finds that although the two languages are fundamentally the difference between them in regards to unit test creation and execution is small. The most striking consequence of Clojure’s lack of Object-Orientation is that dependency injection must be done between functions rather than between classes and objects. It’s also argued that the relative immaturity of the available Clojure development tools can have negative effects on the Test-Driven Development process. / Agila metoder och Testdriven Utveckling är väletablerade metoder inom mjukvaruindustrin. Då en stor del av dagens mjukvaruutveckling sker inom Objektorienterade språk som Java är det bara naturligt att agila best-practices har utvecklats för att passa den Objektorienterade paradigmen. Clojure är ett relativt ungt programmeringsspråk som skiljer sig kraftigt från Objektorienterade språk och det är därför inte självklart att dessa best-practices kan vara direkt applicerbara på utveckling i Clojure. Denna uppsats försöker identifiera de huvudskillnader mellan Clojure och Java som kan ha en direkt påverkan på enhetstestning och den Testdrivna Utvecklingsprocessen. Man upptäcker att det - de två språkens fundamentala skillnader till trots - endast finns små skillnader som påverkar skapandet och körandet av enhetstester. Den mest iögonfallande konsekvensen av bristen på Objektorientering i Clojure är att Dependency Injection måste ske på funktionsnivå, istället för klass- och objektsnivå. Man argumenterar även för att den relativa omogenheten hos verktyg som används vid mjukvaruutveckling i Clojure kan ha en negativ effekt på den Testdrivna Utvecklingsprocessen.

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.

Test-driven development is a software development practice that prompts developers to write tests before writing source code. Studies report varied results on the effects that test-driven development has on the development process, and how this practice compares to other development practices, such as more traditional test-last development methodologies. There also seems like there has not been a discussion around the possible problems that a developer could encounter when adopting this technique, something that seems relevant to making accurate assumptions on the usability of the practice. A literature review was conducted, where the subject of test-driven development is examined with a focus on how inexperienced programmers interact with the practice and what effect it has on the product, in terms of external quality, productivity, number of test written and test coverage. The results suggest that there are no significant differences in external quality and productivity between TDD and TLD. The results also suggest that divide and conquer and refactoring are skills that ease the process of adopting the test-driven development practice.

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.