The ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA) is the leading research symposium on software testing and analysis, bringing together academics, industrial researchers, and practitioners to exchange new ideas, problems, and experience on how to analyze and test software systems. ISSTA’18 will be co-located with the European Conference on Object-Oriented Programming (ECOOP ’18), and with Curry On, a conference focused on programming languages & emerging challenges in industry.

The ISSTA proceedings are available here.

Accepted Papers

	Title
	Analyzing the Analyzers: FlowDroid/IccTA, AmanDroid, and DroidSafe ISSTA Technical Papers Lina Qiu, Yingying Wang, Julia Rubin
	An Empirical Study on TensorFlow Program Bugs ISSTA Technical Papers Yuhao Zhang, Yifan Chen, Shing-Chi Cheung, Yingfei Xiong, Lu Zhang Pre-print
	Automated Test Mapping and Coverage for Network Topologies ISSTA Technical Papers Per Erik Strandberg, Thomas Ostrand, Elaine Weyuker, Daniel Sundmark, Wasif Afzal
	Automatically Translating Bug Reports into Test Cases for Mobile Apps ISSTA Technical Papers Mattia Fazzini, Martin Prammer, Marcelo d'Amorim, Alessandro Orso
	Badger: Complexity Analysis with Fuzzing and Symbolic Execution ISSTA Technical Papers Yannic Noller, Rody Kersten, Corina S. Păsăreanu
	Bench4BL: Reproducibility Study on the Performance of IR-Based Bug Localization ISSTA Technical Papers Jaekwon Lee, Dongsun Kim, Tegawendé F. Bissyandé, Woosung Jung, Yves Le Traon
	CiD: Automating the Detection of API-related Compatibility Issues in Android Apps ISSTA Technical Papers Li Li, Tegawendé F. Bissyandé, Haoyu Wang, Jacques Klein
	Comparing developer-provided to user-provided tests for fault localization and automated program repair ISSTA Technical Papers René Just, Chris Parnin, Ian Drosos, Michael D. Ernst
	Compiler Fuzzing through Deep Learning ISSTA Technical Papers Chris Cummins, Pavlos Petoumenos, Alastair Murray, Hugh Leather
	Deep Specification Mining ISSTA Technical Papers Tien-Duy B. Le, David Lo
	Eliminating Timing Side-channel Leaks Using Program Repair ISSTA Technical Papers Meng Wu, Shengjian (Daniel) Guo, Patrick Schaumont, Chao Wang
	Evaluating Test-Suite Reduction in Real-World Software Evolution ISSTA Technical Papers August Shi, Alex Gyori, Muhammad Suleman Mahmood, Peiyuan Zhao, Darko Marinov
	Exploiting Community Structure for Floating-Point Precision Tuning ISSTA Technical Papers Hui Guo, Cindy Rubio-González
	Identifying Implementation Bugs in Machine Learning based Image Classifiers using Metamorphic Testing ISSTA Technical Papers Anurag Dwarakanath, Manish Ahuja, Samarth Sikand, Raghotham M Rao, R.P. Jagadeesh Chandra Bose, Neville Dubash, Sanjay Podder
	Lightweight Verification of Array Indexing ISSTA Technical Papers Martin Kellogg, Vlastimil Dort, Suzanne Millstein, Michael D. Ernst
	Making Data-Driven Porting Decisions with Tuscan ISSTA Technical Papers Kareem Khazem, Earl T. Barr, Petr Hosek
	PerfFuzz: Automatically Generating Pathological Inputs ISSTA Technical Papers Caroline Lemieux, Rohan Padhye, Koushik Sen, Dawn Song
	piCoq: Parallel Regression Proving for Large-Scale Verification Projects ISSTA Technical Papers Karl Palmskog, Ahmet Celik, Milos Gligoric
	Practical Detection of Concurrency Issues at Coding Time ISSTA Technical Papers Luc Bläser
	Remove RATs from Your Code: Automated Optimization of Resource Inefficient Database Writes for Mobile Applications ISSTA Technical Papers Yingjun Lyu, Ding Li, William G.J. Halfond
	Repositioning of Static Analysis Alarms ISSTA Technical Papers Tukaram Muske, Rohith Talluri, Alexander Serebrenik
	Safe and Sound Program Analysis with Flix ISSTA Technical Papers Magnus Madsen, Ondřej Lhoták
	Search-Based Detection of Deviation Failures in the Migration of Legacy Spreadsheet Applications ISSTA Technical Papers Mohammad M. Almasi, Hadi Hemmati, Gordon Fraser, Phil McMinn, Janis Benefelds
	Shaping Program Repair Space with Existing Patches and Similar Code ISSTA Technical Papers Jiajun Jiang, Yingfei Xiong, Hongyu Zhang, Qing Gao, Xiangqun Chen Pre-print
	Shooting from the Heap: Ultra-Scalable Static Analysis with Heap Snapshots ISSTA Technical Papers Neville Grech, George Fourtounis, Adrian Francalanza, Yannis Smaragdakis
	Static Analysis of Java Dynamic Proxies ISSTA Technical Papers George Fourtounis, George Kastrinis, Yannis Smaragdakis
	Symbolic Path Cost Analysis for Side-Channel Detection ISSTA Technical Papers Tegan Brennan, Seemanta Saha, Tevfik Bultan, Corina S. Păsăreanu
	Test Case Prioritization for Acceptance Testing of Cyber Physical Systems: A Multi-Objective Search-Based Approach ISSTA Technical Papers Seung Yeob Shin, Shiva Nejati, Mehrdad Sabetzadeh, Lionel C. Briand, Frank Zimmer
	Test Migration for Efficient Large-Scale Assessment of Mobile App Coding Assignments ISSTA Technical Papers Farnaz Behrang, Alessandro Orso
	Tests from Traces: Automated Unit Test Extraction for R ISSTA Technical Papers Filip Křikava, Jan Vitek
	Translating Code Comments to Procedure Specifications ISSTA Technical Papers Arianna Blasi, Alberto Goffi, Konstantin Kuznetsov, Alessandra Gorla, Michael D. Ernst, Mauro Pezzè, Sergio Delgado Castellanos

Call for Papers

Research Papers

Authors are invited to submit research papers describing original contributions in testing or analysis of computer software. Papers describing original theoretical or empirical research, new techniques, in-depth case studies, infrastructures of testing and analysis methods or tools are welcome.

Experience Papers

Authors are invited to submit experience papers describing a significant experience in applying software testing and analysis methods or tools and should carefully identify and discuss important lessons learned so that other researchers and/or practitioners can benefit from the experience. Of special interest are experience papers that report on industrial applications of software testing and analysis methods or tools.

Reproducibility Studies (New!)

ISSTA would like to encourage researchers to reproduce results from previous papers, which is why ISSTA 2018 will introduce a new paper category called Reproducibility Studies. A reproducibility study must go beyond simply re-implementing an algorithm and/or re-running the artifacts provided by the original paper. It should at the very least apply the approach to new, significantly broadened inputs. Particularly, reproducibility studies are encouraged to target techniques that previously were evaluated only on proprietary subject programs or inputs. A reproducibility study should clearly report on results that the authors were able to reproduce as well as on aspects of the work that were irreproducible. In the latter case, authors are encouraged to make an effort to communicate or collaborate with the original paper’s authors to determine the cause for any observed discrepancies and, if possible, address them (e.g., through minor implementation changes). We explicitly encourage authors to not focus on a single paper/artifact only, but instead to perform a comparative experiment of multiple related approaches.

In particular, reproducibility studies should follow the ACM guidelines on reproducibility (different team, different experimental setup): The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently.

This means that it is also insufficient to focus on repeatability (i.e., same experiment) alone. Reproducibility Studies will be evaluated according to the following standards:

• Depth and breadth of experiments
• Clarity of writing
• Appropriateness of Conclusions
• Amount of useful, actionable insights
• Availability of artifacts

In particular, we expect reproducibility studies to clearly point out the artifacts the study is built on, and to submit those artifacts to artifact evaluation (see below). Artifacts evaluated positively will be eligible to obtain the highly prestigious badges Results Replicated or Results Reproduced.

Submission Guidelines

Submissions must be original and should not have been published previously or be under consideration for publication while being evaluated for this symposium. Authors are required to adhere to the ACM Policy and Procedures on Plagiarism and the ACM Policy on Prior Publication and Simultaneous Submissions. More details are available at the Submission Policies page.

Research and Experience Papers as well as Reproducibility Studies should be at most 10 pages in length, with at most 2 additional pages for references. Appendices are not allowed. Instead authors should make use of the option to supply Supplementary Material, see below. All papers must be prepared in ACM Conference Format.

Supplementary Material

Authors are free to provide supplementary material if that material supports the claims in the paper. Such material may include proofs, experimental results, and/or data sets. This material should be uploaded at the same time as the submission. Any supplementary material must also be anonymized. Reviewers are not required to examine the supplementary material but may refer to it if they would like to find further evidence supporting the claims in the paper.

Double-Blind Reviewing

ISSTA 2018 will conduct double-blind reviewing. Submissions should not reveal the identity of the authors in any way. Authors should leave out author names and affiliations from the body of their submission. They should also ensure that any citations to related work by themselves are written in third person, that is, “the prior work of XYZ” as opposed to “our prior work”. More details are available at the Double-Blind Reviewing page. Authors with further questions on double-blind reviewing are encouraged to contact the Program Chair by email.

Submit your papers via the HotCRP ISSTA 2018 submission website.

Reviews and Responses

Reviewing will happen in two phases. In Phase 1, each paper will receive three reviews, followed by an author response. Depending on the response, papers with negative reviews might be rejected early at this point. Other papers will proceed to Phase 2, at which they might receive additional reviews where necessary, to which authors can respond in a second author-response phase.

Posters

Authors of accepted papers are given the opportunity to bring along a poster of their accepted work and present it during the poster session. You can find more details about the joint ECOOP/ISSTA Posters track here.

Papers submitted for consideration to any of the above call for papers should not have been already published elsewhere and should not be under review or submitted for review elsewhere during the duration of consideration. Specifically, authors are required to adhere to the ACM Policy and Procedures on Plagiarism and the ACM Policy on Prior Publication and Simultaneous Submissions. All submissions are subject to the ACM Author Representations policy.

All submissions must be in English and in PDF format. Papers must not exceed the page limits that are listed for each call for papers.

The conference will use the iThenticate plagiarism detection software to screen submissions and will follow the ACM Policy and Procedures on Plagiarism. Possible violations will be reported to ACM for further investigation.

Submission Format

The ACM styles have changed recently, and all authors should use the official "2017 ACM Master article template”, as can be obtained from the ACM Proceedings Template pages.

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:

• \documentclass[sigconf,review, anonymous]{acmart}
• \acmConference[ISSTA 2018]{ACM SIGSOFT International Symposium on Software Testing and Analysis}{16–22 July, 2018}{Amsterdam, The Netherlands}

Accepted Contributions

All authors of accepted papers will be asked to complete an electronic ACM Copyright form and will receive further instructions for preparing their camera ready versions.

All accepted contributions will be published in the conference electronic proceedings and in the ACM Digital Library

Note that the official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of ISSTA 2018. The official publication date affects the deadline for any patent filings related to published work.

The names and ordering of authors as well as the title in the camera ready version cannot be modified from the ones in the submitted version unless there is explicit approval from the track chairs.

At least one author of each accepted paper must register and present the paper at ISSTA 2018 in order for the paper to be published in the proceedings. One-day registrations or student registrations do NOT satisfy the registration requirement, except the SRC and Doctoral track, for which student registrations suffice.

Double-Blind Reviewing

More details are available at the Double-Blind Reviewing page.

ISSTA 2018 Guidelines on Double-Blind Reviewing

Why is ISSTA 2018 using double-blind reviewing?

Studies have shown that a reviewer’s attitude toward a submission may be affected, even subconsciously, by author identity. We want reviewers to be able to approach each submission without such involuntary reactions as “Barnaby; he writes good papers” or “Who are these people? I have never heard of them.” For this reason, we ask that authors omit their names from their submissions, and avoid revealing their identities through citations and text. Many systems, security, and programming language conferences use double-blind reviewing and have done so for years (e.g., SIGCOMM, OSDI, IEEE Security and Privacy, SIGMOD, PLDI). Software engineering conferences are gradually starting to adopt this model. In 2017, most of the Software Engineering conferences (ESEC-FSE, ISSTA, ICSME, MSR, ICPC) have adopted double-blind reviewing, and in 2018 also ICSE as well. In 2016, ISSTA decided to try out double-blind reviewing for a three-year trial period, ISSTA 2016,17,18.

For those who are interested in motivation for double-blind reviewing, a very well­ argued, referenced, and evidenced article in favour of double-blind review processes for Software Engineering conferences can be found in the blog post by Claire Le Goues. Also there is a list of double-blind resources from Robert Feldt, and a more formal study of the subject by Moritz Beller​​ and Alberto Bacchelli​​.

Generally, this process will be cooperative, not adversarial. While the authors should take precautions not to reveal their identities (see details below), if a reviewer discovers the authors’ identities through a subtle oversight by the authors, the authors will not be penalized.

Do you really think blinding works? I suspect reviewers can often guess who the authors are.

Reviewers can sometimes guess the authorship correctly, though studies show this happens less often than people think. Still, imperfect blinding is better than no blinding at all, and even if all reviewers guess all authors’ identities correctly, double-blind reviewing simply becomes traditional single-blind reviewing.

Couldn’t blind submission create an injustice if a paper is inappropriately rejected because a reviewer is aware of prior unpublished work that actually is performed by the same authors?

The double-blind review process that we will be using for ISSTA 2018 is lightweight: author names will be revealed one week before the PC meeting, after all reviews have been collected. In this phase, the authors’ previous work can and will be explicitly considered.

What about additional information to support repeatability or verifiability of the reported results?

ISSTA 2018 puts a strong emphasis on creation of quality artifacts and repeatability and verifiability of experiences reported in the papers. An artifact evaluation committee is put in place to review artifacts accompanying all accepted papers, without the need to conceal identity of the authors.

For Authors

What exactly do I have to do to anonymize my paper?

Your job is not to make your identity undiscoverable, but to make it possible for our reviewers to evaluate your submission without knowing who you are. If you have a concern that particular information is particularly easy to trace to you, consider adding a warning to reviewers in a footnote, e.g., “Note for reviewers: searching the commit logs of the GitHub projects we used in our evaluation may reveal authors’ identities.”

Also please remove any acknowledgements from the paper.

I would like to provide supplementary material for consideration, e.g., the code of my implementation or proofs of theorems. How do I do this?

In general, supplementary material should also be anonymized. Please make your best to avoid (i) having your names/affiliations in artifact’s metadata (e.g. PDFs, spreadsheets, other documents); (ii) having contributors’ names in source code. To create a repository, you could use an anonymized cloud account (i.e., created with a username not clearly attributable to the authors), or similar solutions.

If the code or the repository cannot be anonymized easily, please either (A) provide an anonymized URL (such as using a URL shortener like http://bit.ly) with a prominent warning to reviewers that following the link may unblind them or, (B) if this is not possible, remove the URL to the repository from the paper and, instead, state “link to repository removed for double-blind review” or similar. Once the author names are revealed, the reviewers can ask the PC chair for the URL, who will contact the authors.

Also note that the assessment of artifacts within the Artifact Evaluation happens after paper acceptance and is not double-blind!

I am building on my own past work on the WizWoz system. Do I need to rename this system in my paper for purposes of anonymity, so as to remove the implied connection between my authorship of past work on this system and my present submission?

No. In our opinion the risk involved in misjudging a technical contribution because of such anonymization would outweigh the risk of de-anonymizing authors. Hence you should refer to the original, true system names only.

Am I allowed to post my (non-blinded) paper on my web page? Can I advertise the unblinded version of my paper on mailing lists or send it to colleagues? May I give a talk about my work while it is under review?

As far as the authors’ publicity actions are concerned, a paper under double-blind review is largely the same as a paper under regular (single-blind) review. Double-blind reviewing should not hinder the usual communication of results. But, during the review period, please don’t broadcast the work on social media. Also, to the extent to which this is possible, please avoid to publish the preprint of your work (e.g., on arXiv or on your website) until it is accepted for publication. In exceptional cases this might be required, but then please avoid spreading the paper more actively.

Will the fact that ISSTA is double-blind have an impact on handling conflicts of interest?

Using double-blind reviewing does not change the principle that reviewers should not review papers with which they have a conflict of interest, even if they do not immediately know who the authors are. Conflicts of interest are identified based on the authors’ and reviewers’ names and affiliations, and they can be declared by both the authors and reviewers. Note: Do not over-declare conflicts! The PC chair will double-check author-declared conflicts. In case we are able to identify clearly spurious conflicts that the authors have no good argument for, this can lead to desk rejection of the paper.

For Reviewers

What should I do if I if I learn the authors’ identities? What should I do if a prospective ISSTA author contacts me and asks to visit my institution?

If at any point you feel that the authors’ actions are largely aimed at ensuring that potential reviewers know their identities, you should contact the PC Chair. If you are unsure, contact the PC Chair. Otherwise you should not treat double-blind reviewing differently from regular single-blind reviewing. You should refrain from seeking out information on the authors’ identities, but discovering it accidentally will not automatically remove you from reviewing a paper you have been assigned. Use your best judgment and feel free to contact us with any concerns.

How do we handle potential conflicts of interest since I cannot see the authors’ names?

HotCRP will ask you to identify conflicts of interest before bidding. Please see the text field Collaborators and other affiliations on your HotCRP profile page. Also you can declare individual conflicts for each paper during bidding. To do so, enter a preference of -100.

This FAQ is based on several iterations of ASE, ISSTA, PLDI, and SIGMOD guidelines for double-blind reviewing.