Test Suite Minimization (TSM) reduces the size of test suites while preserving their fault detection capability. In black-box TSM, reduction is performed without relying on production-code instrumentation. While several black-box TSM approaches have explored metrics like test logs or test similarity, these often suffer from scalability and efficiency issues. Recently, change history has been explored as a lightweight and scalable indicator for guiding black-box TSM. However, existing approaches treat historical modifications uniformly, ignoring the temporal dynamics of software evolution where recently modified code tends to be more fault-prone. To address this limitation, we introduce temporal modeling into black-box TSM and propose Temporal Risk-driven Test Suite Minimization (TRTM). TRTM extracts modification history from version-control metadata and applies exponential temporal attenuation to weight changes based on recency, producing time-weighted class-level risk scores that reflect fault-proneness. Next, it determines dependencies between test cases and production classes by constructing static call graphs derived solely from test code, preserving the black-box setting. The risk scores of the classes exercised by each test case are then aggregated using statistical measures such as Average and Geometric Mean to compute a risk score for the test case. Finally, test cases with the highest risk scores are selected to construct the reduced suite. Evaluation on a large dataset containing 14 projects with 631 versions shows that TRTM consistently outperforms the state-of-the-art baseline, achieving a mean Accuracy of 0.72 (vs. 0.66) and Fault Detection Rate (FDR) of 0.75 (vs. 0.69), while also reducing execution time.

Watermarking has become a crucial technique for ensuring provenance and accountability in AI-generated source code. As large language models (LLMs) are increasingly integrated into development workflows, reliable attribution remains challenging. In practice, most developers rely on commercial LLM APIs operating under black-box constraints, making existing approaches that require access to the decoding process less feasible for real-world integration. To address this limitation, we propose PromptMark, a black-box, prompt-guided watermarking framework that embeds invisible yet statistically detectable signals into generated code via structured input instructions. The method steers models toward subtle identifier and comment naming patterns while preserving the functional correctness and structural integrity of the generated code. Detection is performed using statistical tests designed to remain reliable across varying code lengths and model outputs. The embedding is further refined through an iterative feedback loop, where prompts are updated based on watermark detection scores. Experiments on the MBPP and HumanEval benchmarks show that PromptMark consistently achieves strong watermark detectability while maintaining high code correctness, outperforming baseline approaches.

Responsive Layout Failures (RLFs) typically arise from CSS properties that hinder proper layout behavior in different screen sizes. To find an accurate and effective solution for repairing RLFs, localization of those problematic properties is necessary. However, existing approaches only detect RLFs and apply broad CSS patches for them. The patches alter the entire layout without localizing the root cause of failure. To address this gap, we propose a heuristic approach to identify the specific CSS properties that developers would typically localize manually. The approach first detects the RLFs existing in a webpage and their affected elements. Next, it localizes the nearby HTML elements using RLF direction and relative alignment of the elements present in the RLF region. The involved CSS properties of those elements are then identified using a ranked search set of CSS properties, created by analyzing Quora and Stack Overflow queries. Finally, elements and their corresponding property pairs are ranked based on their impact on RLFs. We have implemented this approach into a tool called {\normalfont \textsc{LocaliCSS}} and evaluated it on a set of webpages using Top N Rank, MRR and P@K metrics. The tool achieved localization accuracy ranging from 45.2% (Top-1) to 92.86% (Top-7), with an MRR of 76% and a P@3 of 77.13%. Additionally, experienced front-end engineers manually localized the RLFs as part of our evaluation. Their preferred CSS properties matched the suggestions from our approach in 42.86% of cases for Top-1 rankings and up to 90.48% for Top-7 rankings.

Responsive websites frequently experience distorted layouts at specific screen sizes, called Responsive Layout Failures (RLFs). Manually repairing these RLFs involves tedious trial-and-error adjustments of HTML elements and CSS properties. In this study, an automated repair approach, leveraging LLM combined with domainspecific knowledge is proposed. The approach is named ReDeFix, a Retrieval-Augmented Generation (RAG)-based solution that utilizes Stack Overflow (SO) discussions to guide LLM on CSS repairs. By augmenting relevant SO knowledge with RLF-specific contexts, ReDeFix creates a prompt that is sent to the LLM to generate CSS patches. Evaluation demonstrates that our approach achieves an$\text{8 8 \%}$accuracy in repairing RLFs. Furthermore, a study from software engineers reveals that generated repairs produce visually correct layouts while maintaining aesthetics.

Code comprehension and analysis of open-source project codebases is a task frequently performed by developers and researchers. However, existing tools that practitioners use for assistance with such tasks often require prior project setup, lack context-awareness, and involve significant manual effort. To address this, we present CLARA, a browser extension that utilizes state-of-the-art inference model to assist developers and researchers in: (i) comprehending code files and code fragments, (ii) code refactoring, and (iii) code quality attribute detection. We qualitatively evaluated CLARA’s inference model using existing datasets and methodology, and performed a comprehensive user study with 10 developers and academic researchers to assess its usability and usefulness. The results show that CLARA is useful, accurate, and practical in code comprehension and analysis tasks. CLARA is an open-source tool available at github.com/clara_tool_demo. A video showing the full capabilities of CLARA can be found at youtube.com/clara_demo_video.

Black-box Test Suite Minimization (TSM) aims to remove redundant test cases from a test suite while retaining its fault detection capability without analyzing the production code. This makes it particularly efficient to be used in industry projects. These techniques utilize metrics such as test history, commit complexity or test code diversity (or similarity) to guide test case selection. Similarly, change-proneness (CP) can also guide to successful test case selection as it indicates the likelihood of having faults. We propose CP as a metric for TSM and implement into an approach, Change-proneness based Test suite Minimization (CTM), where relationships between test cases and their depending classes are measured using CP values. CTM first calculates class-level CP, followed by identifying the dependency between the test cases and classes. Then the association between test cases and their related classes are calculated using various statistical measures such as geometric mean etc. Finally test cases with the highest association values are selected. To demonstrate the effectiveness and efficiency of CP as a TSM metric, we compared CTM with state of the art, AST-based Test case Minimizer (ATM) on 15 Java projects with 617 versions. The experimental results demonstrate that CTM achieves the same average fault detection accuracy as ATM (0.67) while reducing execution time by 114.5 folds.

ABSTRACT Context Code smells are indicators of poor design and implementation choices that negatively affect software quality and maintainability. Moreover, it is difficult and time‐consuming to work with a long list of the code smells, as not all of those smells have equal impact on the system. So, understanding the individual impact of the code smells is significant while performing refactorings on a priority basis. Objective Despite significant research efforts aimed at detecting and refactoring these code smells, understanding their individual impact on software quality metrics such as size, complexity, coupling, etc. remains still unclear. Methodology To mitigate this research gap, we present an empirical investigation on the impact analysis of code smells based on the 25 software quality metrics such as size, cyclomatic complexity, coupling, etc. To the best of our knowledge, this is the largest empirical study about the impact analysis of code smells with respect to the number of software metrics. Particularly for this study, we identify 13 code smells in 35 open‐source software systems, and analyze (1) the relationship between code smells and software metrics, (2) which code smells are highly impactful that affect the metrics, and (3) which impactful smells occur frequently in the systems. Results The results show varying degrees of correlation‐based impact between specific code smells and software metrics, with some smells showing strong correlations with multiple metrics. Three categories of impact for the code smells have been identified, namely High, Moderate and Low, where Long Method, Anti Singleton, Complex Class, Large Class and Long Parameter List smells have high impact, but their frequencies are not high except Anti Singleton; Refused Parent Bequest, Spaghetti Code and Blob have moderate impact; and rest of the smells have low impact. We also observe that perceptions about the impact of code smells vary from developer to developer and they most cases refactor the smells based on their intuition. Conclusion Our findings will help them to refactor the smells on an objective‐based instead of an intuition‐based, which will be more significant to improve the software quality. For example, refactoring the smells having a high impact on the coupling between objects metric can be an objective. Furthermore, our results will not only assist developers in prioritizing refactoring activities but also provide researchers with valuable insights to innovate tools that prioritize refactoring based on the impact of code smells. These tools will help developers target the most impactful smells and thus enhance the overall quality and maintainability of software systems.

Software vulnerabilities are flaws in a product that compromise system security. In large software systems, developers struggle to find particular vulnerable statements from vulnerable functions when new vulnerabilities arise. Existing research underutilizes the potential of vulnerability reports which provides vital context for identifying vulnerable functions and their corresponding statements in source code. The paper introduces VFSDetector, an information retrieval-based approach for Vulnerable Functions and Statements Detection in source code using vulnerability reports. It adapts the Vector Space Model to compare vulnerability report text with source code. Initial evaluation on 10 reports from seven open-source projects show VFSDetector accurately identifies the genuine vulnerable function as the 1st function in 40% of cases and particular vulnerable statements in 20% of cases. It ranks the actual vulnerable function within the top five in 90% of cases and vulnerable statements in the top fifteen in 70% of cases. These findings can assist developers in patching vulnerable statements more quickly.

Recent advancements in deep neural network have enhanced the capabilities of User Interface (UI) element identification models. However, these models often struggle to accurately identify and classify elements in complex backgrounds and overlapping components. This study proposes NeuroUI, an automated testing approach that introduces structurally consistent Metamorphic Relation (MR) design to make the UI detection models robust. The approach introduces six MRs including Text Language, Text Emoji, Emotive Text Style, Component Occlusion, Geometric Background and Text Overlap which are applied to original seed snapshots to create perturbed snapshots. These are used to form a test oracle where at least one of the elements is classified wrong. When evaluated on four models namely SSD, FCOS, YOLOv5, and Faster R-CNN, NeuroUI achieved an increase in Error Finding Rates (EFR) up to 27.9, 29.4, 34.5, and 32.6 percentage points respectively. Retraining these models with the generated test oracle reduced EFR significantly up to 30.2 percentage points on average for our trained models when tested on 30 real-world applications from the Google Play Store.

Dark patterns manipulate user choices through deceptive UI tactics. Any automated detection technique for dark patterns must address the varying nature of dark patterns. Existing detection techniques need manual intervention in some cases. In other cases, techniques are not generalized due to overfitting problems; for example, these techniques can not handle cases where texts are semantically similar but possess lexical differences. We propose an automated dark pattern text detection technique that is generalized. We synthesize inclusive definitions of dark pattern categories. This contextual information is prioritized using in-context learning capabilities of GPT-3 to detect and classify dark pattern texts. Results show that our technique offers satisfactory performance for 6 out of 7 dark pattern categories explored in this study. We also validate the improved generalization capability of our technique by outperforming an existing baseline model on a test dataset.

Fault-proneness is an indication of programming errors that decreases software quality and maintainability. On the contrary, code smell is a symptom of potential design problems which has impact on fault-proneness. In the literature, negative impact of code smells on fault-proneness has been investigated. However, it is still unclear that how frequency of each code smell type impacts the fault-proneness. To mitigate this research gap, we present an empirical study to identify whether frequency of individual code smell types has a relationship with the fault-proneness. The results show that Anti Singleton, Blob and Class Data Should Be Private smell types have strong relationship with fault-proneness though their frequencies are not very high. On the other hand, comparatively high frequent code smell types such as Complex Class, Large Class and Long Parameter List have moderate relationship with fault-proneness. These findings will assist developers to prioritize and refactor code smells to improve software quality.

Automated End-to-End (E2E) web testing is a key component in modern rapid development to validate system functionality. However, there are no resources supporting practitioners on how diverse scenarios are tested manually. This paper presents WebEV, a dataset containing E2E test cases from open-source popular projects. Projects are selected based on - i) Cypress-based automation, ii) popularity on GitHub and iii) executability of test cases. The dataset contains information regarding each test command along with the incurred state change representation. Snapshots of the application are used to retrieve - i) the current URL of the application, ii) the screenshot and HTML text of the entire page, and iii) the screenshot and HTML text of an operated UI element. This process is done both before and after each command execution to capture the perception of testers on each state transition, i.e., extract their thought process during testing. This dataset can assist the research community to model user web interaction, predicting the tester’s perception, and improving the state of automated testing approaches. Moreover, WebEV can be used to mine how automated approaches differ from real-life E2E test scenarios.

Web application failure detection relies mostly on the tester’s creativity, leaving test automation to only ease executing repetitive tasks. Existing automated testing techniques opt for test path diversity or input generation but not the tester’s behavioral patterns. For example, testing deeply nested business logic, proper form submission, or non-redundant navigation are not considered. This paper proposes eBAT, an automated testing approach that considers those testers’ interaction patterns from observation. A behavior-driven action selection strategy is derived from these patterns to interact with the system. Actionable elements (buttons, links, inputs, etc.) obtained through state abstraction and interaction pattern-wise grouping are operated in a tree-based manner. The effectiveness and efficiency of eBAT are evaluated as the unique number of failures detected and the detection rate respectively. Results compared against the state-of the-art indicate significant improvement in failure detection with similar code coverage. Moreover, eBAT outperforms the baseline failure detection rate in 5 out of 6 benchmark projects.

Community smells are organizational and social anti-patterns in the development community that need to be refactored. In the literature, studies on community smell refactoring are found from the very conceptual level. However, little is known about the practitioners’ perceptions, refactoring readiness and the refactoring strategies adopted in local software communities. This paper bridge this gap by exploring these issues in the software industry of Bangladesh. A depth interview-based study was conducted on local software practitioners chosen through a convenience sample recruitment strategy. Interviews were transcribed and analyzed using Straussian Grounded Theory. We collected data on the four prominent smells according to literature and introduced a new measure called ‘Refactoring Readiness’ to calculate the community smell refactoring preparedness of a software development community. Analyzing the data, it is seen that 85% local practitioners perceive community smells as harmful but less than half take step to mitigate those smells. We identified the refactoring strategies (e.g. creating a structured communication plan, mentoring) currently adopted by them and found that the Refactoring Readiness of the software industry of Bangladesh is 0.63 on a scale of 0-1. This provides evidence that more work needs to be done for refactoring community smells from the local sub-optimal development communities.

Background: Reusing source code containing code smells can induce significant amount of maintenance time and cost. A list of code smells has been identified in the literature and developers are encouraged to avoid the smells from the very beginning while writing new code or reusing existing code, and it increases time and cost to identify and refactor the code after the development of a system. Again, remembering a long list of smells is difficult specially for the new developers. Besides, two different types of software development environment - open source and industry, might have an effect on the occurrences of code smells. Aims: A study on the occurrences of code smells in open source and industrial systems can provide insights about the most frequently occurring smells in each type of software system. The insights can make developers aware of the most frequent occurring smells, and researchers to focus on the improvement and innovation of automatic refactoring tools or techniques for the smells on priority basis. Method: We have conducted a study on 40 large scale Java systems, where 25 are open source and 15 are industrial systems, for 18 code smells. Results: The results show that 6 smells have not occurred in any system, and 12 smells have occurred 21,182 times in total where 60.66% in the open source systems and 39.34% in the industrial systems. Long Method, Complex Class and Long Parameter List have been seen as frequently occurring code smells. The one tailed t-test with 5% level of significant analysis has shown that there is no difference between the occurrences of 10 code smells in industrial and open source systems, and 2 smells are occurred more frequently in open source systems than industrial systems. Conclusions: Our findings conclude that all smells do not occur at the same frequency and some smells are very frequent. The short list of most frequently occurred smells can help developers to write or reuse source code carefully without inducing the smells from the beginning during software development. Our study also concludes that industry and open source environments do not have significant impact on the occurrences of code smells.

This dataset contains 246 bugs, their fixes and corresponding buggy projects from historical bug fixes dataset (https://github.com/xuanbachle/data-bugfixes) that fulfill the following criteria:\n\n\n\tUnique\n\tSatisfy redundancy assumption at file level\n\tFixed by applying replacement mutation\n\tRequire fixing at expression level\n\tHaving available project and dependency files\n\n\nFor details, please view https://www.scitepress.org/Link.aspx?doi=10.5220/0009411301700180

The outcome of software products primarily depends on the developers, including their emotion or sentiment in a software development environment. Developer emotions have been observed to be correlated to several patterns, for instance, task resolution time, developer turnover, etc. by conducting sentiment analysis on software collaborative artifacts like Commits. This study aims to quantify the impact of those patterns by finding a relation between developer sentiment and software bugs. To do so, Fix-Inducing Changes — changes that introduce bugs to the system — are detected, along with changes that precede or fix those bugs. Sentiment of these changes are determined from their Commit messages using Senti4SD. It is statistically observed that Commits that introduce, precede or fix bugs are significantly more negative than regular Commits, with a higher proportion of emotional (non-neutral) messages. It is also found that a distinction between buggy and correct fixes exists based on the message's neutrality.

Developer emotion or sentiment in a software development environment has the potential to affect performance, and consequently, the software itself. Sentiment analysis, conducted to analyze online collaborative artifacts, can derive effects of developer sentiment. This study aims to understand how developer sentiment is related to bugs, by analyzing the difference of sentiment between regular and Fix-Inducing Changes (FIC) - changes to code that introduce bugs in the system. To do so, sentiment is extracted from Pull Requests of 6 well known GitHub repositories, which contain both code and contributor discussion. Sentiment is calculated using a tool specializing in the software engineering domain: SentiStrength-SE. Next, FICs are detected from Commits by filtering the ones that fix bugs and tracking the origin of the code these remove. Commits are categorized based on FICs and assigned separate sentiment scores (-4 to +4) based on different preceding artifacts - Commits, Comments and Reviews from Pull Requests. The statistical result shows that FICs, compared to regular Commits, contain more positive Comments and Reviews. Commits that precede an FIC have more negative messages. Similarly, all the Pull Request artifacts combined are more negative for FICs than regular Commits.

Change Coupling (CC) is the implicit relation formed between two or more changing software artifacts (e.g. source code). These artifacts are found to have design issues and code smells. Existing research has revealed the relationship between the change coupled relation of a class with the number of bugs in bug repositories. However, this ignored their true relation at the creation time of bugs or erroneous changes known as Fix-Inducing Changes (FIC). This paper tries to find the actual relationship between FIC and change coupled relations with respect to considering recent and all commits. This is done by traversing the entire history of a repository with a commit window of 100 commits and collecting data about FICs and metrics related to change coupling and object oriented system. It is found from the analysis that recent CC relations at the time of error are more correlated with new errors. Besides, it is found that explanatory power for predicting future erroneous change is more in recent CC relation than the one formed by considering all commits starting from the 1st commit.

Patch prioritization means sorting candidate patches based on probability of correctness. It helps to minimize the bug fixing time and maximize the precision of an automated program repairing technique. Approaches in the literature use either syntactic or semantic similarity between faulty code and fixing element to prioritize patches. Unlike others, this paper aims at analyzing the impact of combining syntactic and semantic similarities on patch prioritization. As a pilot study, it uses genealogical and variable similarity to measure semantic similarity, and normalized longest common subsequence to capture syntactic similarity. For evaluating the approach, 22 replacement mutation bugs from IntroClassJava benchmark were used. The approach repairs all the 22 bugs and achieves a precision of 100%.

During the gradual process of software evolution, errors appear in different components of a software system.These errors are later on fixed by developers as part of corrective maintenance activities.However, if errors appear continuously from a particular component, that may indicate design flaws or code smells.Maintenance cost will greatly reduce if design flaws are treated as early as possible.To find out such flaws it may require time-consuming manual inspections.This paper tries to find out such components using the information of change coupled cluster of files or Java classes at fix-inducing changes.In this proposed approach, information (like class, method, parameter of method and variable names) from change coupled relation of a class at Fix-Inducing Changes (FICs) are used to provide information about erroneous components.Then the error history, of software components, is found by using cosine similarity of information from change coupled cluster of classes found in FICs to see with the architectural information found from authenticated sources.Finally, the error history of components is shown as the percentage of change coupled cluster of a class found in FICs of each 100 commits in the version control system.

Agile method emphasizes on the people factors and strength of teamwork that simplify the development process. A highly productive team throughout an agile software development process is very instrumental in achieving project success. Consequently, understanding of how individual behaviour and productivity are affected by teamwork within an agile team becomes critical. Identifying factors that impact productivity will result in improvement of teamwork. Hence, a need emerges to recognise the significant ones. Doing so will enable project team management to determine the areas where to concentrate efforts in order to improve productivity. The objective of this research is to identify and analyse agile teamwork productivity influence factors by using system dynamics (SD) approach. Identification of main factors influencing productivity and how they impact agile teamwork are carried out through interviews, survey and literature review. From the perspective of agile team members, the four most perceived factors impacting on their productivity are team effectiveness, team management, motivation and customer satisfaction. Lack of agile team management support is found to be the most mentioned reason for failed agile project. The complex interrelated structure of different factors affecting agile teamwork productivity is modeled using influence diagram and Causal Loop Diagram (CLD) for qualitative analysis.

Code cloning is a common code reusing technique that occurs when developers replicate similar pieces of code fragments within or between software repositories. Another replication happens when developers repeat method interfaces (i.e., method name, return and parameter types). Two methods are prone to be cloned when those have similar interfaces and perform similar functionalities. Considering this, a new lightweight Interface Driven Code Clone Detection (IDCCD) technique is proposed, that can detect clones by using method interface similarities. First, the method blocks are tokenized from the source files. For those method block tokens, interface information is extracted and indexed with mapped tokens. Then, similar interfaces are queried from that index and compared those with a similarity function for detecting clones. IDCCD is evaluated with other state of the art techniques by using BigCloneEval framework. The experimental results show that IDCCD performs similar comparing to other existing tools with a lower complexity.

Developers need to put lots of time and effort to reuse the code snippets retrieved by the existing code search engines. The reason is that these engines do not provide self-executable, functionally correct and easily understandable code snippets as search results. Developers manually resolve all the dependencies to make the code snippets executable in their development contexts. They have to write and execute the same test cases many times to check the correctness of the code fragments. In this paper, a technique has been proposed that converts each method in a code base into self-executable method (i.e., program slice) by resolving method calls, data and library dependencies. To ensure that the methods are functionally correct, automatic test scripts are generated and executed for each self-executable method based on the branch, statement, and path coverage. The understandability of the code fragments is increased by replacing irrelevant textual keywords with relevant words. All the self-executable code fragments are indexed using traditional Information Retrieval approach. So, when a user query is submitted, the technique will retrieve self-executable and functionally correct code snippets.

In automatic software bug localization, source code analysis is usually used to localize the buggy code without manual intervention. However, due to considering irrelevant source code, localization accuracy may get biased. In this paper, a Method level Bug localization using Minimized search space (MBuM) is proposed for improving the accuracy, which considers only the liable source code for generating a bug. The relevant search space for a bug is extracted using the execution trace of the source code. By processing these relevant source code and the bug report, code and bug corpora are generated. Afterwards, MBuM ranks the source code methods based on the textual similarity between the bug and code corpora. To do so, modified Vector Space Model (mVSM) is used which incorporates the size of a method with Vector Space Model. Rigorous experimental analysis using different case studies are conducted on two large scale open source projects namely Eclipse and Mozilla. Experiments show that MBuM outperforms existing bug localization techniques.