Build the demo path, then repeat it on your own product.
Use these docs to reproduce the Demo AUT flow, create your first framework, connect reporting, and understand the evidence Quantum QA generated.
1. Start with Demo AUT
Generate the framework, explore the completed demo, download the workspace ZIP, and run all five lanes.
2. Create your project
Add your project and product, choose capabilities, and generate your customer-owned framework root.
3. Configure CI and variables
Set BASE_URL, OPENAPI_URL, WS_URL, Slack/Teams webhooks, Xray credentials, and reporting tokens.
4. Generate Test Packs
Use Guided mode for known recipes or Custom mode when you have app-specific selectors and endpoints.
5. Read reports
Use Slack/Teams cards, Allure, Xray Test Executions, k6 summaries, and Quantum QA reporting for evidence.
6. Troubleshoot
Regenerate framework after platform updates, keep grep blank for full lane runs, and treat ADA axe failures as product defects.
What customers should learn to read first
Framework Operational Posture
A readiness score for coverage scope, execution readiness, reporting visibility, and delivery traceability.
Release Confidence
A stakeholder-facing signal based on framework maturity, runnable evidence, reporting, and traceability state.
Reporting Dashboard
Hosted run memory for evidence links, pass rates, labels, capability status, and recent run history.
Evidence Panel
The place to open Allure, CI artifacts, Xray executions, and Quantum QA JSON receipts for a specific run.
The four questions behind Quantum QA reporting
Use these words when explaining a run to managers, auditors, and stakeholders. Quantum QA is designed to connect generated tests to these release questions.
Validity
Whether a test proves the right behavior, contract, role, data shape, or user outcome.
Reliability
Whether the signal is deterministic, repeatable in CI, and readable enough to support a release decision.
Coverage
What products, capabilities, flows, roles, and non-happy paths are represented in the current proof set.
Risk
What remains unresolved: known defects, untested areas, failing ADA checks, performance gaps, or missing evidence.
How to explain what Quantum QA generated
The goal is not to say "AI wrote a test." The goal is to explain what risk the test covers, what proof it produces, and how it contributes to release confidence.
Positive path
A valid workflow or API call that should succeed and produce evidence.
Negative path
A rejected credential, invalid token, forbidden role, validation error, or malformed request that should fail safely.
Contract evidence
Status, schema, mandatory fields, payload shape, sanitized request/response data, and error shape.
State evidence
API interception or read-back that proves a UI workflow changed backend state correctly.
Accessibility evidence
Axe results and page evidence that may intentionally fail when the product has real ADA defects.
Performance evidence
k6 summary data, thresholds, latency, failure rate, and scenario receipts.
Recommended first run
- 1. Select Demo AUT and Demo AUT Portal.
- 2. Generate or regenerate the Framework Pack.
- 3. Open AI Architect and click Explore Completed Demo.
- 4. Download the Workspace ZIP from Test Packs.
- 5. Push to GitHub and run the workflow with Test Type all and grep blank.