Research / Evidence

Evidence

Every structured evidence record, grouped by verification status so verified, partial, false, and not-found findings are never mixed together. Expand a card for the full evidence, source, and notes.

This page mirrors evidence.json, the machine-readable record in the GitHub repository. For a clean list of every URL opened during this research — including sources that failed to load — see Sources.

Verified findings

Actively checked against a primary source and confirmed to hold as stated.

Verbatim from the full PDF text: “Only eight of 26 respondents (31%) reported using quantum-specific testing tools.” Stated as Finding 2, Section 5.2, p.18. Survey of 26 analyzed respondents (from 1,397 industry/government + 75 academic invitees), plus 4 follow-up interviews, fielded via Qualtrics 2024-05-20 to 2024-08-05, IRB-approved.

Zappin, Stalnaker, Chaparro, Poshyvanyk, “Challenges and Practices in Quantum Software Testing and Debugging: Insights from Practitioners,” arXiv:2506.17306

https://arxiv.org/abs/2506.17306

Authors themselves flag N=26 as a generalizability limitation (Section 9.2). Paper explicitly calls for, but does not build, “CI/CD pipelines tailored to hybrid systems” — evidence of need, not of prior-art absence.

Qiskit’s official ecosystem CI template ships three real, verified workflow files (test_latest / development / minimum_versions.yml), reused across ~8 Qiskit-ecosystem repos. Qiskit core’s own qpy.yml performs genuine cross-Qiskit-version regression testing for QPY serialization compatibility.

Qiskit ecosystem CI template; Qiskit QPY compatibility harness

https://github.com/Qiskit/qiskit-addon-cutting

These templates assert pass/fail of existing tests at each version tier — they do not diff behavior between versions themselves.

Partially verified findings

A primary source was opened, but the original claim was only partly confirmable — commonly because no specific reference was supplied to check against, or because the finding cuts both for and against the original framing.

No specific arXiv IDs were supplied to check against, so the original “two papers” could not be confirmed or denied directly. Independent search reconstructed the most material candidates: QUTest (arXiv:2605.19736) already implements cross-Qiskit-version regression testing with CI-compatible (JUnit/xUnit) output for GitHub Actions — but does not integrate with pytest, and supports only Qiskit today.

Campos, “QUTest: A Native Testing Framework for Quantum Programs,” arXiv:2605.19736

https://arxiv.org/abs/2605.19736

The single most material finding of the whole research phase: it directly narrows the novelty claim. What remains open per QUTest’s own stated limitations: pytest-native integration, cross-SDK testing, automated (not hand-written) regression detection.

Three real, installable pytest plugins exist (pytest-quantum, qtest-quantum, qc-assert) but do framework-to-framework (not version-to-version) equivalence or single-run assertions only. All are under 9 months old, single-maintainer, 0–2 GitHub stars.

See the Prior-Art matrix for the full inspection table

https://github.com/qbench/pytest-quantum

None execute a test suite against multiple installed versions of the same SDK and auto-diff results.

quantum-transpiler-regression-testing (“cart”), independently verified via GitHub repo and Zenodo DOI resolution, found that ~38% of real Qiskit transpiler bug-fixes are regressions invisible to black-box equivalence oracles. Scope: single-SDK, CLI-based, brand new (0 stars). No cross-SDK tool of any kind was found anywhere.

furqan-nr/quantum-transpiler-regression-testing; Zenodo 10.5281/zenodo.21020113

https://github.com/furqan-nr/quantum-transpiler-regression-testing

Treat as directly relevant, possibly competing/complementary prior art.

False / contradicted findings

Actively checked and found not to hold as originally stated.

MQT QCEC is a mature equivalence-checking library (decision-diagram, alternating DD, simulation-based falsification, ZX-calculus engines) for Qiskit circuits and OpenQASM files. Its own CI matrix is OS/architecture/compiler only — no SDK-version matrix, no cross-SDK-version regression harness, no CI/CD product for arbitrary user projects.

munich-quantum-toolkit/qcec (README, CI workflow, verification handbook)

https://github.com/munich-quantum-toolkit/qcec

117 GitHub stars, 1,516+ commits, MIT license. Citation: Burgholzer & Wille, “QCEC: A JKQ tool for quantum circuit equivalence checking,” Software Impacts, 2021.

MQT Debugger is an assertion-based, simulation-driven debugger for locating errors within a single quantum program run, with a Debugger Adapter Protocol (DAP) server for IDE integration. Its GitHub Actions workflows are standard CI for its own codebase, not a feature for testing other projects across SDK versions.

Rovara, Burgholzer, Wille, “A Framework for Debugging Quantum Programs,” arXiv:2412.12269

https://arxiv.org/abs/2412.12269

21 stars, 4 forks, 496 commits, MIT license. arXiv:2412.12269 submitted 2024-12-16.

“Q-Trace” as a named quantum debugging tool does not exist. Other real systems verified — QMon, TraceQ, the Microsoft QDK Trace Simulator, CUDA-Q statistical assertions, Proq, Bloq/AutoBloq, MorphQ — all operate at the single-circuit, single-run fault-localization or monitoring level. None perform cross-version or cross-SDK regression comparison; none integrate with pytest or GitHub Actions.

See the Prior-Art matrix for the full per-system table

https://arxiv.org/abs/2506.18458

MorphQ (Qiskit-testing-Qiskit) flagged for cross-check but not deeply verified in this pass.

Bugs4Q (36+ manually-validated real Qiskit bugs, public repo) is described by independent replication work as “a widely used dataset.” Critically, arXiv:2606.27124 ran Bugs4Q across 21 Qiskit versions / 77,700 executions, found reproducibility collapsed from 62.2% to 16.2%, and released a patched fork “Bugs4Q-Robust.”

Bugs4Q (arXiv:2108.09744, JSS vol. 205 2023); cross-version replication (arXiv:2606.27124)

https://github.com/Z-928/Bugs4Q

No single corpus is a universal standard (unlike Defects4J for Java) — the narrowest defensible claim is that existing corpora are not packaged as ready-to-use pytest/CI fixtures.

Not found after search

A reasonably broad search turned up nothing. Treated as absence of evidence, not proof of non-existence.

GitHub repository search for “quantum equivalence checking” returned only unrelated SAT-solver student projects whose legitimacy was not independently verified. No other academic or industry open-source equivalence checker with CI integration was found beyond MQT QCEC, QUTest, and the “cart” pilot.

gh search repos “quantum equivalence checking”

https://github.com/munich-quantum-toolkit/qcec

Absence of evidence after search, not proof of non-existence.

Generic autonomous AI testing agents exist abundantly for classical software QA with no quantum angle. The closest quantum-specific agentic system, QBugLM, is genuinely agentic and quantum-specific but has no CI/CD integration, no cross-SDK-version regression detection, and no demonstrated state-awareness.

QBugLM (arXiv:2606.07314); general web search for autonomous quantum testing agents

https://arxiv.org/abs/2606.07314

Explicitly marked NOT FOUND rather than FALSE — absence of evidence after a reasonably broad search, not proof of non-existence. Least load-bearing part of the original idea.

Machine-readable source: research/evidence.json in sadeqisaidmohaddes-star/quantum-cicd-research