Use this to audit novelty and positioning. ISSTA reviewers know the testing/analysis literature well, so the job is to name the nearest technique and state the delta, not to survey the field. Reopen the current call for any dual-submission and prior-publication rules before advising authors.
| Lane | Typical venues | What ISSTA reviewers check |
|---|---|---|
| Software-engineering flagships | ICSE, ESEC/FSE, ASE | Whether the closest SE technique is compared or distinguished |
| Testing-specific venues | ISSTA, ICST, ISSRE | Whether the direct predecessor and its benchmark are used |
| Programming languages / verification | PLDI, POPL, OOPSLA, CAV, TACAS | Whether the analysis's formal neighbours are acknowledged |
| Security testing | S&P, CCS, USENIX Security, NDSS | Whether fuzzing/analysis-for-security work is credited where relevant |
A bibliography that cites only ISSTA papers signals to a reviewer that nearer work at FSE, ASE, or CAV was missed — a recognizable weakness that benchmark strength does not repair.
Suppose the paper proposes a directed fuzzer for a specific bug class. Its nearest neighbours: a coverage-guided fuzzer at a security venue with no directedness, a directed symbolic-execution tool at a PL venue that does not scale, and a prior ISSTA fuzzer for a different bug class. The novelty sentence names all three deltas — directedness the coverage fuzzer lacked, scale the symbolic tool lacked, and a different, harder target than the prior ISSTA fuzzer — rather than a generic "we improve on prior fuzzers."
[Novelty] clear / incremental / at-risk
[Closest lanes] <SE / testing / PL-verification / security>
[Nearest 3 works] <work -> venue -> delta>
[Venue-attribution check] <any paper cited to the wrong conference?>
[Archival-overlap risk] none / issues
[Novelty sentence] <ISSTA-ready delta statement>