• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 24
  • 10
  • 10
  • 3
  • 1
  • 1
  • 1
  • 1
  • Tagged with
  • 55
  • 55
  • 55
  • 27
  • 22
  • 21
  • 15
  • 15
  • 12
  • 12
  • 11
  • 10
  • 9
  • 9
  • 9
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
11

Test-lists Utilization in Test Driven Development : The Role of test-lists in Requirements Traceability / Test-lists Utilization in Test Driven Development : The Role of test-lists in Requirements Traceability

Khan, Hassan Mahmood, Arshad, Ibrar January 2012 (has links)
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
12

Systematic Literature Review and Controlled Pilot Experimental Evaluation of Test Driven Development (TDD) vs. Test-Last Development (TLD) / Systematic Literature Review and Controlled Pilot Experimental Evaluation of Test Driven Development (TDD) vs. Test-Last Development (TLD)

Munir, Hussan, Moayyed, Misagh January 2012 (has links)
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
13

Software Testing in Agile Development : Technological and Organisational Challenges

Čaušević, Adnan January 2011 (has links)
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.
14

Test-Driven Development in Clojure : An analysis of how differences between Clojure and Java affects unit testing and design patterns / Testdriven utveckling i Clojure : En analys av hur skillnader mellan Clojure och Java påverkar enhetstestning och designmönster

Nilsson, Niclas January 2015 (has links)
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.
15

Web-CAT: A Web-based Center for Automated Testing

Shah, Anuj Ramesh 20 June 2003 (has links)
The fundamentals of software testing and related activities are often elusive in undergraduate curricula. A direct consequence of the lack of software testing efforts during education is the huge losses suffered by the software industry when applications are not sufficiently tested. Software practitioners have exhorted faculty members and institutions to teach more software testing in universities. The purpose of this research is to provide answers to the needs of such practitioners and introduce software-testing activities throughout the curriculum. The most important goal is to introduce software-testing education without requiring a significant amount of extra effort on behalf of faculty members or teaching assistants. The approach taken comprises the development of the Web-based Center for Automated Testing (Web-CAT) and the introduction of test-driven development (TDD) in courses. Web-CAT serves as a learning environment for software testing tasks and helps automatically assess student assignments. A comparison of student programs developed using Web-CAT with historical records indicated a significant decrease in the number of bugs in submitted programs. Undergraduate students also received exposure to the principles of software testing and were able to write test cases that were on an average better than those generated by an automated test case generator designed specifically for the assignment. / Master of Science
16

Modeling Student Software Testing Processes: Attitudes, Behaviors, Interventions, and Their Effects

Buffardi, Kevin John 23 July 2014 (has links)
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.
17

Automatically Generating Tests from Natural Language Descriptions of Software Behavior

Sunil Kamalakar, FNU 18 October 2013 (has links)
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
18

Investigation on Expectations, Beliefs, and Limitations of Test-DrivenDevelopment in Practice

Ganja, Sree Kavya, Cherukuri, Prudhvi Nath Naidu January 2023 (has links)
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.
19

Assessment of Test-driven Development in an industrial context / Utvärdering av testdriven utveckling i industriell miljö

Gustavsson, Daniel January 2017 (has links)
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.
20

Test-Driven Development with the Focus on Inexperienced Programmers: A Literature Review.

Nyman, Adam, Rimmi, Oliver January 2022 (has links)
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.

Page generated in 0.1044 seconds