Published in volume 26, issue 3, May 2016

This issue presents three new inventions in software testing. A major research topic in software engineering is that of fault localization, that is, finding faulty code in failing software. Probabilistic reasoning in diagnosing causes of program failures, by Junjie Xu, Rong Chen, and Zhenjun Du, invents a new graph to model possible faults probabilistically. (Recommended by Atif Memon.) The second paper, Behaviour abstraction adequacy criteria for API call protocol testing, by Hernan Czemerinski, Victor Braberman, and Sebastian Uchitel, invents new criteria to test whether APIs are used correctly. Specifically, the criteria measure the extent to which software that uses the APIs conform to the expected protocol such as whether the methods are called in valid orders. (Recommended by Hasan Ural.) The third paper in this issue addresses the difficult oracle problem. Predicting metamorphic relations for testing scientific software: A machine learning approach using graph kernels, by Upulee Kanewala, James M. Bieman, and Asa Ben-Hur, invents a technique to use machine learning to predict metamorphic relations, which are used to create oracles in software for which correct behavior is unknown. (Recommended by TY Chen.)


How to Write an Effective “Response to Reviewers” Letter

A well written response letter is critical when resubmitting a paper to a journal. A key is to be proactive. As authors, we’re happy that the journal did not reject the paper, but we always find comments that are annoying, frustrating, or downright insulting. Authors even react to comments that are valid and correct. But as I discussed in my last editorial [1], our goal is not to argue with anonymous reviewers, but to publish a paper. Indeed, authors, reviewers, and editors all want the same thing: to publish good papers. Even the worst reviews can help us write better papers.

A response letter is the authors’ chance to assert proactive control over the process. Don’t try to convince reviewers they were wrong-that’s the path to rejection. The goal is much simpler: The response letter should convince the reviewers that you modified the paper perfectly before they even look at the revision.

Sadly, many reviewers decide whether to accept or reject a paper in the first five minutes they consider it. Then they spend the rest of their time looking for reasons to support their initial assessment. (Please note that I am definitely not advocating that approach. It is anti-science and destructive, but is unfortunately common.) The response letter is the first impression of that crucial first five minutes. I’m suggesting some ways to not blow it.

Below is a list of “dos” and “don’ts” for writing effective response letters.

DO this:

DON’T do this:

I want to acknowledge Stephen Schach, my most proactive co-author, for teaching me most of these tactics.

[1] Jeff Offutt. How to revise a research paper (Editorial), Wiley’s journal of Software Testing, Verification, and Reliability, 26(2), March 2016.

Jeff Offutt
George Mason University
17 March 2016