Quantum Powerhouse Research
Is there a real gap in quantum CI/CD regression testing?
A primary-source-verified investigation — every finding traced back to an official repository, an arXiv paper, or an independently-resolved citation.
Claims verified
Confirmed / partial
Prior-art systems
Sources linked
The question
Is there a genuine open research/software gap around CI/CD regression testing for quantum software — specifically, an open-source pytest/GitHub Actions style infrastructure that runs quantum projects across SDK versions and detects regressions or equivalence failures? Several prior claims (MQT QCEC, MQT Debugger, a 31% practitioner statistic, two cited arXiv papers, and an assumed absence of bug corpora) needed independent verification before that question could be answered honestly.
Why this matters
It is easy to build a novelty argument on claims nobody has checked. This research phase set out to verify — or reject — every load-bearing claim behind the original thesis, using only primary sources: official repositories, arXiv abstracts and full text, and independently-resolved DOI records. Where a search-result snippet was the only evidence available, the claim was marked Unverified rather than accepted.
Claim status distribution
Computed directly from the 13 claims in the claims table — not a separately-maintained figure.
Headline findings
MQT QCEC and MQT Debugger are real, but narrower than assumed
Both are mature, citable tools — but they solve equivalence checking and single-run assertion debugging respectively, not CI/CD orchestration or cross-SDK-version regression testing.
The 31% practitioner statistic is real and precisely traceable
“Only eight of 26 respondents (31%) reported using quantum-specific testing tools” — Zappin et al., arXiv:2506.17306, Finding 2, p. 18. Cite it with its N=26 caveat, not as a field-wide constant.
The single most important find: QUTest already exists
arXiv:2605.19736 (May 2026) already implements cross-Qiskit-version regression testing with GitHub Actions-compatible output. This materially narrows any novelty claim — it does not eliminate the gap, but it removes a large piece of it.
“No bug corpus exists” is false
Bugs4Q is real and “widely used,” and a 2026 replication study already ran it across 21 Qiskit versions (77,700 executions), finding reproducibility collapsed from 62.2% to 16.2%.
No cross-SDK regression/equivalence tool exists anywhere
Every cross-version or regression-testing artifact found (QUTest, Qiskit’s own CI template, the “cart” transpiler pilot) is single-SDK. This is the strongest candidate for genuine, narrow novelty — see the Gap Analysis.
Read next
Methodology
How the research was conducted: four parallel primary-source verification threads and the confidence-rating rules.
Claims table
All 13 claims (C01–C13), their verification status, evidence, and confidence level.
Prior-art matrix
21 systems compared across testing, CI/CD, cross-version, cross-SDK, and more.
Evidence
The structured evidence record behind every claim, as expandable detail cards.
Sources
A clean index of every source opened during this research, including ones that failed to load.
Timeline
The real, git-derived sequence this research and its publication actually happened in.
Gap analysis & conclusions
Our own synthesis of what's novel, what isn't, and the narrowest defensible research gap — clearly marked as interpretation, not additional primary-source fact.
Raw artifacts
This website is a rendering, not the source of truth. Every markdown file, the structured evidence.json, the full search log, and the complete git history of this research live in the public GitHub repository:
sadeqisaidmohaddes-star/quantum-cicd-research
Source of truth: https://github.com/sadeqisaidmohaddes-star/quantum-cicd-research