Xray for Jira: The Six Testing Entities You Need to Know

By markjc Thu May, 2026 (0)

Xray for Jira: The Six Testing Entities You Need to Know

0

Vote for this post

Click the arrows to vote • 1 vote per logged in user
Login to Vote

Xray for Jira: The Six Testing Entities You Need to Know

If you have ever tried to manage test cases, UAT sign-offs, or regression suites directly inside Jira and felt like something was missing — it probably was. Xray plugs that gap by introducing a set of dedicated issue types that turn Jira into a fully-featured test management platform. Understanding these six entities is the fastest way to get productive with Xray from day one.

Why Xray Extends Jira Rather Than Replacing It

Most test management tools sit outside your development workflow and require constant synchronisation with Jira. Xray takes the opposite approach: it lives inside Jira, using native issue types, workflows, and permissions. Your testers, developers, and business stakeholders all work in the same environment they already know. Requirements, bugs, and test results are linked directly — no imports, no exports, no drift between systems.

The architecture is built around traceability. Every test you run can be traced back to the requirement it covers, and every failure can automatically generate a linked bug. That chain — from requirement through test design to execution result — is what makes Xray genuinely useful rather than just another checklist tool.

The Six Core Entities

Xray introduces six issue types into Jira. Five are created directly by your team; the sixth is generated automatically in the background. Together they cover the full arc from test design through to recorded results.

Entity	What It Is	Practical Example
Test	The core test case definition. Can be Manual (step-by-step), Cucumber (Gherkin language), or Generic (unstructured, often used as an automation ID reference).	A login test: Step 1 — enter username. Step 2 — enter password. Step 3 — click login. Expected: dashboard loads.
Pre-Condition	Defines the required state before a Test can run. Reusable across multiple Tests, so you write it once and attach it wherever it applies.	"User must be logged out" or "Database must contain product SKU-123."
Test Set	A flat, static list for grouping Tests logically. Think of it as a named folder — "Smoke Tests," "Checkout Regression," "Sprint 24 UAT."	All tests covering the Checkout module collected into one Test Set for easy assignment and export.
Test Plan	A dynamic, higher-level entity that organises Test Executions around a specific goal — a release, a sprint, or a UAT phase. Provides a live progress dashboard.	"Sprint 24 Test Plan" — shows at a glance how many executions are passing, failing, or still to be run.
Test Execution	The actual testing session. You assign a tester (or a CI/CD pipeline), specify the environment and build revision, and run a defined set of Tests against it.	"Regression Suite — Build 4.2 on Staging" assigned to the QA team for Tuesday afternoon.
Test Run	Internal entity — not created manually. Generated automatically for every Test included in a Test Execution. Records the Pass/Fail result, comments, and evidence for that specific test at that specific moment.	The result of the Login Test run at 10:05 AM on Chrome 124, with a screenshot of the failure attached.

The Key Insight Test Sets are static collections you curate. Test Plans are dynamic dashboards you track. Test Executions are the actual work sessions. Keep these three distinct in your mind and the rest of Xray's structure falls into place immediately.

How the Entities Fit Together in Practice

The relationship between these entities follows a natural flow. You write Tests and attach Pre-Conditions to them during the design phase. You then group those Tests into Test Sets by logical theme. When a sprint or release approaches, you create a Test Plan to track the campaign, then create one or more Test Executions underneath it — each representing a specific run on a specific environment or build. As testers work through an Execution, Xray automatically creates a Test Run record for each Test, capturing the individual result.

The result is a complete audit trail. You can answer questions like "Which tests passed on Build 4.1 but failed on Build 4.2?" or "Which requirements are not yet covered by any passing test?" directly from your Jira dashboard — without any manual collation.

Xray Test Plan dashboard showing execution progress and coverage

The Automation Angle

For teams running automated test suites, the Generic Test type combined with the Test Execution entity is where Xray really earns its place. Automated frameworks like Selenium, Cypress, or JUnit produce machine-readable results (JUnit XML, Cucumber JSON). Xray's REST API ingests these results directly, maps them to the appropriate Test Runs, and updates your Test Plan coverage in real time. Your CI/CD pipeline pushes a build, the tests run, and Jira reflects the results — no human in the loop required.