ICSE 2024
Fri 12 - Sun 21 April 2024 Lisbon, Portugal

Accepted Papers

A Comprehensive Study of Learning-based Android Malware Detectors under Challenging Environments
Research Track
A Large-Scale Survey on the Usability of AI Programming Assistants: Successes and Challenges
Research Track
Attention! Your Copied Data is Under Monitoring: A Systematic Study of Clipboard Usage in Android Apps
Research Track
BinAug: Enhancing Binary Similarity Analysis with Low-Cost Input Repairing
Research Track
Block-based Programming for Two-Armed Robots: A Comparative Study
Research Track
DOI Pre-print Media Attached
BOMs Away! Inside the Minds of Stakeholders: A Comprehensive Study of Bills of Materials for Software Systems
Research Track
Characterizing Software Maintenance Meetings: Information Shared, Discussion Outcomes, and Information Captured
Research Track
Co-Creation in Fully Remote Software Teams
Research Track
CoderEval: A Benchmark of Pragmatic Code Generation with Generative Pre-trained Models
Research Track
CrashTranslator: Automatically Reproducing Mobile Application Crashes Directly from Stack Trace
Research Track
Dataflow Analysis-Inspired Deep Learning for Efficient Vulnerability Detection
Research Track
Deep Learning or Classical Machine Learning? An Empirical Study on Log-Based Anomaly Detection
Research Track
Deeply Reinforcing Android GUI Testing with Deep Reinforcement Learning
Research Track
DEMISTIFY: Identifying On-device Machine Learning Models Stealing and Reuse Vulnerabilities in Mobile Apps
Research Track
Demystifying Compiler Unstable Feature Usage and Impacts in the Rust Ecosystem
Research Track
Detecting Logic Bugs in Graph Database Management Systems via Injective and Surjective Graph Pattern Transformation
Research Track
Do Automatic Test Generation Tools Generate Flaky Tests?
Research Track
DocFlow: Extracting Taint Specifications from Software Documentation
Research Track
Domain Knowledge Matters: Improving Prompts with Fix Templates for Repairing Python Type Errors
Research Track
ECFuzz: Effective Configuration Fuzzing for Large-Scale Systems
Research Track
EDEFuzz: A Web API Fuzzer for Excessive Data Exposures
Research Track
EGFE: End-to-end Grouping of Fragmented Elements in UI Designs with Multimodal Learning
Research Track
Enabling Runtime Verification of Causal Discovery Algorithms with Automated Conditional Independence Reasoning
Research Track
Exploring the Potential of ChatGPT in Automated Code Refinement: An Empirical Study
Research Track
FAIR: Flow Type-Aware Pre-Training of Compiler Intermediate Representations
Research Track
Fine-SE: Integrating Semantic Features and Expert Features for Software Effort Estimation
Research Track
FuzzSlice: Pruning False Positives in Static Analysis Warnings through Function-Level Fuzzing
Research Track
DOI Pre-print
How do Developers Talk about GitHub Actions? Evidence from Online Software Development Community
Research Track
How to Support ML End-User Programmers through a Conversational Agent
Research Track
Improving Testing Behavior by Gamifying IntelliJ
Research Track
Inferring Data Preconditions from Deep Learning Models for Trustworthy Prediction in Deployment
Research Track
ITER: Iterative Neural Repair for Multi-Location Patches
Research Track
It's Not a Feature, It's a Bug: Fault-Tolerant Model Mining from Noisy Data
Research Track
Kind Controllers and Fast Heuristics for Non-Well-Separated GR(1) Specifications
Research Track
KnowLog: Knowledge Enhanced Pre-trained Language Model for Log Understanding
Research Track
Large Language Models are Edge-Case Generators: Crafting Unusual Programs for Fuzzing Deep Learning Libraries
Research Track
Large Language Models are Few-Shot Summarizers: Multi-Intent Comment Generation via In-Context Learning
Research Track
Large Language Models for Test-Free Fault Localization
Research Track
Learning and Repair of Deep Reinforcement Learning Policies from Fuzz-Testing Data
Research Track
Learning-based Widget Matching for Migrating GUI Test Cases
Research Track
LibvDiff: Library Version Difference Guided OSS Version Identification in Binaries
Research Track
LogShrink: Effective Log Compression by Leveraging Commonality and Variability of Log Data
Research Track
Marco: A Stochastic Asynchronous Concolic Explorer
Research Track
Modularizing while Training: a New Paradigm for Modularizing DNN Models
Research Track
Novelty Begets Popularity, But Curbs Participation - A Macroscopic View of the Python Open-Source Ecosystem
Research Track
NuzzleBug: Debugging Block-Based Programs in Scratch
Research Track
Object Graph Programming
Research Track
On the Helpfulness of Answering Developer Questions on Discord with Similar Conversations and Posts from the Past
Research Track
On Using GUI Interaction Data to Improve Text Retrieval-based Bug Localization
Research Track
PonziGuard: Detecting Ponzi Schemes on Ethereum with Contract Runtime Behavior Graph (CRBG)
Research Track
Practical Program Repair via Preference-based Ensemble Strategy
Research Track
Predicting open source contributor turnover from value-related discussions: An analysis of GitHub issues
Research Track
Predicting Performance and Accuracy of Mixed-Precision Programs for Precision Tuning
Research Track
Prompting Is All Your Need: Automated Android Bug Replay with Large Language Models
Research Track
Reorder Pointer Flow in Sound Concurrency Bug Prediction
Research Track
Resource Usage and Optimization Opportunities in Workflows of GitHub Actions
Research Track
Revealing Hidden Threats: An Empirical Study of Library Misuse in Smart Contracts
Research Track
RUNNER: Responsible UNfair NEuron Repair for Enhancing Deep Neural Network Fairness
Research Track
SCTrans: Constructing a Large Public Scenario Dataset for Simulation Testing of Autonomous Driving Systems
Research Track
Semantic Analysis of Macro Usage for Portability
Research Track
Smart Contract and DeFi Security Tools: Do They Meet the Needs of Practitioners?
Research Track
Toward Automatically Completing GitHub Workflows
Research Track
Toward Improved Deep Learning-based Vulnerability Detection
Research Track
Towards Reliable AI: Adequacy Metrics for Ensuring the Quality of System-level Testing of Autonomous Vehicles
Research Track
TRACED: Execution-aware Pre-training for Source Code
Research Track
UniLog: Automatic Logging via LLM and In-Context Learning
Research Track
Unveiling the Life Cycle of User Feedback: Best Practices from Software Practitioners
Research Track
VeRe: Verification Guided Synthesis for Repairing Deep Neural Networks
Research Track

Call for papers

The International Conference on Software Engineering (ICSE) is the premier forum for presenting and discussing the most recent and significant technical research contributions in the field of Software Engineering. In the research track, we invite high-quality submissions of technical research papers describing original and unpublished results of software engineering research.

Please note the following important changes for 2024:

  1. In 2024, ICSE will follow a dual deadline structure for submission of papers. In other words, submissions will occur in two cycles. This is the most important change. Please refer to the section on Dual Submission Cycles in the following for the information.

  2. For each paper submitted to Research track in ICSE 2024, authors will need to choose one of seven focus areas. Please see the section on Research Areas in the following.

Research Areas

ICSE welcomes submissions addressing topics across the full spectrum of Software Engineering, being inclusive of quantitative, qualitative, and mixed-methods research. Topics of interest include the following and are grouped into the following seven research areas.

Each submission will need to indicate one of these seven areas as the chosen area. Optionally, the authors can consider adding an additional area. A paper may be moved from the chosen area(s) to another focus area at the discretion of the program chairs. Program chairs will ultimately assign a paper to an area chair, considering the authors’ selection, the paper’s content, and other factors such as (if applicable) possible conflicts of interest.

AI and software engineering, Auto-coding

  • SE for Machine learning systems
  • Machine learning for SE tasks
  • Recommender systems
  • Autonomic systems and self-healing systems
  • Program synthesis
  • Program repair
  • AI for DevOps
  • Code generation from machine learning models


  • Mining software repositories, communication platforms, and novel software engineering data sources
  • Apps and app store analysis
  • Software ecosystems
  • Configuration management
  • Software visualization
  • Data-driven user experience understanding and improvement
  • Data driven decision making in software engineering

Dependability and Security

  • Formal methods
  • Model Checking
  • Reliability and Safety
  • Vulnerability detection to enhance software security
  • System design to enhance software security
  • Privacy, Robustness, Fairness: Checking and Enforcement
  • Embedded and cyber-physical systems: modeling and validation


  • Evolution and maintenance
  • API design and evolution
  • Release engineering and DevOps
  • Software reuse
  • Refactoring and program differencing
  • Program comprehension
  • Reverse engineering
  • Environments and software development tools
  • Traceability to understand evolution

Human and Social aspects

  • Human and organizational aspects of software engineering
  • Interaction in programming environments and software engineering tools
  • Distributed and collaborative software engineering
  • Agile methods and software processes
  • Software economics
  • Community-based software engineering (e.g., open source, crowdsourcing)
  • Ethics in software engineering
  • Green and sustainable technologies
  • Research on diversity, inclusion and social issues in software engineering

Requirements and modeling

  • Requirements Engineering (incl. non-functional requirements)
  • Design for quality, including privacy and security by design
  • Feedback, user and requirements management
  • Modelling and Model-Driven Engineering
  • Software Architecture and Design
  • Variability and product lines
  • Systems and software traceability
  • Software services and cloud-based systems

Testing and analysis

  • Software testing
  • Program analysis
  • Debugging and fault localization
  • Programming languages: developer-centric issues
  • Automated test generation techniques such as search and symbolic execution
  • Testing and analysis of non-functional properties
  • GUI testing
  • Mobile application testing


Since the authors will choose an area for their submission, the scope of each area becomes important. Some submissions may relate to multiple areas. In such cases, the authors should choose the area for which their paper brings the maximum new insights. Moreover, authors also have the choice of indicating an alternate area for each paper.

Similarly, for certain papers. authors may have a question whether it belongs to any area, or it is simply out of scope. For such cases, we recommend the authors to judge whether their paper brings new insights for software engineering. As an example, a formal methods paper with a focus on hardware verification may be deemed out of scope for ICSE. In general, papers which only peripherally concern software engineering and do not give new insights from the software engineering perspective would be less relevant to ICSE. Our goal is however to be descriptive, rather than prescriptive, to enable authors to make their own decisions about relevance.

Dual Submission Cycles – New for ICSE 2024

Since ICSE 2024 will have a different timeline from previous ICSEs, we request authors to kindly take note of the dates. The dates for the two submission cycles are as follows

First submission cycle

  • Submission: March 29, 2023
  • Notification: June 2, 2023
  • Revision due: July 10, 2023
  • Final Decisions: August 24, 2023
  • Camera-ready: Sept 15, 2023

Second submission cycle

  • Submission: August 1, 2023
  • Notification: October 10, 2023
  • Revision due: Nov 17, 2023
  • Final Decisions: Dec 15, 2023
  • Camera ready: Jan 12, 2024

Papers accepted for the first submission cycle of ICSE 24 will be available in the ACM and IEEE Digital Libraries after the camera-ready deadline of September 15 2023. Once papers have been reviewed, authors will be able to see the full reviews, including the reviewer scores. There is no rebuttal phase for either cycle.

Review Criteria

Each paper submitted to the Research Track will be evaluated based on the following criteria:

i) Novelty: The novelty and innovativeness of contributed solutions, problem formulations, methodologies, theories and/or evaluations, i.e., the extent to which the paper is sufficiently original with respect to state-of-the-art.

ii) Rigor: The soundness, clarity and depth of a technical or theoretical contribution, and the level of thoroughness and completeness of an evaluation.

iii) Relevance: The significance and/or potential impact of the research to the field of software engineering.

iv) Verifiability and Transparency: The extent to which the paper includes sufficient information to understand how an innovation works; to understand how data was obtained, analyzed, and interpreted; and how the paper supports independent verification or replication of the paper’s claimed contributions. Any artifacts attached to or linked from the paper may be checked by one reviewer.

v) Presentation: The clarity of the exposition in the paper.

Reviewers will carefully consider all of the above criteria during the review process, and authors should take great care in clearly addressing them all. The paper should clearly explain and justify the claimed contributions. Each paper will be handled by an area chair who will ensure reviewing consistency among papers submitted within that area.

The outcome of each paper will be one of the following Accept, Conditional Accept, Revision, Reject. Note that papers which are Accepted straight-away may still involve changes by authors in the camera-ready version, but these changes will not be checked any further by PC. We now elaborate the Conditional Accept and the Revision outcomes in the following.

Conditional Accept

Authors of papers receiving a Conditional Accept decision are expected to submit the revised papers with changes marked in a different color, such as using LaTeXdiff. The authors also need to submit an “Author Response” document capturing the authors’ response to each reviewer comment and how those comments were addressed in the revision. This is similar to the “Summary of Changes and Response” document that is typically submitted by authors for a journal paper major revision. The reviewers will check the revised paper against the original paper and the suggested changes. Conditional Accepts will be checked by only one member of the Program Committee, and this will be done in one pass. We expect all papers receiving Conditional Accept to be accepted, even though this is not guaranteed.


Papers submitted can go through revisions in response to specific revision requests made by the reviewers. Authors of papers receiving a Revision decision are expected to submit the revised papers with changes marked in a different color, such as using LaTeXdiff. The authors also need to submit an “Author Response” document capturing the authors’ response to each reviewer comment and how those comments were addressed in the revision. This is similar to the “Summary of Changes and Response” document that is typically submitted by authors for a journal paper major revision. Authors may use the revision opportunity to revise and improve the paper, but should not use this to submit a substantially different paper. The reviewers will check the revised paper against the original paper and the suggested changes. Revised papers will be examined by the same set of reviewers. An unsatisfactory revised paper will be rejected.

Re-submissions of rejected papers

Authors of papers which receive a REJECT decision in the first submission cycle are strongly discouraged from re-submitting it to the second submission cycle. However, in exceptional cases where the authors feel that the reviewers misunderstood their paper, authors can re-submit their paper to the second submission cycle with a “Clarifications and Summary of Improvements” document stating how they have changed the paper. They should also include the past reviews as part of this document, for completeness. These papers will be treated as new submissions which may or may not get the same set of reviewers at the discretion of the PC chairs. Authors who try to bypass this guideline (e.g., by changing the paper title without significantly changing paper content, or by making small changes to the paper content) will have their papers desk-rejected by the PC chairs without further consideration. Papers rejected from the first or second submission cycle of ICSE2024 can be submitted to ICSE2025 without any restrictions.

Submission Process

All authors should use the official “ACM Primary Article Template”, as can be obtained from the ACM Proceedings Template page. LaTeX users should use the sigconf option, as well as the review (to produce line numbers for easy reference by the reviewers) and anonymous (omitting author names) options. To that end, the following LaTeX code can be placed at the start of the LaTeX document:


\acmConference[ICSE 2024]{46th International Conference on Software Engineering}{April 2024}{Lisbon, Portugal}

  • All submissions must not exceed 10 pages for the main text, inclusive of all figures, tables, appendices, etc. Two more pages containing only references are permitted. All submissions must be in PDF. Accepted papers will be allowed one extra page for the main text of the camera-ready version.
  • Submissions must strictly conform to the ACM conference proceedings formatting instructions specified above. Alterations of spacing, font size, and other changes that deviate from the instructions may result in desk rejection without further review.
  • By submitting to the ICSE Research Track, authors acknowledge that they are aware of and agree to be bound by the ACM Policy and Procedures on Plagiarism and the IEEE Plagiarism FAQ. Papers submitted to ICSE 2024 must not have been published elsewhere and must not be under review or submitted for review elsewhere whilst under consideration for ICSE 2024. Contravention of this concurrent submission policy will be deemed a serious breach of scientific ethics, and appropriate action will be taken in all such cases. To check for double submission and plagiarism issues, the chairs reserve the right to (1) share the list of submissions with the PC Chairs of other conferences with overlapping review periods and (2) use external plagiarism detection software, under contract to the ACM or IEEE, to detect violations of these policies.
  • By submitting your article to an ACM Publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies, including ACM's new Publications Policy on Research Involving Human Participants and Subjects. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy.
  • Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start and we have recently made a commitment to collect ORCID IDs from all of our published authors. The collection process has started and will roll out as a requirement throughout 2022. We are committed to improve author discoverability, ensure proper attribution and contribute to ongoing community efforts around name normalization; your ORCID ID will help in these efforts.
  • The ICSE 2024 Research Track will employ a double-anonymous review process. Thus, no submission may reveal its authors’ identities. The authors must make every effort to honor the double-anonymous review process. In particular:
    • Authors’ names must be omitted from the submission.
    • All references to the author’s prior work should be in the third person.
    • While authors have the right to upload preprints on ArXiV or similar sites, they must avoid specifying that the manuscript was submitted to ICSE 2024.
    • During review, authors should not publicly use the submission title. They should thus use a different paper title for any pre-print in arxiv or similar websites.
  • Further advice, guidance, and explanation about the double-anonymous review process can be found in the Q&A page from prior ICSEs.
  • By submitting to the ICSE Research Track, authors acknowledge that they conform to the authorship policy of the ACM, and the authorship policy of the IEEE.

Submissions to the Technical Track that meet the above requirements can be made via the Research Track submission site by the submission deadline. Any submission that does not comply with these requirements may be desk rejected without further review.

Submission site (second cycle August 2023): https://icse2024.hotcrp.com/

We encourage the authors to upload their paper info early (and can submit the PDF later) to properly enter conflicts for double-anonymous reviewing. It is the sole responsibility of the authors to ensure that the formatting guidelines, double anonymous guidelines, and any other submission guidelines are met at the time of paper submission.

Open Science Policy

The research track of ICSE 2024 is governed by the ICSE 2024 Open Science policies. The guiding principle is that all research results should be accessible to the public and, if possible, empirical studies should be reproducible. In particular, we actively support the adoption of open artifact and open source principles. We encourage all contributing authors to disclose (anonymized and curated) data/artifacts to increase reproducibility and replicability. Note that sharing research artifacts is not mandatory for submission or acceptance. However, sharing is expected to be the default, and non-sharing needs to be justified. We recognize that reproducibility or replicability is not a goal in qualitative research and that, similar to industrial studies, qualitative studies often face challenges in sharing research data. For guidelines on how to report qualitative research to ensure the assessment of the reliability and credibility of research results, see this previously curated Q&A page.

Upon submission to the research track, authors are asked

  • to make their artifact available to the program committee (via upload of supplemental material or a link to an anonymous repository) – and provide instructions on how to access this data in the paper; or

  • to include in the paper an explanation as to why this is not possible or desirable; and

  • to indicate why they do not intend to make their data or study materials publicly available upon acceptance, if that is the case. The default understanding is that the data and/or other artifacts will be publicly available upon acceptance of a paper.

Withdrawing a Paper

Authors can withdraw their paper at any moment until the final decision has been made, through the paper submission system. Resubmitting the paper to another venue before the final decision has been made without withdrawing from ICSE 2024 first is considered a violation of the concurrent submission policy, and will lead to automatic rejection from ICSE 2024 as well as any other venue adhering to this policy. Such violations may also be reported to appropriate organizations e.g. ACM and IEEE.

Conference Attendance Expectation

If a submission is accepted, at least one author of the paper is required to register for ICSE 2024 and present the paper. We are assuming that the conference will be in-person, and if it is virtual or hybrid, virtual presentations may be possible. These matters will be discussed with authors closer to the date of the conference.