Independent quality governance. Native Jira testing included.
Keep your tests. Govern every release.
TestWarden adds independent quality governance above the tools your team already uses. Keep AIO Tests, Xray, Zephyr, TestRail, Azure DevOps and your existing CI workflows. The Warden evaluates evidence for the exact software change and records whether the proof is sufficient to proceed.
Need native test management? That is built into TestWarden for Jira, too.
- Keep your test-management system and CI as they are
- Evidence bound to the exact commit and build
- Free for Jira sites up to 10 users
- Built on Atlassian Forge
Evidence for any other build does not count toward this decision.
- Run 8841 announced. No evidence yet for build 4821.
The Warden is still verifying.
- Complete automated test run for this build
- Evidence is current (under 24 hours)
Run 8841 announced. No evidence yet for build 4821.
- No decision recorded yet.
Build. A change arrives as an exact commit and build: 9f3c2a1, build 4821. CI announces run 8841. An announcement is never evidence.
Read this scene as text
- Build. A change arrives as an exact commit and build: 9f3c2a1, build 4821. CI announces run 8841. An announcement is never evidence.
- Evidence. The test run reports in. It becomes a receipt attributed to its producer (ci, github-actions, run 8841) and tied to this exact build.
- Contract. The Warden evaluates the receipts against Contract v1: a complete, current test run for this build. A passing scanner report is recorded, but it cannot satisfy that requirement.
- Held. One required test failed, so the decision is HELD with a readable reason and the next action. Policy decides; no tool score can override it.
- Fresh proof. A fix lands as commit c41e8d7, build 4822. Only fresh evidence for that exact build counts, and the HELD decision stays on record.
- Cleared. The new run passes under the same policy, so build 4822 is CLEARED. Decision 1 is preserved beside decision 2, never rewritten.
Works alongside your existing test-management stack.
Named tools are the integration targets. Report compatibility, connector code under integration and live integrations are labelled separately. See each provider’s status.
- AIO Tests
- Xray
- Zephyr Scale
- TestRail
- Azure DevOps
- GitHub Actions
One governance layer
The independent quality-governance layer for AI-era software development.
Keep the tools your team trusts. Let The Warden determine whether the proof for each software change is sufficient.
Keep your stack
AIO Tests, Xray, Zephyr Scale, TestRail, Azure DevOps and CI integration paths, each labelled with its real status.
Independent decisions
Build-bound evidence, deterministic governance and auditable history.
Quality intelligence
Quality Memory and governed AI capabilities, under development.
Native Jira testing
Full test management is included if your team wants it.
Also included: native Jira test management
No test manager yet? Run the whole lifecycle where Jira work lives.
Author shared tests, execute them in cycles, raise defects with context and see coverage, without leaving Jira and without losing what each run actually tested. Use it instead of, or alongside, the tools you already have.
- Shared tests
One canonical test across Jira projects. No uncontrolled copies.
- Structured steps
Action, data and expected result. Paste up to 100 steps at once.
- Cycles and version-pinned attempts
Every attempt snapshots the test version, so edits never rewrite history.
- Contextual Jira defects
Raise a Bug from the failed step with cycle, environment, version and attempt filled in.
- Coverage
See requirement and release coverage without writing JQL.
- Optional migration
Import test cases from Xray, Zephyr Scale, AIO Tests or any CSV, only if you choose to.
- 1.Place an order for two items; ship only the first
- 2.Open Refund, choose Partial amount
- 3.Confirm the refund for the unshipped line
- No attempts yet. Not Run.
Shared test. One canonical test in the Shared Library, with structured steps and a version. It covers requirement PAY-318 and is used by two Jira projects, with no copies.
Read this scene as text
- Shared test. One canonical test in the Shared Library, with structured steps and a version. It covers requirement PAY-318 and is used by two Jira projects, with no copies.
- Attempt. A cycle runs the test. Attempt 1 snapshots test v3, so what you execute is exactly what was reviewed.
- Step fails. Step 3 fails. The tester records the actual result and creates the Jira defect from that step.
- Defect. The Jira Bug opens with context filled in: cycle, environment, test version, attempt and the failed step. It stays linked to the attempt.
- New version. After the fix the test gains a step and becomes v4. Attempt 1 still shows the v3 it ran against; editing never rewrites history.
- Re-run. Attempt 2 is pinned to v4 and passes. Coverage for PAY-318 now reads Passed, with both attempts and the defect on record.
The Warden
Agents write the code. Developers get a decision they can act on.
Deterministic policy owns clearance. A tool’s green result, an approval or an AI summary is evidence the policy weighs. It is never the decision.
- 01
Clear obligations
The contract says what proof a change needs before anyone pushes.
- 02
Actionable HELD reasons
A fixed reason code, the failing test by name and the next action. Not a score.
- 03
An exact-build decision
Every decision is for one repository, commit, build and environment.
- 04
Preserved history
A repair gets a new decision. The earlier HELD stays on record, tenant-isolated in your Jira site.
- Target
- acme/checkout-service · 9f3c2a1 · build 4821 · staging
- Reason
- evidence_failed
- Failing test
- checkout.refund.partial_amount
- Next action
- Resolve the failing evidence, then push. The new build gets a fresh decision; this one stays on record.
Illustrative example. The same facts reach people in Jira, in GitHub status feedback, over the Forge App REST API and through the developer pilot’s CLI and MCP tools.
Where developers meet it
- CI evidence. JUnit XML, SARIF 2.1.0 and JSON over Atlassian OAuth. The CI gate exits zero only for CLEARED on the exact build.
- API, CLI and MCP. Six read and request operations, a PowerShell client and an MCP server. Developer preview, live acceptance pending.
- Governed explanations. Optional AI can explain a decision, with citations. It cannot clear, hold or approve.
How it fits
A green result is evidence, not authorization.
Results from your test-management system, CI, scanners and authorized agents flow into The Warden, which records one decision for the exact change.
- Evidence producers
- Existing test-management systems
- CI
- Scanners
- Authorized agents
- Evidence ingestion and provenance validation
Each result is tied to an exact repository, commit, build, run and environment, and stored as an immutable receipt.
- Verification Contract and deterministic Warden policy
The contract says what must be proven. A pinned policy interprets the evidence. No model decides.
- The Warden records one decisionHELDNEEDS APPROVALCLEARED
- Where the decision is delivered
- Jira quality record
Changes workspace with decision, reasons and history.
Marketplace V1 — publicly listed - GitHub Check and job summary
Actionable HELD feedback on the pull request.
Developer preview — live acceptance pending - Audit evidence
Immutable receipts and append-only decisions.
Proven in development - Authorized workflow feedback
Developer API, CLI and MCP reads for people and agents.
Developer preview — live acceptance pending
The missing release decision
Your tools tell you what passed. The Warden tells you whether it’s enough.
SonarQube examines code quality. Harness coordinates delivery. JFrog AppTrust governs artifacts and supply-chain evidence. Xray and AIO manage testing. TestWarden specializes in the question that spans your Jira quality workflow: did this exact change satisfy the proof its verification policy requires?
Keep the stack you already trust. Add exact-build evidence, independent HELD/CLEARED decisions and a durable Quality Memory, without allowing an AI agent to sign off on its own work.
- SonarQubeCode quality and security analysis
- HarnessDelivery and release orchestration
- JFrog AppTrustArtifact and supply-chain evidence
- Xray · AIO TestsTest management and execution
- TestWardenIs the proof for this exact change sufficient? Decided by policy, recorded as HELD or CLEARED.
Two ways to adopt
Keep your tools, or add native testing. Either way, one authority decides.
Keep the tools your team trusts. The Warden decides whether the proof for each software change is enough.
- Path 1
Keep your tests. Add The Warden above them.
Your test-management system, CI, scanners and authorized agents keep running exactly as they do today. Their results become evidence. The Warden checks that evidence against a verification contract for the exact change and decides whether there is enough proof to proceed. You add a TestWarden subscription; nothing is retired.
Any complete JUnit XML or SARIF report from your CI is accepted today. Read-only connectors for AIO Tests, Xray, Zephyr Scale, TestRail and Azure DevOps are in source and still under acceptance. None is live.
See integration status - Path 2
Want native test management? It is built in.
TestWarden for Jira also includes a shared test repository, cycles, version-pinned execution, requirement coverage and an optional Migration Center for Xray, Zephyr Scale and CSV exports. Migration is a choice, never a requirement for using The Warden.
Migration is optional and CSV-based. It brings test cases and steps. Past execution results stay in your old tool.
Native test management
Quality Memory and governed AI
Where the product is heading, labelled honestly.
Quality Memory, Verification Intelligence and a Quality Agent are the approved direction. Each is marked with what is proven and what is still in development.
Quality Memory
A tenant-isolated history of tests, software changes, verification receipts, failures, decisions and observed outcomes, with provenance that authorized quality analysis can cite.
- Proven in development
Immutable receipts and append-only decisions, per Jira site
Expanded historical ingestion, retrieval and intelligence over that history
Nothing is pooled across customers, and nothing is trained on your data.
- Proven in development
Verification Intelligence
Advisory analyses grounded in your own evidence: coverage gaps, changed-code test impact, flaky-test and failure patterns, release risk and evidence-grounded recommendations.
Advisory analyses implemented in source. None is released, and none has a real model result accepted.
Advice only. It informs people and policy, and it can never clear, hold or approve a change.
Quality Agent
Designed to investigate quality problems, recommend test maintenance or repairs and take part in workflows that an administrator has explicitly authorized.
Proposal and approval workflow in source. The runtime is deliberately blocked until authorized write and verification adapters exist.
The agent never certifies its own work. A repaired change needs fresh independent evidence before The Warden can grant clearance.
How AI is governed
- Administrator opt-in with recorded consent, and per-capability switches.
- AI features read only evidence the signed-in user is already authorized to see.
- Tenant isolation: each Jira site’s history stays in that site’s own scope.
- Spending budgets and caps. Non-administrators do not see budget detail.
- Source provenance: output must cite real references, or no AI text is shown.
- Deterministic decision authority: policy owns CLEARED, HELD and NEEDS APPROVAL.
What is available to try
Optional AI explanation of a Warden decision, with citations: Developer preview — live acceptance pending. The Marketplace V1 version submitted for approval ships no AI and declares no external egress. The capabilities above are the approved development direction, not features you can switch on today. Details in AI and data handling.
Optional: Migration Center
Preview first. Reconcile every row.
If you choose to move test cases from Xray, Zephyr Scale or any CSV, you see what will import and why anything will not before a single test is written, then a report that accounts for every row.
Migration imports test cases. Integration keeps your tool and uses its results as evidence. They are different workflows, and you never need the first to use the second.
What migrates, and what stays- Move from XrayTest Case Importer CSV
- Move from Zephyr ScaleZephyr Scale CSV
- Generic CSVSpreadsheet or AIO Tests export
Choose. Pick the source: Xray Test Case Importer CSV, Zephyr Scale CSV, or a generic CSV such as an AIO Tests export. Here, a 412-row export.
Read this scene as text
- Choose. Pick the source: Xray Test Case Importer CSV, Zephyr Scale CSV, or a generic CSV such as an AIO Tests export. Here, a 412-row export.
- Map. Source columns map to TestWarden fields. Known layouts are detected; anything unmapped is kept as a custom field, not dropped.
- Preview. A dry run validates every row before anything is written: what will import, what will skip, and the reason for each exception.
- Import. The import runs in the background in batches with checkpoints. It is resumable and idempotent, so closing the panel loses nothing.
- Reconcile. The report accounts for every row. Test cases and their steps are in TestWarden; past execution results stay in your old tool, so export them there before you retire it.
Pricing
Free to 10 users. Then priced by your Jira site.
Standard includes The Warden, native test management and migration. Keeping AIO Tests or Xray? TestWarden is an additional subscription alongside them. Larger sites evaluate everything for 30 days first.
- 20 users
- $31.80
- per month. Founding example: $25.44
- 100 users
- $159.00
- per month. Founding example: $127.20
- 1,000 users
- $598.50
- per month. Founding example: $478.80
USD before taxes. Examples, not quotes: Atlassian Marketplace calculates the price from your licensed Jira users.
See pricing and the calculatorTrust
Built on Forge. Specific about data.
- Runs on Atlassian Forge in your Jira Cloud site. The submitted Marketplace version declares no external egress and ships no AI.
- Evidence access uses Atlassian OAuth with explicit scopes and current Jira role checks.
- Optional AI explanation is admin-enabled, consented and budget-capped. It never decides.
Now available on Atlassian Marketplace
Proof before progress.
TestWarden is listed on the Atlassian Marketplace for Jira Cloud. Keep your existing test-management and CI tools, and add The Warden's independent verification layer—or use TestWarden's built-in Jira test management. Visit the Marketplace to get started; we're here if you want guided setup or migration help.