Research PapersICST 2020

ICST 2020 invites high quality submissions in all areas of software testing, verification, and validation. Papers for the research track should present novel and original work that pushes the state-of-the-art. Case studies and empirical research papers are also welcome.

Call for Papers

ICST 2020 invites high quality submissions in all areas of software testing, verification, and validation. Papers for the research track should present novel and original work that advances the state-of-the-art. Case studies and empirical research papers are also welcome.

Topics of Interest

Topics of interest include, but are not limited to the following:

• Fuzz testing
• Manual testing practices and techniques
• Search based software testing
• Security testing
• Model based testing
• Test automation
• Static analysis and symbolic execution
• Formal verification and model checking
• Software reliability
• Testability and design
• Testing and development processes
• Testing education
• Testing in specific domains, such as mobile, web, embedded, concurrent, distributed, cloud, GUI and real-time systems
• Testing for learning-enabled software, including deep learning
• Testing/debugging tools
• Theory of software testing
• Empirical studies
• Experience reports

Each submission will be reviewed by at least three members of the ICST Program Committee.

Papers that have a strong industrial/practical component and focus more on impact rather than (technical) novelty are encouraged to consider the industry track instead.

Submission Format

Full Research papers as well as Industry papers must conform to the two-column IEEE conference publication format, not exceed 10 pages, including all text, figures, tables, and appendices; two additional pages containing only references are permitted. It must conform to the the IEEE Conference Proceedings Formatting Guidelines (please use the letter format template and conference option). The ICST 2020 research track only accepts full research papers. Short papers are not accepted to the research track.

The submission must also comply with the ACM plagiarism policy and procedures. In particular, it must not have been published elsewhere and must not be under review elsewhere while under review for ICST. The submission must also comply with the IEEE Policy on Authorship.

Lastly, the ICST 2020 Research papers track will employ a double-blind review process. Thus, no submission may reveal its authors’ identities. The authors must make every effort to honor the double-blind review process. In particular, the authors’ names must be omitted from the submission and references to their prior work should be in the third person. Further advice, guidance and explanation about the double-blind review process can be found in the Q&A page.

Submissions to the Research Papers Track that meet the above requirements can be made via the Research Papers Track submission site by the submission deadline. by the submission deadline.

Any submission that does not comply with the above requirements may be rejected by the PC Chairs without further review.

If a submission is accepted, at least one author of the paper is required to attend the conference and present the paper in person for the paper to be published in the ICST 2020 conference proceedings.

New in 2020. Submissions must supply all information that is needed to replicate the results, and therefore are expected to include or point to a replication package with the necessary software, data, and instructions. Reviewers may consult these packages to resolve open issues. There can be good reasons for the absence of a replication package, such as confidential code and/or data, the research being mostly qualitative, or the paper being fully self-contained. If a paper does not come with a replication package, authors should comment on its absence in the submission data; reviewers will take such comments into account.

Submission Site: https://easychair.org/my/conference?conf=icst2020

Submitting to ICST2020: Q&A

Please note that the Double Blind Review (DBR) process is not used by all tracks, e.g., Industry Track. Check in the call for papers whether DBR is used or not.

Q: Is the deadline firm? Can I ask for an extension?

Yes. No.

Q: How can I submit an anonymous replication package?

Set up an anonymous account at dropbox or a similar public file sharing service and place your (anonymized) package there. Include the URL in your submission (typically at the end).

Q: Do I have to provide a replication package?

There are good reasons not to provide a package. Typical reasons include (1) your approach is simple enough such that it can be fully described in the paper; (2) the concept of a replication package is not applicable because of your specific research methodology; or (3) parts of your research are confidential. Just state the reason in the paper, such that reviewers can assess it.

Q: How does one prepare an ICST 2020 submission for double-­blind reviewing?

In order to comply, you do not have to make your identity undiscoverable; the double­-blind aspect of the review process is not an adversarial identity discovery process. Essentially, the guiding principle should be to maximize the number of people who could plausibly be authors, subject to the constraint that no change is made to any technical details of the work. Therefore, you should ensure that the reviewers are able to read and review your paper without having to know who any of the authors are. Specifically, this involves at least the following four points:

1. Omit all authors’ names, affiliations, emails and related information from the title page as well as in the paper itself.
2. Refer to your own work in the third person. You should not change the names of your own tools, approaches or systems, since this would clearly compromise the review process. It breaks the constraint that “no change is made to any technical details of the work”. Instead, refer to the authorship or provenance of tools, approaches or systems in the third person, so that it is credible that another author could have written your paper.
3. Anonymize project and grant names and numbers or those of funding agencies or countries as well as any acknowledgements of support to the work you report on.
4. If necessary, set up an anonymous account at dropbox or a similar public file sharing service and place your (anonymized) package there. Include the URL in your submission (typically at the end).

We further expect you to follow the excellent advice on anonymization from ACM.

When anonymizing your email, affiliations, name, etc., try to refrain from being overly creative or “funny” by coming up with your own, anonymized versions. For emails preferably use author1@anon.org, author2@anon.org, etc., since initial DBR screening will be done by an automated tool.

Q: I previously published an earlier version of this work in a venue that does not have double-blind. What should I do about acknowledging that previous work?

Double-blind does not and cannot mean that it is impossible for the referees to discover the identity of the author. However, we require authors to help make it easy for author identity to not play a role in the reviewing process. Therefore, we ask that in the materials you submit to us to be reviewed author identity is not revealed.

If the work you are submitting for review has previously been published in a non-peer-reviewed venue (e.g., arXiv departmental tech report), there is no need to cite it, because unrefereed work is not truly part of the scientific literature. If the previous work is published in a peer-reviewed venue, then it should be cited, but in the third person so that it is not clear whether or not this work was done by the author of the submitted paper or some other set of authors unknown. However, if citing in the third person would still risk that it is easy to identify the authors please err on the side of caution by also anonymising the papers being extended (both when cited and in the reference list).

Q: Our submission makes use of work from a PhD/master’s thesis dissertation/report which has been published. Citing the dissertation might compromise anonymity. What should we do?

It is perfectly OK to publish work from a PhD/master’s thesis, and there is no need to cite it in the version submitted for review because prior dissertation publication does not compromise novelty. In the final (post-review, camera ready) version of the paper, please do cite the dissertation to acknowledge its contribution, but in the refereed version of the paper that you submit, please refrain from citing the dissertation.

However, you need not worry whether or not the dissertation has appeared, since your job is only to help the committee review your work without awareness of author identity, but not to make it impossible for them to discover the identity of authors. The referees will be trying hard not to discover the authors’ identity, so they will likely not be searching the web to check whether there is a dissertation related to this work.

Q: I am submitting to the industry track. Should I double-blind my submission?

No you should not. Since industry papers typically relies heavily on the industrial or practical context in which the work was carried out it would be too much to ask to require this context to be anonymized.

Q: I want to include a link to an online appendix in my submission. How should I do this?

Ideally the information in the appendix should be anonymous and it should be uploaded to an anonymous service such as for example figshare or create a new github (or other) sharing account that is not associated with your real name. These sites will give you a link that is anonymous. Later, if the paper is accepted you can turn that link into a non-anonymized link or just put the appendix on your own site and change the link in the camera ready version of the paper. An alternative solution is to not include the link in the submission; normally papers should be possible to review based on only the material of the paper itself.

To upload material on figshare please create an account there, then add a new item, use the keywords “Supplemental Materials” and add the other item-specific data and then select “Make file(s) confidential” and select “Generate private link”. Copy the url generated there and then “Save changes”. Your file(s) can now be accessed anonymously at the given url so you can put it in your ICST submission.

Q: What if we want to cite some unpublished work of our own (as motivation for example)

If the unpublished paper is an earlier version of the paper you want to submit to ICST and is currently under review, then you have to wait until your earlier version is through its review process before you can build on it with further submissions (this would be considered double-submission and violates ACM plagiarism policy and procedures). Otherwise, if the unpublished work is not an earlier version of the proposed ICST submission, then you should simply make it available on a website, for example, and cite it in the third person to preserve anonymity, as you are doing with others of your works.

Q: Can I disseminate non-blinded version of my submitted work by discussing it with colleagues, giving talks, publishing it at ArXiV, etc.?

You can discuss and present your work that is under submission at small meetings (e.g., job talks, visits to research labs, a Dagstuhl or Shonan meeting), but you should avoid broadly advertising it in a way that reaches the reviewers even if they are not searching for it. For example, you are allowed to put your submission on your home page and present your work at small professional meetings. However, you should not discuss your work with members of the program committee, publicize your work on mailing lists or media that are widely shared and can reach the program committee, or post your work on ArXiV or a similar site just before or after submitting to the conference.

Accepted Papers

	Title
	A Family of Experiments to Assess the Impact of the PO Pattern in Web Test Suite Development Maurizio Leotta, Matteo Biagiola, Filippo Ricca, Mariano Ceccato, Paolo Tonella
	A Framework for In-Vivo Testing of Mobile Applications Mariano Ceccato, Davide Corradini, Luca Gazzola, Fitsum Kifetew, Leonardo Mariani, Matteo Orru, Paolo Tonella
	A Study on Challenges of Testing Robotic Systems Afsoon Afzal, Claire Le Goues, Michael Hilton, Christopher Steven Timperley Pre-print
	An Empirical Analysis of Blind Tests Kesina Baral, Jeff Offutt
	An Empirical Evaluation of Mutation Operators for Deep Learning Systems Gunel Jahangirova, Paolo Tonella Pre-print
	CBR: Controlled Burst Recording Oscar Cornejo, Daniela Briola, Daniela Micucci, Leonardo Mariani
	Can We Predict the Quality of Spectrum-based Fault Localization? Mojdeh Golagha, Alexander Pretschner, Lionel Briand
	Comparing Offline and Online Testing of Deep Neural Networks: An Autonomous Car Case Study Fitash Ul Haq, Donghwan Shin, Shiva Nejati, Lionel Briand
	Dependency-Aware Web Test Generation Matteo Biagiola, Andrea Stocco, Filippo Ricca, Paolo Tonella
	Determining Method-Call Sequences for Object Creation in C++ Thomas Bach, Ralf Pannemans, Artur Andrzejak
	Fostering the Diversity of Exploratory Testing in Web Applications Julien Leveau, Xavier Blanc, Laurent Réveillère, Jean-Rémy Falleri, Romain Rouvoy
	Human-In-The-Loop Automatic Program Repair Marcel Böhme, Charaka Geethal, Van-Thuan Pham Link to publication Pre-print
	Implementation-induced Inconsistency and Nondeterminism in Deterministic Clustering Algorithms Xin Yin, Iulian Neamtiu, Saketan Patil, Sean Andrews
	Keynote 2 - Elvira Albert - Smart – and also reliable and gas-efficient – Contracts
	Keynote 3 - Franjo Ivancic - SunDew: Systematic Automated Security Testing
	Language-Agnostic Generation of Compilable Test Programs Patrick Kreutzer, Stefan Kraus, Michael Philippsen
	Learning How to Search: Generating Exception-Triggering Tests Through Adaptive Fitness Function Selection Hussein Almulla, Gregory Gay Pre-print
	Lunch
	Massively Parallel, Highly Efficient, but What About the Test Suite Quality? Applying Mutation Testing to GPU Programs Qianqian Zhu, Andy Zaidman
	Metamorphic Security Testing for Web Systems Phu X. Mai, Fabrizio Pastore, Arda Goknil, Lionel Briand
	MiMIs: Simple, Efficient, and Fast Bounded-Exhaustive Test Case Generators Kyle Dewey, Shant Hairapetian, Miroslav Gavrilov
	More Accurate Dynamic Slicing for Better Supporting Software Debugging Xiangyu Li, Alessandro Orso
	Most Influential Paper Award
	NodeRacer: Event Race Detection for Node.js Applications André T. Endo, Anders Møller Pre-print
	Optimizing Mutation Testing by Discovering Dynamic Mutant Subsumption Relations Marcio Augusto Guimarães, Leo Fernandes, Márcio Ribeiro, Marcelo d'Amorim, Rohit Gheyi
	Prioritizing Runtime Verification Violations Breno Miranda, Igor Lima, Owolabi Legunsen, Marcelo d'Amorim
	QuickREST: Property-based Test Generation of OpenAPI Described RESTful APIs Stefan Karlsson, Adnan Causevic, Daniel Sundmark Pre-print
	RESTTESTGEN: Automated Black-Box Testing of RESTful APIs Emanuele Viglianisi, Michael Dallago, Mariano Ceccato
	STICCER: Fast and Effective Database Test Suite Reduction Through Merging of Similar Test Cases Abdullah Alsharif, Gregory Kapfhammer, Phil McMinn
	Substate Profiling for Enhanced Fault Detection and Localization: An Empirical Study Rawad Abou Assi, Wes Masri, Chadi Trad
	Testability Transformations For Existing APIs Andrea Arcuri, Juan Pablo Galeotti