ISSTA Related Work
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.
Positioning checks
- Separate a genuine technique or measurement contribution from an engineering improvement: a new
bug class found, a new property analyzed, a new evaluation of a technique class, or a
sharper-but-cheaper analysis.
- Name the single nearest technique and state the delta in one sentence: what it could not do, what
yours does, and at what cost. Reviewers look for the closest competitor first.
- Sweep the right venues. Testing and analysis work is spread across ISSTA and its siblings; missing
a paper because it was at FSE or CAV rather than ISSTA reads as not knowing the field.
- Keep self-citations double-anonymous: cite your own prior tool in the third person and do not link
to an identity-revealing repository.
- Declare any overlap with a prior workshop or preprint version, and do not put duplicate archival
work under review.
Literature lanes for testing and analysis
| 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.
Delta-first positioning vignette
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."
Venue-attribution discipline
- Before citing a paper as ISSTA, confirm the venue on dblp or the ACM DL; many canonical
testing/analysis papers (KLEE at OSDI, EvoSuite at ESEC/FSE, Randoop at ICSE) are not ISSTA, and
mis-attributing them signals carelessness.
- For a tool everyone knows by name, cite the paper that introduced it, at its actual venue, not the
venue where you first encountered it.
- When unsure whether a venue is archival for dual-submission purposes, declare the overlap in the
submission form rather than guessing.
Output format
[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>
Source: brycewang-stanford/Awesome-Journal-Skills → ISSTA-Skills/skills/issta-related-work/SKILL.md
1---2name: issta-related-work3description: Use when positioning an ISSTA submission against the testing and analysis literature, covering the sibling venues (ICSE, FSE, ASE, ICST, PLDI, CAV), delta-first framing against the nearest technique, double-anonymous self-citation, distinguishing the closest tool baseline, and avoiding the venue-confusion of citing a paper to the wrong conference.4---567# ISSTA Related Work89Use this to audit novelty and positioning. ISSTA reviewers know the testing/analysis literature10well, so the job is to name the nearest technique and state the delta, not to survey the field.11Reopen the current call for any dual-submission and prior-publication rules before advising authors.1213## Positioning checks1415- Separate a genuine technique or measurement contribution from an engineering improvement: a new16 bug class found, a new property analyzed, a new evaluation of a technique class, or a17 sharper-but-cheaper analysis.18- Name the single nearest technique and state the delta in one sentence: what it could not do, what19 yours does, and at what cost. Reviewers look for the closest competitor first.20- Sweep the right venues. Testing and analysis work is spread across ISSTA and its siblings; missing21 a paper because it was at FSE or CAV rather than ISSTA reads as not knowing the field.22- Keep self-citations double-anonymous: cite your own prior tool in the third person and do not link23 to an identity-revealing repository.24- Declare any overlap with a prior workshop or preprint version, and do not put duplicate archival25 work under review.2627## Literature lanes for testing and analysis2829| Lane | Typical venues | What ISSTA reviewers check |30|---|---|---|31| Software-engineering flagships | ICSE, ESEC/FSE, ASE | Whether the closest SE technique is compared or distinguished |32| Testing-specific venues | ISSTA, ICST, ISSRE | Whether the direct predecessor and its benchmark are used |33| Programming languages / verification | PLDI, POPL, OOPSLA, CAV, TACAS | Whether the analysis's formal neighbours are acknowledged |34| Security testing | S&P, CCS, USENIX Security, NDSS | Whether fuzzing/analysis-for-security work is credited where relevant |3536A bibliography that cites only ISSTA papers signals to a reviewer that nearer work at FSE, ASE, or37CAV was missed — a recognizable weakness that benchmark strength does not repair.3839## Delta-first positioning vignette4041Suppose the paper proposes a directed fuzzer for a specific bug class. Its nearest neighbours: a42coverage-guided fuzzer at a security venue with no directedness, a directed symbolic-execution tool43at a PL venue that does not scale, and a prior ISSTA fuzzer for a different bug class. The novelty44sentence names all three deltas — directedness the coverage fuzzer lacked, scale the symbolic tool45lacked, and a different, harder target than the prior ISSTA fuzzer — rather than a generic "we46improve on prior fuzzers."4748## Venue-attribution discipline4950- Before citing a paper as ISSTA, confirm the venue on dblp or the ACM DL; many canonical51 testing/analysis papers (KLEE at OSDI, EvoSuite at ESEC/FSE, Randoop at ICSE) are *not* ISSTA, and52 mis-attributing them signals carelessness.53- For a tool everyone knows by name, cite the paper that introduced it, at its actual venue, not the54 venue where you first encountered it.55- When unsure whether a venue is archival for dual-submission purposes, declare the overlap in the56 submission form rather than guessing.5758## Output format5960```text61[Novelty] clear / incremental / at-risk62[Closest lanes] <SE / testing / PL-verification / security>63[Nearest 3 works] <work -> venue -> delta>64[Venue-attribution check] <any paper cited to the wrong conference?>65[Archival-overlap risk] none / issues66[Novelty sentence] <ISSTA-ready delta statement>67```6869---7071**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `ISSTA-Skills/skills/issta-related-work/SKILL.md`
thedixitjain