The current Use Case is from an existent Xray Customer. Please do not use it as a standard approach or interpreted as the "right way" to use Xray.

Xray is a flexible tool and should be adapted to your own use case. Be inspired.

Content

Team Profile

Industry	Life Sciences
Using Xray	Xray DC since 2024
Using Xray	For: Testing new features Validate requirements Manage System Integration Test (SIT) - regression
Testing Team	-
Testing Team Organization	-
End users profile	Agile Testing Teams
Extra details	GxP ; SOX compliance High need for control and restrictions around testing entities Demand for audit readiness and traceability for long retention periods.

Xray Features highlights

In this use case, the customer takes advantage of:

Xray being seamlessly integrated with Jira, in particular, uses Jira Workflows to manage and control Xray Entities
Configuration restrictions applied to workflows to guarantee permission control
Document Generator to build baselines (snapshots of data on a specific period) - Requirement Traceability Matrix

Team choice for the top Xray Feature

The most important feature is the ability to take advantage of jira workflow controls to completely manage permissions, implement post functions and create automation that enforces a strict process.

In particular, Xray provides the ability to restrict test execution for tests in specific status - approved. For example, Tests in draft status can not be executed.

With a combination of Xray unique configuration possibilites and Jira workflow out-of-box capabilities, the team can configure workflows that are in compliance with regulated markets demand.

Integration with other tools

eSign - to enforce approvals with electronic signatures
Jira Workflow Misc - to leverage automation and workflow conditions
Risk Manager Plus - to improve risk management
easeRequirements - to manage requirements (that then will be covered by tests)

Xray Configuration & Customization

Xray Project Organization

Backlog project - The backlog project is used for agile development, and it contains: Epics, Stories, Bugs, Tasks, Sub-tasks, Test Plans, Test Executions, and Sub Test Executions.
Specification project - The specification project is used for regulatory deliverables, and it contains: Requirements, Risks, Tests, Preconditions, Test Sets, Test Plans, Test Executions, and Sub Test Executions.

Test Status created

There wasn't the need to create new Test Status.

Custom fields created:

Regulatory impact fields (GxP ; SOX, none) - that will impact on the approval flow
Risk fields - high risk test, low risk test
Revision number - automated counting for the number of times the test case went on the approval proccess
Purpose of the test - happy path test, edge condition test , etc.
Business Approver - Identification of the user that needs to electronic sign the test
Technical Approver - Identification of the user that needs to electronic sign the test
Quality Approver - Identification of the user that needs to electronic sign the test

Custom fields created have high impact on conditions/restrictions for the approval workflow.

Workflows

Workflow for Tests

Some rules behind it:

In this workflow, the status "New" & "Draft" are editable. When the test is sent for Approval the Test Case is locked, not allowing to edit fields or test steps.

A Test can only be executed when in status "Approved".

By moving a Test to pending approval, the eSign integration will allow specific users to digital sign the workflow.

Other configurations

The ability of restricting execution based on the status of tests is a key factor and a differentiator from other testing management apps.

Testing Practices Details

Writing Tests

When creating a Test there are additional custom fields that contribute to the workflow steps sequence (more or less restrict)
After creating a Test, there is a very restrict approval process to ensure that only approved and validated tests are executed.
An integration with eSign, enforces the need for digital signature at the approval process.

Planning & Organization Tests

Test are typically organized in the Test Plan Board into folders ( that can be different depending on the test scope)
Test sets are also used to create "repeatable" test efforts. For example, end-to-end (E2E) tests that are re-executed with every release.
Test Plans are created by sprint and per release.

Executing Tests

Depends on the testing scope, usually Test executions are created by folder of the Test Plan.
Test Execution has also custom fields (similar to Test) that contribute to the workflow rules.

Analysing Results ( Reports)

Report	Used for
Test Execution Detail Report (Doc Generator)	Generated on demand ( when auditing) to showcase the test execution, all evidences, attachments, etc.
Test Runs Summary Gadget	At the release level summarises all testing
Requirement Traceability Matrix (Doc Generator)	Generated at the Release Date and imported to a Document Management System to ensure audit readiness.