Abstract Video surveillance has benefited greatly from advances in artificial intelligence, particularly in computer vision, and the number of monitored environments has consequently increased, creating new challenges in extracting relevant information. When multiple cameras cover adjacent areas, overlapping fields of view can cause the same subject to be detected across cameras, introducing duplicate counts. Although the literature offers established solutions, many rely on high-quality recordings and complex, computationally intensive methods, limiting their use on resource-constrained devices. In this work, we address these challenges with a solution that leverages minimal information about target subjects and uses a transductive strategy to detect duplicates based on interactions within overlapping fields of view. Experiments in real-world settings show that our approach suppresses duplicates effectively, making it suitable for deployment on resource-limited hardware. We evaluate state-of-the-art lightweight models with high inference speed, as well as classical re-identification methods, in scenarios with low-quality video and constrained devices. The results underscore the effectiveness of the proposed approach and motivate exploration of re-ID with domain adaptation, as well as anchor-free methods with weak or semi-supervised learning.

Due to limited hardware, consumer-grade surveillance cameras usually rely on cloud-based computer vision models to detect people in video footage. However, this approach introduces a recurring cost, as users must continuously pay for cloud processing. One possible solution is to use mobile devices for person detection, as they can be found in most households. Yet, experimental evaluations on the impact of different computer vision models on mobile device resource usage are limited. This study examines the efficiency of YOLOv8 models on Android devices, assessing detection performance, inference time, memory consumption, and energy efficiency. The models were tested using two machine learning frameworks, LiteRT (formerly TensorFlow Lite) and ONNX Runtime, to determine the most suitable approach for mobile inference. Experimental results confirm that compact models, such as YOLOv8n and YOLOv8s, offer the best trade-off between computational efficiency and detection accuracy, while LiteRT outperforms ONNX in all evaluated metrics.

The manual generation of test scripts is a time-intensive, costly, and error-prone process, indicating the value of automated solutions. Large Language Models (LLMs) have shown great promise in this domain, leveraging their extensive knowledge to produce test code more efficiently. This study investigates the quality of Python test code generated by three LLMs: GPT-4o, Amazon Q, and LLama 3.3. We evaluate the structural reliability of test suites generated under two distinct prompt contexts: Text2Code (T2C) and Code2Code (C2C). Our analysis includes the identification of errors and test smells, with a focus on correlating these issues to inadequate design patterns. Our findings reveal that most test suites generated by the LLMs contained at least one error or test smell. Assertion errors were the most common, comprising 64% of all identified errors, while the test smell Lack of Cohesion of Test Cases was the most frequently detected (41%). Prompt context significantly influenced test quality; textual prompts with detailed instructions often yielded tests with fewer errors but a higher incidence of test smells. Among the evaluated LLMs, GPT-4o produced the fewest errors in both contexts (10% in C2C and 6% in T2C), whereas Amazon Q had the highest error rates (19% in C2C and 28% in T2C). For test smells, Amazon Q had fewer detections in the C2C context (9%), while LLama 3.3 performed best in the T2C context (10%). Additionally, we observed a strong relationship between specific errors, such as assertion or indentation issues, and test case cohesion smells. These findings demonstrate opportunities for improving the quality of test generation by LLMs and highlight the need for future research to explore optimized generation scenarios and better prompt engineering strategies.

Background. Test smells can pose difficulties during testing activities, such as poor maintainability, non-deterministic behavior, and incomplete verification. Existing research has extensively addressed test smells in automated software tests, but little attention has been paid to smells in natural language tests. While some research has attempted to catalog such test smells, there is a lack of investigation into their impact on the effectiveness of test cases. Aims. In this paper, we conduct a controlled experiment with 30 participants from academia and industry to examine the impact of test smells in manual test descriptions. Method. Specifically, we analyze whether the presence of two test smells, Ambiguous Test and Eager Action, result in (1) increased test execution time, (2) a higher number of steps needed to complete the tests, and (3) high divergency on the perceived success of the tests outcomes. Results. Our findings reveal that an Ambiguous Test can increase execution time by up to five times and screen flow by up to seven times. In addition, if the Eager Actions are dependent on one another, there is no increase in execution time and screen flow. Conclusions. It highlights the need for better design of manual test descriptions to improve clarity, consistency, and performance execution.

Smart homes are transforming domestic environments by integrating connected devices and sensors, enabling lighting, temperature, and security automation. While these systems enhance comfort and efficiency, they often rely on predefined settings or manual input due to the absence of adaptive recommendation systems. AI-driven recommendation systems personalize actions by learning from user behavior and environmental data, improving the smart home experience. However, they also introduce cybersecurity risks, particularly data poisoning attacks, where manipulated data disrupts system functionality. This paper exposes and examines vulnerabilities in smart home recommendation systems, categorizing data poisoning attacks and analyzing their impact. Through a literature review and attack vector analysis, we identify key weaknesses and propose mitigation strategies to enhance security. Our goal is to contribute to developing robust smart home technologies that protect user privacy, ensure reliability, and withstand adversarial threats.

ABSTRACT Context Smart home devices have become increasingly popular in modern households, powered by the Internet of Things (IoT) advances. The data generated by smart devices can provide valuable insights into users' behavior and preferences. By analyzing the data, one can understand how people interact with their homes, thus creating a “smart home profile”. To comprehend the complete IoT ecosystem dynamics of an intelligent environment, it is necessary to learn from each IoT device to predict its status in the future time. Nevertheless, dealing with real‐world IoT data structure requires considerable preprocessing tasks and the employment of classifiers that can learn multiple IoT inputs from a single IoT message. Objective Aware of these challenges, this paper proposes a novel methodology to process multi‐label IoT data and provide a comprehensive comparison of multi‐label classifiers for forecasting the status of smart devices, considering their efficiency and accuracy. Method We propose a data transformation method to preprocess the IoT data to be used by multi‐label classifiers. This method is based on real data structure. Results We evaluate our proposal in two real‐world scenarios and various multi‐label classifiers. The promising findings indicate that efficient classifiers can generate many correct predictions for a comprehensive IoT ecosystem in a small fraction of a second. Conclusions Our proposed data transformation can fit the context of prediction to smart homes and work with multi‐label classifiers to understand user behavior.

Test smells can pose difficulties during testing activities, such as poor maintainability, non-deterministic behavior, and incomplete verification. Existing research has extensively addressed test smells in automated software tests but little attention has been given to smells in natural language tests. While some research has identified and catalogued such smells, there is a lack of systematic approaches for their removal. Consequently, there is also a lack of tools to automatically identify and remove natural language test smells. This paper introduces a catalog of transformations designed to remove seven natural language test smells and a companion tool implemented using Natural Language Processing (NLP) techniques. Our work aims to enhance the quality and reliability of natural language tests during software development. The research employs a two-fold empirical strategy to evaluate its contributions. First, a survey involving 15 software testing professionals assesses the acceptance and usefulness of the catalog’s transformations. Second, an empirical study evaluates our tool to remove natural language test smells by analyzing a sample of real-practice tests from the Ubuntu OS. The results indicate that software testing professionals find the transformations valuable. Additionally, the automated tool demonstrates a good level of precision, as evidenced by a F-Measure rate of 83.70%.

Abstract Test smells are considered bad practices that can reduce the test code quality, thus harming software testing goals and maintenance activities. Prior studies have investigated the diffusion of test smells and their impact on test code maintainability. However, we cannot directly compare the outcomes of the studies as most of them use customized datasets. In response, we introduced the TSSM (Test Smells and Structural Metrics) dataset, containing test smells detected using the JNose Test tool and structural metrics (test code and production code) calculated with the CK metrics tool of 13,703 open‐source Java systems from GitHub. In addition, we perform an empirical study to investigate the relationship between test smells and structural metrics of test code and the relationship between test smells on a large‐scale dataset. We split the projects into three clusters to analyze the distribution of test smells, the co‐occurrences among test smells, and the correlation of test smells and structural metrics of test code. The ratio of smelly test classes with a specific test smell is similar among the clusters, but we could observe a significant difference in the number of test smells among them. The test smells Sleepy Test, Mystery Guest, and Resource Optimism rarely occur in the three clusters, and the last two are strongly correlated, indicating that those test smells are more severe than others. Our results point out that most test smells have a moderate correlation with high complexity, large size, and coupling of the test code, indicating that they can also negatively affect its quality. To support further studies, we made our dataset publicly available.

Background: Test smells indicate potential problems in the design and implementation of automated software tests that may negatively impact test code maintainability, coverage, and reliability. When poorly described, manual tests written in natural language may suffer from related problems, which enable their analysis from the point of view of test smells. Despite the possible prejudice to manually tested software products, little is known about test smells in manual tests, which results in many open questions regarding their types, frequency, and harm to tests written in natural language. Aims: Therefore, this study aims to contribute to a catalog of test smells for manual tests. Method: We perform a two-fold empirical strategy. First, an exploratory study in manual tests of three systems: the Ubuntu Operational System, the Brazilian Electronic Voting Machine, and the User Interface of a large smartphone manufacturer. We use our findings to propose a catalog of eight test smells and identification rules based on syntactical and morphological text analysis, validating our catalog with 24 in-company test engineers. Second, using our proposals, we create a tool based on Natural Language Processing (NLP) to analyze the subject systems' tests, validating the results. Results: We observed the occurrence of eight test smells. A survey of 24 in-company test professionals showed that 80.7% agreed with our catalog definitions and examples. Our NLP-based tool achieved a precision of 92%, recall of 95%, and f-measure of 93.5%, and its execution evidenced 13,169 occurrences of our cataloged test smells in the analyzed systems. Conclusion: We contribute with a catalog of natural language test smells and novel detection strategies that better explore the capabilities of current NLP mechanisms with promising results and reduced effort to analyze tests written in different idioms.

Refactorings are transformations to improve the code design without changing overall functionality and observable behavior. During the refactoring process of smelly test code, practitioners may struggle to identify refactoring candidates and define and apply corrective strategies. This paper reports on an empirical study aimed at understanding how test smells and test refactorings are discussed on the Stack Exchange network. Developers commonly count on Stack Exchange to pick the brains of the wise, i.e., to ‘look up’ how others are completing similar tasks. Therefore, in light of data from the Stack Exchange discussion topics, we could examine how developers understand and perceive test smells, the corrective actions they take to handle them, and the challenges they face when refactoring test code aiming to fix test smells. We observed that developers are interested in others’ perceptions and hands-on experience handling test code issues. Besides, there is a clear indication that developers often ask whether test smells or anti-patterns are either good or bad testing practices than code-based refactoring recommendations.

Refactoring is a practice commonly used by developers to restructure the source code without changing its external behavior. Over the last decades, the software engineering research community has been making use of mining software repository techniques to investigate refactoring under multiple perspectives, identifying properties and impact of this practice on source code quality, other than using refactoring data coming from software repositories to build automated recommendation systems. While the current state of the art proposes various automated tools to mine refactoring data, there is still a lack of instruments that may help researchers when mining test-specific refactoring data. The availability of those instruments may enable additional, specialized techniques to support developers while refactoring test code. In this paper, we introduce an approach that extends REFACTORINGMINER-a well-established refactoring mining tool having high precision and recall scores- and is able to detect seven test-specific refactoring operations. We perform mixed-method research to assess capabilities and usefulness of the approach. First, we compare the test-specific refactoring data extracted by the approach against an oracle of 375 test-specific refactorings. Second, we engage with 15 software engineering researchers and apply a technology acceptance model to investigate how they would benefit from our approach. The key results of the study show that our approach reaches 100% and 92.5% of precision and recall scores, respectively. In addition, the approach is considered useful and suitable for various research tasks, including the definition of novel learning models able to recommend test-specific refactoring actions.

The teaching-learning process may require specific pedagogical approaches to establish a relationship with industry practices. Recently, some studies investigated the educators’ perspectives and the undergraduate courses curriculum to identify potential weaknesses and solutions for the software testing teaching process. However, it is still unclear how the practitioners evaluate the acquisition of knowledge about software testing in undergraduate courses. This study carried out an expert survey with 68 newly graduated practitioners to determine what the industry expects from them and what they learned in academia. The yielded results indicated that those practitioners learned at a similar rate as others with a long industry experience. Also, they studied less than half of the 35 software testing topics collected in the survey and took industry-backed extracurricular courses to complement their learning. Additionally, our findings point out a set of implications for future research, as the respondents’ learning difficulties (e.g., lack of learning sources) and the gap between academic education and industry expectations (e.g., certifications).

White label products consist of rebranding a product to sell to another corporation. It has been largely applied in physical products' manufacturing, and it seems to be suitable for software startups, in particular for the opportunity of developing custom applications to different customers in reduced period of time, when compared to stand-alone applications. This study aims to unveil the concept of white label software and its feasibility for software startups; investigate how software startups used to apply this concept; investigate if advanced code reuse techniques, such as highly-configurable systems, could be used as an opportunity lever for them. We carried out semi-structured interviews with four software startups. We also conducted a survey in a Brazilian startup ecosystem.The results presented an interesting portrait of how software startups have dealt with software reuse in their daily practices, with particular attention on how white label software development has been explored in their projects. A set of challenges is also discussed in this paper.

Software Product Line (SPL) engineering is a paradigm for the development of a family of products based on the systematic reuse of artifacts. Although its increasing adoption, organizations often start with a single system and use ad-hoc techniques such as clone-and-own to create new systems by performing small changes and adaptations to meet customers' needs. However, as the number of clones raises over time, it becomes a hard task to maintain and support all the systems. This scenario happened in the Apo-Games projects and adopting SPL Engineering can address these issues. Product Line Architecture (PLA) is one of the key assets to allow the success of SPL development. In this paper, we apply our approach to recover the PLA of the Apo-Games projects by using the source code of a set of Android and Java clones. We provide a set of information to support the development of the Apo-Games SPL. We identified that the Android and Java projects have similar PLAs.

Context. Software Product Lines (SPL) engineering is increasingly being applied to handle variability in industrial software systems. Problem. The research community has pointed out a series of benefits which modularity brings to software composition, a key aspect in SPL engineering. However, in practice, the reuse in Javascript-based systems relies on the use of package managers (e.g., npm, jam, bower, requireJS), but these approaches do not allow the management of project features. Method. This paper presents the RiPLE-HC, a strategy aimed at blending compositional and annotative approaches to implement variability in Javascript-based systems. Results. We applied the approach in an industrial environment and conducted an academic case study with six open-source systems to evaluate its robustness and scalability. Additionally, we carried a controlled experiment to analyze the impact of the RiPLE-HC code organization on the feature location maintenance tasks. Conclusion. The empirical evaluations yielded evidence of reduced effort in feature location, and positive benefits when introducing systematic reuse aspects in Javascript-based systems.

With the ever increasing popularity of JavaScript in different domains to build bigger and more complex software systems, variability management may be deemed as an affordable strategy. In this sense, Software Product Lines (SPL) engineering is one of the most successful paradigms to accomplish the necessary modularity and systematic reuse of code artifacts for that purpose. In previous work, we present tool support to hybrid composition of JavaScript-based product lines, called RiPLE-HC, which we now extend to incorporate a means to deal with feature interactions and feature annotation scattering in a more smooth way. The proposed tool support may provide practitioners with an easy-to-use approach to implement crosscutting features by increasing the awareness of the developers about the features implementation.

Change Requests (CRs) are key elements to software maintenance and evolution. Finding the appropriate developer to a CR is crucial for obtaining the lowest, economically feasible, fixing time. Nevertheless, assigning CRs is a labor-intensive and time consuming task. In this paper, we present a semi-automated CR assignment approach which combine rule-based and information retrieval techniques. The approach emphasizes the use of contextual information, essential to effective assignments, and puts the development team in control of the assignment rules, toward making its adoption easier. Results of an empirical evaluation showed that the approach is up to 46,5% more accurate than approaches which rely solely on machine learning techniques.

ABSTRACT Software maintenance starts as soon as the first artifacts are delivered and is essential for the success of the software. However, keeping maintenance activities and their related artifacts on track comes at a high cost. In this respect, change request (CR) repositories are fundamental in software maintenance. They facilitate the management of CRs and are also the central point to coordinate activities and communication among stakeholders. However, the benefits of CR repositories do not come without issues, and commonly occurring ones should be dealt with, such as the following: duplicate CRs, the large number of CRs to assign, or poorly described CRs. Such issues have led researchers to an increased interest in investigating CR repositories, by considering different aspects of software development and CR management. In this paper, we performed a systematic mapping study to characterize this research field. We analyzed 142 studies, which we classified in two ways. First, we classified the studies into different topics and grouped them into two dimensions:challengesandopportunities. Second, the challenge topics were classified in accordance with an existing taxonomy for information retrieval models. In addition, we investigated tools and services for CR management, to understand whether and how they addressed the topics identified. Copyright © 2013 John Wiley & Sons, Ltd.

Context: Change Request (CR) repositories play an important role in the software maintenance and evolution process. Through a CR repository, software changes are reported and assigned to developers. Finding the appropriate developer to a CR is crucial for obtaining the lowest, economically feasible, fixing time. Nevertheless, assigning CRs is a labor-intensive and time consuming task. Although many work have proposed automated approaches for CR assignment, they have been implemented without investigating the fundamental aspects which characterize the task itself. Objective: This paper investigates the effort that is taken to assign CR to appropriate developers and identifies the fundamental aspects that characterize it, such as the strategies to perform the assignments and the complexity involved in them. Such investigation improves the current knowledge on the topic, providing researchers and practitioners with useful information towards developing effective solutions. Method: A survey was performed with software developers to understand CR assignment in the Brazilian Federal Organization for Data Processing. The questionnaire was composed of 38 questions, being them both open-ended and closed-ended. We analyzed the answers of 36 respondents. Results: We find that: there is a significant amount of time being spent on assignments (e.g., assigning 20 CRs can take up to 3.3 hours); there are many strategies used to assign CRs, which are complementary to those used in current automated solutions; and CR assignment is very complexity due to a process that requires cognitive abilities for information seeking, communication, and memorization. Conclusion: CR repositories are fundamental to software maintenance, however assigning CRs to developers is an expensive activity. Although we understand that fully and totally accurate automation of assignments is unlikely, further improvements on this direction are feasible and necessary to reduce costs. This way, this paper brings relevant findings to guide new research on automated CR assignment.

Software Product Line (SPL) Engineering focuses on systematic software reuse, which has benefits such as reductions in time-to-market and effort, and improvements in the quality of products. However, establishing a SPL is not a simple matter, and can affect all aspects of the organization, since the approach is complex and involves major investment and considerable risk. These risks can have a negative impact on the expected ROI for an organization, if SPL is not sufficiently managed. This paper presents a mapping study of Risk Management (RM) in SPL Engineering. We analyzed a set of thirty studies in the field. The results points out the need for risk management practices in SPL, due to the little research on RM practices in SPL and the importance of identifying insight on RM in SPL. Most studies simply mention the importance of RM, however the steps for managing risk are not clearly specified. Our findings suggest that greater attention should be given, through the use of industrial case studies and experiments, to improve SPL productivity and ensure its success. This research is a first attempt within the SPL community to identify, classify, and manage risks, and establish mitigation strategies.

Background - Risk Management (RM) practices are usually established towards avoiding or minimizing problems, likely to occur during software development. It can be stated as the task of analyzing and managing the impact of every important action to be performed in the project. Aim - In the context of RM practices, we developed a scoping study, aiming at analyzing the current scenario of RM practices in software development. Method - We analyzed 74 studies published by the most important venues published up to the year 2011. Based on the analyzed dataset, we sketched a set of useful practices for applying RM in software projects. Results - The analysis indicate that most of the studies subjectively describe ways to evaluate risks, instead of providing readers with details on how RM is to be performed. Conclusions - Such findings points out to the need of further research in the field of RM, specially due to its importance for software development projects.

Explicit Risk Management (RM) in Software Product Lines Engineering (SPL) is considered an open question, as posed in literature, and confirmed by industrial practices, unlike Single System Development (SSD), which contains a large set of evidence. The goal of this research is to synthesize the available evidence gathered in previous research, in a form of two scoping studies, which considered RM in SPL and SSD, using the narrative synthesis method. Through the synthesis we could identify common risks to both development paradigm, as well as RM activities and practices most commonly used to apply RM in projects. In addition, was observed that RM to SPL is still an open question if compared to SSD.

Software Product Lines (SPL) adoption can affect several aspects of an organization and it involves significant investment and risk. This way, SPL risk management is a crucial activity of SPL adoption. This study aims to identify SPL risks during the scoping and requirement disciplines to provide information to better understand risk management in SPL. In order to achieve the previous stated goal, a case study research was applied in an industrial project in the medical information management domain. Using the captured risks, a classification scheme was built and risk mitigation strategies were identified. We spent five months, totaling 79 hours, performing risk management (RM) in the scoping discipline and twelve months, totaling 148 hours, performing RM on the requirements discipline. We identified 32 risks during the scoping discipline and 20 risks during the requirements discipline, 14 risks occurred in both disciplines. Some identified risks are not particular to SPL development, however, they have their impact increased due to the SPL characteristic. All the study results and lessons learned are useful for all project managers and researchers who are considering the introduction of SPL risk management in industry or academia.

Testing can still be considered a bottleneck for software product line engineering. The variability implemented in the source artifacts increases its complexity. Due to its key role for product line quality, testing requires cost-effective practices, such as techniques for test selection should be produced to enable companies to experience the substantial production cost savings. In this paper, we present the outline of a Ph.D. research aimed at developing a reasoning framework to improve SPL testing practices. Based on multiple sources of evidence, the framework intends to provide testers with an automated reasoner for determining which techniques may be suitable for a given variability implementation mechanism, and how these should be employed in order to makes testing in a SPL a more effective and efficient practice. We plan to perform empirical evaluations in order to assess the proposal effectiveness.