For many years, Odoo, an open-source add-on-based platform offering an extensive range of functionalities, including Enterprise Resource Planning, has constantly expanded its scope, resulting in an increased complexity of its software. To cope with this evolution, Odoo has developed an integration testing system called tour execution, which executes predefined testing scenarios (i.e., tours) on the web user interface to test the integration between the front, back, and data layers. This paper reports our effort and experience in extending the tour system with fuzzing. Inspired by action research, we followed an iterative approach to devise FuzzE, a plugin for Odoo's tour system to create new tours. FuzzE was eventually developed in three iterations. Our results show that mutational fuzzing is the most effective approach when integrating with an existing testing infrastructure. We also reported one issue to the Odoo issue tracker. Finally, we present lessons learned from our endeavor, including the necessity to consider testability aspects earlier when developing web-based systems to help the fuzzing effort, and the difficulty faced when performing triage and root cause analysis on failing tours.

In today's organizations, software is mission-critical. However, the legacy of past decisions can make tasks related to artifacts increasingly inefficient or risky, creating debt. While most researchers and practitioners mainly focus on technical debt, some have investigated its social dimensions, known as social debt. We argue that organizations developing software need to tackle debt holistically, as it is intrinsically a socio-technical issue. In this short paper, we rely on a definition of socio-technical debt based on the existing literature to define Debt Stories: a tool based on the User Story format, that can help capture debt elements directly from the stakeholders involved in software development. A debt story includes information about the role of the stakeholder in the development process, the social or technical context, and the impact of the debt element on the different tasks performed by the stakeholder. We provide a first empirical evaluation of the usage of Debt Stories in an industrial context, demonstrating the relevance of Debt Stories to express and communicate socio-technical debt.

Conducting socio-technical software engineering research on closed-source software is difficult as most organizations do not want to give access to their code repositories. Most experiments and publications therefore focus on open-source projects, which only provides a partial view of software development communities. Yet, closing the gap between open and closed source software industries is essential to increase the validity and applicability of results stemming from socio-technical software engineering research. We contribute to this effort by sharing our work in a large company counting 4,800 employees. We mined 101 repositories and produced the GDED dataset containing socio-technical information about 106,216 commits, 470,940 file modifications and 3,471,556 method modifications from 164 developers during the last 13 years, using various programming languages. For that, we used GitDelver, an open-source tool we developed on top of Pydriller, and anonymized and scrambled the data to comply with legal and corporate requirements. Our dataset can be used for various purposes and provides information about code complexity, self-admitted technical debt, bug fixes, as well as temporal information. We also share our experience regarding the processing of sensitive data to help other organizations making datasets publicly available to the research community.

Software development practitioners are increasingly interested in adopting agile methods and generally recommend customisation so that the adopted method can fit the organisational reality. Many studies from the literature report agile adoption and customisation experiences but most of them are hardly generalisable and few are metric-based. They therefore cannot provide quantitative evidence of the suitability of the customised agile method, neither assess the organisation readability to adopt it, nor help in decision-making concerning the organisation transformation strategy. In this paper, we first describe the Agile Methods Quality-Integrated Customisation framework (AM-QuICk) that relies on measurements and aims to continuously assist agile methodologists throughout the agile adoption and customisation process, i.e., during the initial organisation adoption, the method design and throughout the working development process. Then, we present a case study using AM-QuICk within an organisation. With this study, we aim to analyse the current development process and its level of agility and identify the initial risk factors. The data were collected using preliminary interviews with the different team members and two questionnaires. The results reveal that though most respondents are enthusiastic towards agile principles, a progressive transformation strategy would be beneficial.

Several software quality models can be found in the literature with different status regarding normalization issues. Besides, a vast amount of assessment and measurement methods have been proposed in order to monitor the different quality characteristics of various artefacts. The difficulty to integrate them meaningfully into the development process often results in a vastly inefficient use of measurement. One reason for this is related to the waste of time needed to select and integrate different methods. The Model-Centric Quality Assessment (MoCQA) framework is designed to support a flexible integration of different types of quantitative quality assessment, possibly based on different models, all along the software development lifecycle. Among the efforts to assist the task of designing MoCQA models, this paper introduces QuaTALOG, a tool designed to support the Model-Centric Quality Assessment by providing effective information about available measurement and assessment methods to analysts using the framework.