QAM Hub vs Xray: Jira-Native or Standalone Test Management

QAM Hub bills for the people who test; Xray bills for your whole Jira instance, testers or not. A standalone TMS with native automation results and flakiness history, against test cases that live as Jira issues.

Facts verified on 20 September 2026

Xray is test management built as a Jira app, so your test cases are Jira issues and your billing follows your Jira instance rather than your QA team. That single design decision is the whole comparison. If your Jira user count is close to your tester count and your team already lives in Jira, Xray is a reasonable and cheap answer. If you have 200 Jira users and eight testers, you are licensing Xray for 200 people, and a standalone test management system like QAM Hub costs less while giving you automation results, flakiness history and cross-project reporting that Xray either charges extra for or does not have.

What you are actually choosing between#

The category treats Jira-native test management as a feature. It is closer to an architectural commitment. In Xray, a test is a Jira issue type, a test execution is a Jira issue type, and a precondition is a Jira issue type. Everything you gain from that follows from one property: your test assets sit in the same permission model, the same search index and the same reporting surface as the rest of your delivery work. Everything you lose follows from the same property.

The gains are real and worth stating plainly. Linking a test to a story is not an integration, it is a Jira link. A developer who has never opened a test management tool can read the test that failed against their ticket. Xray's BDD support puts Gherkin scenarios in Jira where the product owner can see them, which is closer to the original intent of BDD than most tooling manages.

The losses are structural rather than a matter of missing features. Jira's data model has no concept of a run, so Xray invents one as another issue type. It has no concept of an automated result with a trace file attached, so ingest becomes an API import. And Jira's licensing model has no concept of a person who does not test, which is where the money goes.

The licensing arithmetic, which is the real decision#

This is the part most comparison articles get wrong, including ones that quote a per-user price for Xray as if you pay it per tester.

Atlassian's Marketplace licensing terms are unambiguous. The instruction to buyers is to "purchase the license tier that matches the number of users you have licensed for your host product", and the consequence is spelled out: the app "will only function if its license matches or exceeds the tier of the host product", and Atlassian adds that this holds "even if only some of your licensed users need to use the app." That last clause is the entire argument, written by Atlassian rather than by us.

So the question to ask before pricing Xray is not how many testers you have. It is how many Jira licences your company holds. In a 50-person engineering organisation where everyone has Jira and six people test, you are buying 50 seats of a test management tool for six testers. Xray's own page advertises "$100/yr for 10 Users", which works out at "$0.83 /mo" per user and is genuinely cheap at that size. The same arithmetic at 200 Jira users is a different conversation, and the vendor's tier selector goes up to 150,000.

Maximum quantity billing makes the ceiling the price#

Since 2025 Atlassian bills monthly cloud subscriptions on peak usage rather than end-of-period usage. Atlassian's support documentation states it directly: "Your bill is based on the maximum amount of users you have throughout your billing period." The rollout began on 14 July 2025 with completion expected in October 2025, it applies to monthly subscriptions, and Marketplace apps are named in the list of products it covers alongside Jira and Confluence.

For a QA team this has a specific and irritating consequence. Onboard thirty contractors for a two-week push, off-board them, and the month bills at the peak. Nothing about your testing changed, nobody new ran a test, and the Xray line on the invoice moved. Annual subscriptions are not affected, which is worth knowing before you choose a billing interval: on Atlassian, monthly flexibility now has a price attached to it.

If your Jira user count is stable and close to your tester count, none of this matters and you should stop reading this section. It is a problem specific to organisations where Jira spread further than testing did, which is most organisations above about fifty people. The same arithmetic applies to Zephyr and to every other Marketplace app, which is why switching Jira apps does not solve it.

Three editions across two Marketplace apps#

Xray's packaging deserves a paragraph because it is easy to price the wrong thing. The main Marketplace listing, Xray – Test Management for Jira from Xblend, sells Standard and Advanced editions. Xray Enterprise is a different Marketplace listing with its own install base and its own reviews. Comparisons that say "Xray has three tiers" are describing two products. If you are still deciding whether you need a Jira test-management app at all, that is the prior question and it has a different answer.

The edition split matters more than the names suggest. On the vendor's comparison table, read 20 September 2026, Standard does not include cross-project reporting and traceability, the manual step library, or the usage monitor. Storage is 100 GB on Standard against 250 GB on Advanced, and the API is rate-limited at 60 requests per minute against 100.

Cross-project reporting being an upgrade is the row to notice. A QA lead responsible for four products who buys Standard cannot answer "how is quality across my portfolio" without moving up an edition, and at Xray's licensing basis moving up an edition means moving the whole Jira instance up an edition. That is the same purchase decision as the one in the previous section, arriving from a different direction.

Xray's AI in 2026, and the limit nobody quotes#

Xray's AI runs on Sembi IQ, the shared AI platform across Sembi's testing brands. Worth stating once, factually: Xray, TestRail and Testmo are all Sembi (Idera) brands. Sembi launched as a unified portfolio brand on 23 January 2025, and on 24 June 2026 announced AI test prioritization for TestRail and Xray in the same release. A team shortlisting Xray against TestRail and Testmo to compare vendors is comparing one company's three products on one AI stack. That is normal industry consolidation and has genuine upsides, including a shared roadmap. It is only worth knowing because nobody in the category says it.

What actually shipped, from Xray's Summer '26 release recap published on 6 August 2026: AI Test Prioritization and the Rovo Test Plan Summarizer at general availability, AI test script suggestions, API key rotation with scopes and expiry, and a migration to Atlassian Forge. MCP support is listed as coming soon, so an assistant cannot yet read an Xray instance directly through a protocol interface.

Now the number. Xray's own announcement post of 30 June 2026 states the prioritization ceiling per edition: up to 75 tests on Standard, 150 on Advanced, 300 on Enterprise. Prioritization is the AI feature with the clearest value in a large regression suite, and a large regression suite is exactly where a 150-test ceiling bites. If you run 1,800 regression cases, the feature ranks a slice and you choose the slice by hand first, which is some of the work you wanted the feature to do.

Two caveats, because the vendor is not consistent and you should not be caught out by it. The pricing comparison table places AI Test Script Generation on the Advanced edition; the June blog post says AI-generated test scripts are "available in Xray Enterprise". Both were live on 20 September 2026. And the Summer '26 recap describes administrator reporting that covers AI usage and credit consumption, while no credit allowance, rate or overage figure appears on any Xray page we could find. Treat "how much AI do I get" as a question to put to the vendor in writing, not one the published material answers.

QAM Hub's side of this row is short by design. AI features are included in every plan, sized so that a working team does not run into a limit, subject to fair use, with the allowance growing as you add seats. There is nothing to buy separately, no overage, and no per-run cap on how many tests an analysis will look at. What each plan includes is on our pricing page.

Feature comparison#

QAM Hub facts from the product as shipped on 20 September 2026. Xray facts from getxray.app, the Atlassian Marketplace listings and Xray's product blog, all read on 20 September 2026.

What the ratings actually say#

This is a case where stating the review counts works against the easy argument, so here it is in full.

Several published comparisons, including some in our own round-up of the best test management tools, quote the G2 figure of 4.2 across 19 reviews and let the reader infer that Xray is thinly reviewed for a product claiming scale. That inference is wrong. Xray's buyers do not review on G2 because they buy through the Atlassian Marketplace, and there the sample is 552 reviews at 4.3 against 25,325 reported installs. Nineteen reviews is not evidence of a small product, it is evidence that G2 is the wrong place to look for this one. We would rather lose the cheap point than repeat it.

Where Xray genuinely wins#

Price at small Jira scale. Under ten Jira users, roughly a hundred dollars a year for real test management is unbeatable, and the whole-instance argument above simply does not apply to you.

BDD that non-engineers can read. Gherkin scenarios as Jira issues, visible to the product owner in the tool they already use, with the automated step definitions bound to the same scenario. Standalone tools support BDD; few make it a shared artifact this naturally.

One permission model. Jira project permissions, Jira audit, Jira SSO. Nothing extra to configure, review or justify to a security team, which in some organisations decides the question on its own.

The Atlassian AI stack. If your company has already committed to Rovo, the Test Plan Summarizer is in the assistant your people already open, and that integration is not something a standalone tool can offer.

Where a standalone system wins#

You pay for testers. The seat count is the number of people doing the work, plus a free read-only viewer for each of them. A stakeholder who only reads reports costs nothing, and growing the Jira instance does not change the bill.

Automated results arrive with their evidence. A Playwright run uploads as a run: trace, video, screenshots, durations, per-case status, attached to the case record rather than pasted into a comment. From there the stability history is a by-product rather than a project.

Flakiness becomes a managed object. Stability trend over 7 to 90 days, quarantine with a record of what is quarantined and since when, and cross-run regression detection. Most of the category, Xray included, reports what happened in a run and leaves the pattern across runs to whoever notices it.

Portfolio view without an upgrade. The cross-project Critical / Warning / Healthy matrix is there on both plans with org-wide thresholds an admin edits. In Xray the equivalent sits behind the Advanced edition, which in Xray's billing model means upgrading for the whole instance.

Jira stays Jira. This is not an argument against Atlassian. QAM Hub integrates with Jira, pulls requirements, creates issues from failures and publishes coverage back onto the issue. The difference is that your test assets do not depend on your Jira licence for their existence.

Leaving Xray: what it costs and what to do about it#

Be realistic about this before you start, because it is the least pleasant part of the switch and the part vendors are quietest about.

Test cases move reasonably well. Jira's built-in CSV export with all fields carries the case data, and Xray's REST API carries more, including custom field values and linked requirements. The honest caveat is attachments: a CSV route does not bring images and attachments with it, so anything visual in your cases needs the API path or a manual pass.

Execution history is the hard part, and Xray says so itself. Its documentation states that Xray "does not currently provide an out-of-the-box solution for migrating execution-related information", leaving a custom REST API implementation as the route. That is a genuine limitation of the source tool and it applies whichever destination you pick, us included. We do not ship an Xray import wizard today; we ship a TestRail one. For Xray the path is CSV or API for the case library, JUnit XML for the automation results going forward, and a deliberate decision about how much execution history is worth writing code to rescue.

The practical answer most teams land on: migrate the library, run both systems in parallel for one release, treat the historical execution data in Xray as an archive you keep read access to rather than something you carry across. Budget half a day for the library and a full release cycle of parallel running. Anyone promising an afternoon has not tried it. If you are weighing several destinations rather than just this one, Xray alternatives covers the wider field.

When you should not switch at all#

Stay on Xray if your Jira user count is genuinely close to your tester count, because then you are paying roughly what a standalone tool would cost and you get Jira-native workflow for free. Stay if your testing is BDD-first and the Gherkin scenarios are read by people who will never open a second tool. Stay if your security review of a new SaaS vendor costs more than the licensing difference, which is a real number in regulated organisations and is frequently the deciding one. And stay if you are mid-migration onto Atlassian Forge or mid-anything else; changing two things at once is how a switch gets blamed for problems it did not cause.

Switching makes sense when a specific thing is costing you: seats for people who do not test, automated results that live somewhere other than your test cases, a flaky suite nobody is measuring, or a portfolio question you cannot answer without an edition upgrade. If none of those is true, the honest recommendation is to keep what works.

How we compared these tools#

Xray's features, editions and limits were read from the vendor's own product page, product blog and documentation, plus the Atlassian Marketplace listings, on 20 September 2026. Licensing and billing claims come from Atlassian's published licensing and support documentation rather than from third-party summaries. Ratings are quoted with their review counts and the date they were read, because a score without a sample size is not evidence. Prices change; the verification date on this page is the date it was last checked, and these pages are re-verified quarterly.

QAM Hub is built by QA Madness, so treat our ranking of ourselves accordingly and check the working above. Every Xray fact on this page is sourced to a page you can open yourself.