Quantum QA implementation guide
Use this guide to move from a new workspace to a customer-owned framework, CI/CD execution, Xray/Jira traceability, reporting dashboard, and objective release evidence.
What Quantum QA helps customers do
Quantum QA creates and operates a hosted evidence layer around customer-owned automation. The customer keeps the framework in their repository. Quantum QA helps generate the framework, connect CI/CD, capture reporting receipts, preserve evidence links, and explain release confidence.
Who should use this guide
Information to collect before onboarding
Customer application URL
The base URL for the application or environment that will be tested.
Repository access
A GitHub, GitLab, Bitbucket, or internal repository where the generated framework will live.
CI/CD access
Permission to add workflow files, variables, secrets, and artifact publishing steps.
Traceability target
Jira/Xray details when release evidence must connect to test execution records.
Notification channels
Slack or Teams webhook information if run summaries should be delivered to the team.
Release owner
A QA lead, SDET, engineering manager, or product owner who can approve what evidence is enough.
Customer implementation readiness checklist
Use this checklist before calling the first customer implementation ready. It is not a support script; it is the control list that proves the customer has configured the integrations required for useful release evidence.
Local environment
- Customer has a local Node.js environment that can run the generated framework.
- Application base URL is known for the first target environment.
- Local .env file is created from the generated example file.
- Local smoke run can reach the application under test.
CI/CD provider
- CI provider is selected: GitHub Actions, Azure DevOps, GitLab, or another runner.
- Generated workflow file is committed to the customer-owned repository.
- Required CI secrets are created with the exact names expected by the workflow.
- CI artifact publishing is enabled for reports, screenshots, summaries, and receipts.
Quantum QA reporting
- Reporting token is stored as a CI secret and never committed to source control.
- Project and product identifiers match the Quantum QA workspace configuration.
- Receipt JSON is generated by the run and uploaded/published by CI.
- The first run appears in the Quantum QA Reporting dashboard.
Xray and Jira traceability
- Jira/Xray project key is confirmed with the customer release owner.
- Test Plan ID or execution mapping approach is agreed before the first run.
- Xray client credentials are stored as CI secrets.
- At least one generated test maps to the expected Xray/Jira evidence record.
Slack or Teams notifications
- Target channel is approved by the customer team.
- Slack or Teams webhook is stored as a CI secret.
- First notification card includes pass/fail totals and useful evidence links.
- Notification routing is not sending release evidence to the wrong audience.
First proof run
- A narrow smoke lane is selected before running all lanes.
- Pass/fail totals match the CI logs.
- Evidence links open for the people who need to review them.
- Known failures are documented as product defects, environment issues, or setup gaps.
First successful customer run
- 1. Sign in and select the correct workspace.
- 2. Create a project for the application under test.
- 3. Create one product under the project.
- 4. Choose the first capability lanes: UI, API, WebSocket, accessibility, or performance.
- 5. Generate the Framework Pack.
- 6. Generate test artifacts for the selected capability lanes.
- 7. Download the workspace or move the generated framework into the customer-owned repository.
- 8. Configure CI/CD variables, reporting token, and optional Xray/Jira values.
- 9. Run the workflow and publish the reporting receipt.
- 10. Open Reporting and confirm pass/fail totals, evidence links, and release confidence.
Set up customer access cleanly
Confirm workspace owner
Make sure the customer workspace owner is the person who should manage billing, members, and access.
Invite implementation users
Add the QA/SDET users who will create projects, generate framework packs, and review reporting.
Keep internal workspaces separate
Do not mix founder/demo workspaces with customer workspaces when preparing client evidence.
Verify plan capacity
Confirm the customer plan allows the number of framework roots, active members, and monthly reporting runs needed.
Create the project, product, and lanes
Project
Represents the application, platform, or system under test.
Product
Represents the specific product surface or deployable unit being tested.
Capability lanes
Select UI, API, WebSocket, accessibility, and performance based on the first release proof path.
Framework root
The generated customer-owned automation framework connected to the project/product.
Demo project
Useful for learning, but it should not count as the customer production proof path.
Generate and hand off the automation root
- 1. Open Projects and select the target project/product.
- 2. Generate the Framework Pack.
- 3. Review the generated folder structure before copying it into the customer repo.
- 4. Keep shared helpers, fixtures, CI workflow files, and reporting receipt support together.
- 5. Commit the framework into the customer-owned repository.
- 6. Run the narrowest smoke lane first before the full evidence path.
- 7. Treat regeneration as a controlled change. Preserve customer edits intentionally.
Generate runnable proof assets
Test artifact generation is the point where Quantum QA turns selected product capabilities into runnable customer-owned tests and evidence metadata. The generated artifacts should be reviewed as release proof assets, not treated as throwaway output.
Choose lane scope
Select the capability lanes that should produce artifacts first: UI, API, WebSocket, accessibility, performance, or all.
Generate test artifacts
Use the Test Packs or generation flow to create runnable tests, recipes, evidence metadata, and lane-specific assets.
Review generated intent
Confirm the generated tests match the customer behavior, API contract, role, data state, or release question.
Keep artifacts linked
Keep test files, fixtures, expected evidence, reporting receipt support, and traceability labels together.
Run before broadening
Run the smallest useful generated artifact set before adding more lanes or deeper scenarios.
Download and move the workspace safely
Use Download Workspace when the customer needs a portable ZIP handoff instead of copying files one by one. The downloaded workspace should become customer-owned code once it is reviewed and committed into the customer repository.
- 1. Open the generated workspace or Test Packs area.
- 2. Download the workspace ZIP when the customer wants a portable handoff.
- 3. Extract the workspace into a clean local folder before copying into the customer repository.
- 4. Review included README, CI workflow, helpers, generated tests, and reporting receipt files.
- 5. Commit the downloaded workspace into source control after removing any local-only files.
- 6. Run the framework locally or in CI to prove the handoff works outside Quantum QA.
Refresh generated assets without losing customer work
Regeneration is useful, but it should be handled like a controlled code change. Customers should understand what changed, why it changed, and which custom edits must be preserved.
Use regeneration intentionally
Regenerate when product capabilities, platform templates, traceability metadata, or framework structure need to be refreshed.
Diff before replacing
Compare generated output with customer-owned files before overwriting anything.
Preserve custom edits
Keep customer-specific selectors, fixtures, endpoint overrides, assertions, and CI adjustments unless they are intentionally replaced.
Re-run smoke evidence
After regeneration, run a small proof path before trusting the full suite.
Record the reason
Document why regeneration happened so support and stakeholders understand the framework history.
Configure variables, secrets, artifacts, and run cadence
Variables customers should expect
APP_BASE_URL or BASE_URL
Application URL targeted by generated tests.
PRODUCT_SLUG
Product identifier used to group reporting and evidence.
TEST_TYPE
Lane selector such as ui, api, ws, perf, ada, or all.
QUANTUM_QA_REPORTING_TOKEN
Token used by the generated framework to publish run receipts.
XRAY_CLIENT_ID / XRAY_CLIENT_SECRET
Credentials used when Xray execution evidence is enabled.
JIRA_PROJECT_KEY or XRAY_PROJECT_KEY
Project key used to connect evidence to the correct traceability scope.
SLACK_WEBHOOK_URL or TEAMS_WEBHOOK_URL
Optional destination for run summaries and evidence cards.
ALLURE_RESULTS_PATH
Optional artifact path when Allure is generated and published.
Smoke run
Run one lane first to verify secrets, base URL, and framework install steps.
Full run
Run all configured lanes after the smoke run publishes evidence correctly.
Artifacts
Upload reports, screenshots, summaries, and any generated receipt JSON.
Notifications
Send Slack or Teams cards only after links are stable and useful.
Retention
Confirm how long CI artifacts remain available and whether Quantum QA hosted history is enough.
Connect Xray and Jira evidence
- 1. Confirm whether the customer wants Jira-only links, Xray Test Executions, or both.
- 2. Agree on naming rules for tests, executions, labels, environments, and release identifiers.
- 3. Add credentials and project keys to CI secrets, not source code.
- 4. Run a small lane that publishes a traceability record.
- 5. Open the Xray/Jira link from Quantum QA or the CI notification.
- 6. Confirm the evidence is understandable to a stakeholder who did not run the test.
Validate the dashboard after each run
Run totals
Pass, fail, skipped, and total counts match the CI run.
Capability lanes
UI, API, WebSocket, accessibility, and performance status are visible when configured.
Evidence links
Allure, Xray, CI, Slack/Teams, k6, and Quantum QA receipt links open correctly.
Hosted history
Recent runs appear in the expected retention window for the plan.
Release confidence
The score is explainable using framework posture, execution evidence, reporting, and traceability.
Vocabulary for release conversations
Objective evidence
A repeatable, timestamped, linked proof artifact that can support a release decision.
Framework Operational Posture
Readiness score for coverage, execution, reporting, and traceability.
Release Confidence
Stakeholder-facing signal based on current evidence and remaining risk.
Reporting Receipt
Structured JSON summary emitted by the framework so Quantum QA can ingest run evidence.
Evidence Link
A direct path to CI artifacts, Allure, Xray/Jira, k6 summaries, or Quantum QA run details.
Known risk
A failing lane, missing traceability, unstable environment, or untested capability that still matters.
Common first-run issues
No runs appear in Reporting
Check reporting token, product slug, receipt file path, and the CI upload/publish step.
Xray link is missing
Check Xray credentials, project key, selected lane, and whether Xray publishing is enabled.
Allure link is missing
Check report generation, artifact upload, public/private access, and link construction.
Accessibility lane fails
Review axe output. Treat real accessibility findings as product defects unless an exception is approved.
Performance lane fails
Review thresholds, environment stability, latency, request errors, and k6 summary output.
Framework changed after regeneration
Diff generated files and preserve customer customizations intentionally.
What to include when asking for help
Use the contact form as support intake until a dedicated ticketing system is added. A useful support request should include the context below so the issue can be reproduced or triaged quickly.