Per Runeson

Guidelines for conducting and reporting case study research in software engineering

Case study is a suitable research methodology for software engineering research since it studies contemporary phenomena in its natural context. However, the understanding of what constitutes a case study varies, and hence the quality of the resulting studies. This paper aims at providing an introduction to case study methodology and guidelines for researchers conducting case studies and readers studying reports of such studies. The content is based on the authors’ own experience from conducting and reading case studies. The terminology and guidelines are compiled from different methodology handbooks in other research domains, in particular social science and information systems, and adapted to the needs in software engineering. We present recommended practices for software engineering case studies as well as empirically derived and evaluated checklists for researchers and readers of case study research.

Case Study Research in Software Engineering: Guidelines and Examples

Based on their own experiences of in-depth case studies of software projects in international corporations, in this bookthe authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering. This is the first software engineering specific book on thecase study research method.

Detection of Duplicate Defect Reports Using Natural Language Processing

Defect reports are generated from various testing and development activities in software engineering. Sometimes two reports are submitted that describe the same problem, leading to duplicate reports. These reports are mostly written in structured natural language, and as such, it is hard to compare two reports for similarity with formal methods. In order to identify duplicates, we investigate using natural language processing (NLP) techniques to support the identification. A prototype tool is developed and evaluated in a case study analyzing defect reports at Sony Ericsson mobile communications. The evaluation shows that about 2/3 of the duplicates can possibly be found using the NLP techniques. Different variants of the techniques provide only minor result differences, indicating a robust technology. User testing shows that the overall attitude towards the technique is positive and that it has a growth potential.

Software product line testing - A systematic mapping study

Context: Software product lines (SPL) are used in industry to achieve more efficient software development. However, the testing side of SPL is underdeveloped. Objective: This study aims at surveying existing research on SPL testing in order to identify useful approaches and needs for future research. Method: A systematic mapping study is launched to find as much literature as possible, and the 64 papers found are classified with respect to focus, research type and contribution type. Results: A majority of the papers are of proposal research types (64%). System testing is the largest group with respect to research focus (40%), followed by management (23%). Method contributions are in majority. Conclusions: More validation and evaluation research is needed to provide a better foundation for SPL testing.

A systematic review on regression test selection techniques

Regression testing is verifying that previously functioning software remains after a change. With the goal of finding a basis for further research in a joint industry-academia research project, we conducted a systematic review of empirical evaluations of regression test selection techniques. We identified 27 papers reporting 36 empirical studies, 21 experiments and 15 case studies. In total 28 techniques for regression test selection are evaluated. We present a qualitative analysis of the findings, an overview of techniques for regression test selection and related empirical evidence. No technique was found clearly superior since the results depend on many varying factors. We identified a need for empirical studies where concepts are evaluated rather than small variations in technical implementations.

A survey of unit testing practices

Unit testing is testing of individual units or groups of related units. What are a companys typical strengths and weaknesses when applying unit testing? Per Beremark and the author surveyed unit testing practices on the basis of focus group discussions in software process improvement network (SPIN) and launched a questionnaire to validate the results. This survey is an indication of unit testing in several companies. You can use the questionnaire at your own company to clarify what you mean by unit testing, to identify the strengths and weaknesses of your unit testing practices, and to compare with other organizations to improve those practices

A Second Replicated Quantitative Analysis of Fault Distributions in Complex Software Systems

To contribute to the body of empirical research on fault distributions during development of complex software systems, a replication of a study of Fenton and Ohlsson is conducted. The hypotheses fr...

Combining agile methods with stage-gate project management

We encountered cultural changes and different management and engineering viewpoints in a study of three large software development organizations that started using agile methods. Case studies at three large software product companies show the benefits and pitfalls of integrating agile methods with stage-gate management models.

Defect content estimations from review data

Reviews are essential for defect detection and they provide an opportunity to control the software development process. This paper focuses upon methods for estimating the defect content after a review and hence to provide support for process control. Two new estimation methods are introduced as the assumptions of the existing statistical methods are not fulfilled. The new methods are compared with a maximum-likelihood approach. Data from several reviews are used to evaluate the different methods. It is concluded that the new estimation methods provide new opportunities to estimate the defect content.

Are the Perspectives Really Different? – FurtherExperimentation on Scenario-Based Reading of Requirements

Perspective-BasedReading (PBR) is a scenario-based inspection technique whereseveral reviewers read a document from different perspectives(e.g. user, designer, tester). The reading is made accordingto a special scenario, specific for each perspective. The basicassumption behind PBR is that the perspectives find differentdefects and a combination of several perspectives detects moredefects compared to the same amount of reading with a singleperspective. This paper presents a study which analyses the differencesin perspectives. The study is a partial replication of previousstudies. It is conducted in an academic environment using graduatestudents as subjects. Each perspective applies a specific modellingtechnique: use case modelling for the user perspective, equivalencepartitioning for the tester perspective and structured analysisfor the design perspective. A total of 30 subjects were dividedinto 3 groups, giving 10 subjects per perspective. The analysisresults show that (1) there is no significant difference amongthe three perspectives in terms of defect detection rate andnumber of defects found per hour, (2) there is no significantdifference in the defect coverage of the three perspectives,and (3) a simulation study shows that 30 subjects is enough todetect relatively small perspective differences with the chosenstatistical test. The results suggest that a combination of multipleperspectives may not give higher coverage of the defects comparedto single-perspective reading, but further studies are neededto increase the understanding of perspective difference.