44 research outputs found

    Towards a hybrid testing process unifying exploratory testing and scripted testing

    Get PDF
    CONTEXT Given the current state of the art in research, practitioners are faced with the challenge of choosing scripted testing (ST) or exploratory testing (ET). OBJECTIVE This study aims at systematically incorporating strengths of ET and ST in a hybrid testing process to overcome the weaknesses of each. METHOD We utilized systematic review and practitioner interviews to identify strengths and weaknesses of ET and ST. Strengths of ET were mapped to weaknesses of ST and vice versa. Noblit and Hare's lines-ofargument method was used for data analysis. The results of the mapping were used as input to codesign a hybrid process with experienced practitioners. RESULTS We found a clear need to create a hybrid process as follows: (i) both ST and ET provide strengths and weaknesses, and these depend on some particular conditions, which prevents preference of one approach to another; and (ii) the mapping showed that it is possible to address the weaknesses in one process by the strengths of the other in a hybrid form. With the input from literature and industry experts, a flexible and iterative hybrid process was designed. CONCLUSIONS Practitioners can clearly benefit from using a hybrid process given the mapping of advantages and disadvantage

    Configuration management and product lines to enhance the replication process in software engineering

    Full text link
    This research is concerned with the experimental software engineering area, specifically experiment replication. Replication has traditionally been viewed as a complex task in software engineering. This is possibly due to the present immaturity of the experimental paradigm applied to software development. Researchers usually use replication packages to replicate an experiment. However, replication packages are not the solution to all the information management problems that crop up when successive replications of an experiment accumulate. This research borrows ideas from the software configuration management and software product line paradigms to support the replication process. We believe that configuration management can help to manage and administer information from one replication to another: hypotheses, designs, data analysis, etc. The software product line paradigm can help to organize and manage any changes introduced into the experiment by each replication. We expect the union of the two paradigms in replication to improve the planning, design and execution of further replications and their alignment with existing replications. Additionally, this research work will contribute a web support environment for archiving information related to different experiment replications. Additionally, it will provide flexible enough information management support for running replications with different numbers and types of changes. Finally, it will afford massive storage of data from different replications. Experimenters working collaboratively on the same experiment must all have access to the different experiments

    Empirical Standards for Software Engineering Research

    Full text link
    Empirical Standards are natural-language models of a scientific community's expectations for a specific kind of study (e.g. a questionnaire survey). The ACM SIGSOFT Paper and Peer Review Quality Initiative generated empirical standards for research methods commonly used in software engineering. These living documents, which should be continuously revised to reflect evolving consensus around research best practices, will improve research quality and make peer review more effective, reliable, transparent and fair.Comment: For the complete standards, supplements and other resources, see https://github.com/acmsigsoft/EmpiricalStandard

    Distributed team cohesion – not an oxymoron. The impact of information and communications technologies on teamness in globally distributed IT projects

    Get PDF
    Globally distributed IT projects are common practice in today’s globalized world. Typically, project team members’ work on interdependent tasks, with a common goal to be achieved as one team. However, being split between multiple locations impedes communication among team members and hampers the development of trust. Information and communications media enable communication between geographically distributed project team members and help to create and maintain trust within project units. Communication and trust are particularly significant for fostering a feeling of oneness among project team members. Oneness, also referred to as “teamness”, is repeatedly mentioned as one of the challenges facing global project teams. However, prior literature on teamness is very scarce and its importance is underrepresented. This research contributes to the field in two ways. First, the theoretical study based on a systematic literature review examines available evidence of teamness in globally distributed projects. Secondly, an empirical study based on interviews conducted with global project managers fills the current gap in literature on the link between use of ICT and establishing a sense of team unity. This paper draws practitioners’ attention to the importance of striving for teamness in spite of the geographical distance that exists between project team members

    Problematizing agile in the large: alternative assumptions for large-scale agile development

    Get PDF
    In this paper we critically examine the underlying assumptions in existing studies of large-scale agile software development. We use Alvesson and Sandberg’s problematization methodology and find that existing studies of large-scale agile share a number of underlying assumptions relevant to small rather than large-scale projects. Empirically, we draw on a case study of a large-scale agile project lasting nearly four years and involving more than 120 participants. Interestingly, the findings of the study contradict many of the assumptions in the literature review. For example, work across boundaries becomes at least as important as work within teams. We contribute by developing an alternative set of assumptions better suited to the characteristics of large-scale agile software development. Based on this, we re-conceptualize agile in the large, emphasizing both the complex knowledge boundaries within the project itself, as well as the interactive complexity and tight coupling with technologies and processes outside the project

    Agile Processes in Software Engineering and Extreme Programming: 18th International Conference, XP 2017, Cologne, Germany, May 22-26, 2017, Proceedings

    Get PDF
    agile software development; lean development; scrum; project management; software developmen

    EMPIRICAL CHARACTERIZATION OF SOFTWARE QUALITY

    Get PDF
    The research topic focuses on the characterization of software quality considering the main software elements such as people, process and product. Many attributes (size, language, testing techniques etc.) probably could have an effect on the quality of software. In this thesis we aim to understand the impact of attributes of three P’s (people, product, process) on the quality of software by empirical means. Software quality can be interpreted in many ways, such as customer satisfaction, stability and defects etc. In this thesis we adopt ‘defect density’ as a quality measure. Therefore the research focus on the empirical evidences of the impact of attributes of the three P’s on the software defect density. For this reason empirical research methods (systematic literature reviews, case studies, and interviews) are utilized to collect empirical evidence. Each of this research method helps to extract the empirical evidences of the object under study and for data analysis statistical methods are used. Considering the product attributes, we have studied the size, language, development mode, age, complexity, module structure, module dependency, and module quality and their impact on project quality. Considering the process attributes, we have studied the process maturity and structure, and their impact on the project quality. Considering the people attributes, we have studied the experience and capability, and their impact on the project quality. Moreover, in the process category, we have studied the impact of one testing approach called ‘exploratory testing’ and its impact on the quality of software. Exploratory testing is a widely used software-testing practice and means simultaneous learning, test design, and test execution. We have analyzed the exploratory testing weaknesses, and proposed a hybrid testing approach in an attempt to improve the quality. Concerning the product attributes, we found that there exist a significant difference of quality between open and close source projects, java and C projects, and large and small projects. Very small and defect free modules have impact on the software quality. Different complexity metrics have different impact on the software quality considering the size. Product complexity as defined in Table 53 has partial impact on the software quality. However software age and module dependencies are not factor to characterize the software quality. Concerning the people attributes, we found that platform experience, application experience and language and tool experience have significant impact on the software quality. Regarding the capability we found that programmer capability has partial impact on the software quality where as analyst capability has no impact on the software quality. Concerning process attributes we found that there is no difference of quality between the project developed under CMMI and those that are not developed under CMMI. Regarding the CMMI levels there is difference of software quality particularly between CMMI level 1 and CMMI level 3. Comparing different process types we found that hybrid projects are of better quality than waterfall projects. Process maturity defined by (SEI-CMM) has partial impact on the software quality. Concerning exploratory testing, we found that exploratory testing weaknesses induce the testing technical debt therefore a process is defined in conjunction with the scripted testing in an attempt to reduce the associated technical debt of exploratory testing. The findings are useful for both researchers and practitioners to evaluate their project
    corecore