Identifying the root cause of a software bug and fixing it is challenging. One reason for this is that many bugs are not reproducible during bug fixing. We aim to provide an overview of existing works on bug reproduction and localization. We ask four research questions: RQ1: What types of problems have been studied in the area of bug reproduction and localization? RQ2: How are problems studied in previous research? RQ3: What are the main findings and outcomes of previous studies? RQ4: What are the gaps and challenges identified in previous studies? We conducted a systematic mapping study analyzing research literature published between 2011 and 2021. The search for primary studies involved four major computer science digital libraries and resulted in 134 studies for analysis. Regarding RQ1 we found that many studies focus on information retrieval-based approaches to support bug reproduction and localization. Regarding RQ2 we found that bug reports and source code are the typical data sources of bug reproduction and localization. Also, most studies include experiments with historical data but do not investigate ongoing projects. Regarding RQ3 we found that many studies adapt or combine existing approaches for bug reproduction and localization to improve their accuracy or applicability (e.g., combine requirements-related information and bug reports to increase information-retrieval-based techniques). Regarding RQ4 we found that existing solutions for bug reproduction and localization have rarely been integrated into the workflow of developers. Although bug reproduction and localization have been studied in quite some detail, new challenges and gaps emerge due to the evolution of software technologies and practices and the practical needs of software developers. For example, bug reproduction approaches for traditional web applications do not work well with modern “Single Page Web Applications” (SPA) and related technologies, e.g., Angular or React.

Web applications are often built as Single Page Applications (SPA), for example applications offered by Google, Facebook, Twitter or Netflix. Users interact with SPAs through a single HTML page that is dynamically rewritten with new data from the web server (instead of a web browser that loads entire new HTML pages). Just like with any type of software system, debugging is a common activity during the development and maintenance of SPAs. In order to fix bugs observed during runtime, developers often try to reproduce the bug first to better understand it. However, research has shown that reproducing bugs is not always possible. In this paper we (i) develop a technique for Application Monitoring (AM) to collect data to support bug reproduction; and (ii) apply the monitoring technique in a SPA test bed as well as a real-world SPA application to show its feasibility. As part of our research we developed an initial version of the AM technique and implemented it in a prototype. Our evaluation using this prototype showed that it not only improves the efficiency of the bug reproduction process but also reduces information gaps caused by incomplete bug reports submitted by users. Additionally, compared to the information provided by users, data provided by AM is more accurate and detailed and covers a wider range of data. Future work includes deploying the AM framework in more SPAs and investigating how AM can be integrated into software developer workflows.

Background: Development processes and practices depend on the context in which software is developed (e.g., locations, organizations, projects, developers). Aim: We aim at understanding development processes and practices in New Zealand, a country with a relatively small but growing software sector. We are particularly interested in methods and practices used in such environment, the implementation technologies software development professionals use, how professionals ensure software quality, and how they manage software release processes. Method: We conducted a descriptive survey targeting individual software development professionals working in New Zealand software companies. Results: New Zealand professionals use similar methodologies as professionals in other countries. Popular programming languages differ somewhat to popular languages in other rankings. Quality assurance is rather ad-hoc and the release process is inspired by agile software development principles. Conclusions: Our findings highlight some differences of the New Zealand software industry to other countries. Furthermore, we identified some strengths and weaknesses related to processes and practices. Our findings can help software professionals and organizations reflect on (and potentially adjust) the way they work.