Onboarding

• Path A, native Jira testing. Shared tests with structured steps, cycles, version-pinned attempts, contextual Jira defects, coverage and a Migration Center, for teams that want to run testing inside Jira.
• Path B, keep your tools and add The Warden. Your CI, test runners and scanners keep running. They submit evidence for each exact build and The Warden decides whether their combined proof is enough.

Bring every verifier you already use. The Warden decides whether their combined proof is enough.

Marketplace V1 — publicly listed

1. A Jira site administrator installs TestWarden from the public Atlassian Marketplace listing. For guided installation or evidence setup, contact us.
2. Accept the requested Jira scopes: read:jira-work and write:jira-work, plus the personal-data reporting scope report:personal-data. Details are on Security.
3. Open Apps → TestWarden. The app opens in the Changes workspace. Until evidence arrives it reads “No changes received yet.” That is expected.

Pricing and the free tier are on Pricing.

Marketplace V1 — publicly listed

1. On an empty repository, choose We're starting fresh and click + New test, or choose We already track tests elsewhere to open the Migration Center.
2. Migrating? Upload an Xray Test Case Importer CSV, a Zephyr Scale CSV or a Generic CSV (AIO Tests exports go through Generic CSV with column mapping). Review the preview, then commit. CSV migration brings your test cases, not historical executions. Attachments are not migrated either. See Migration and import.
3. Create a cycle in Plans & Runs, add tests, run them step by step and create a Jira Bug from a failed step. Each run pins the test version it used.
4. Open Verification for requirement and release coverage.

The full walkthrough is in the product documentation.

Marketplace V1 — publicly listed

1. A site administrator enables App REST APIs for TestWarden in Atlassian Administration → Connected apps. The administration page then shows the API base URL.
2. Access for your CI is provisioned with the custom scope write:warden-evidence:custom (submit evidence) and, for reading changes, read:warden-changes:custom. For guided CI integration or pilot onboarding we can help set this up; you do not need to create your own integration or use personal access tokens.
3. Add a step to your pipeline that submits the report you already produce and gates on the result. Follow Submit CI evidence.
4. Open the Evidence Sources workspace. A source appears only after TestWarden accepts evidence from it, so a listed source is a fact, not a connection health claim.

1. Run your pipeline for a commit. The gate exits zero only for CLEARED on the exact commit, build and environment.
2. In Changes, open the change. You see the decision, its contract and policy version, reasons, next actions, the evidence received and the decision history.
3. To see a HELD result end to end, submit the failing fixture from CI evidence, read the reason, then submit evidence for a new build. The earlier decision stays in history and a new one is recorded.

Related tasks

• CI evidence

  Submit JUnit, SARIF or JSON and gate on the exact build.

• API, CLI and MCP

  Read status, obligations and explanations from a terminal or agent.

• Decisions and approvals

  States, reason codes, next actions and preserved history.

• Permissions

  Roles, custom scopes and who can read, write or request.

• AI and data handling

  What is optional, what is consented and what never changes a decision.

• “No changes received yet.” CI has not submitted evidence yet. Confirm App REST APIs are enabled and your pipeline step ran with the right endpoint and token.
• The gate reports authentication_failed. Access for CI is not provisioned, the token expired, or the caller is not a site administrator with the evidence scope. Contact support during onboarding.
• Migration finished but there is no execution history. Expected. Only test cases are imported.

More fixes are in the product troubleshooting list and on Support.