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.

Accepted Papers

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

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.