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.
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 14 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) ships, in its own phrasing, an environment aware mode for running the same tests across selected runtime versions, Qiskit only, 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%, and that restoring it needed source code migration, not just dependency pinning.
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 a 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.
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