Looking for Xray Best Practices: Naming Conventions and Test Organization

[Lena Wong]

Hi everyone,

I'm looking for some best practices from teams with solid experience using Xray.

I understand that Test Cases are reusable, but I'm still new to managing them across multiple projects. I'd love to learn what has worked well for your teams.

A few questions:

• What naming convention do you recommend for Test Cases and Test Executions?
• How do you name them so it's easy to navigate Jira and quickly understand what you're working on?
• Which fields do you consider mandatory for a Test Case and for a Test Execution?
• Do you use Components, Labels, or other Jira fields? If so, what do you use them for (e.g., application area, feature, release, team, environment, etc.)?
• Do you associate Test Cases with Epics, or do you prefer linking them only to Stories or other issue types? What has worked best for you and why?
• Should Test Cases be associated with a Sprint, or do you keep them sprint-independent and only associate Test Executions with a sprint or release?

I'm trying to establish a structure that will scale well and remain easy to maintain over time, so I'd really appreciate hearing about your experience, conventions, and any lessons learned.

Thanks in advance!

[Tomislav Tobijas]

Hi @Lena Wong ,

Since Xray is a Marketplace app, you may get more specialised input in the App Central group. Xray also has a useful collection of official guides and best-practice resources here: https://www.getxray.app/resources 📚

From my experience, the most important thing is to keep the structure simple and consistent:

• Name Tests by feature + scenario + expected outcome, rather than by sprint or release, so they remain reusable.

• Name Test Executions by release/sprint + environment + execution type, for example: "Release 2.4 - UAT - Regression".

• Keep Test Cases sprint-independent. Associate the related requirement or Story with the Test, and use Test Executions or Test Plans for sprint/release-specific tracking.

• Use Components for stable application areas and controlled fields for environment, test type, priority or team. I would avoid relying too heavily on Labels, as they can quickly become inconsistent.

• Link Tests to the lowest meaningful requirement, usually a Story, while Epics are better used for broader coverage and reporting.

I would need to ask our Test Manager to actually give you some explicit examples, as he's mainly working on this part - either with Zephyr or Xray. 👀

Hopefully someone else will also chime in to potentially provide some real-life examples here.

Cheers,
Tobi