Allow the Remote Jobs Trigger to optionally respect active Test Execution filters, enabling CI/CD pipelines to run only the filtered subset of Tests instead of all Tests in the Test Execution.

Description

Provide an option for the Remote Jobs Trigger to respect the currently applied Test Execution filter when generating the ${TESTS_KEY} payload. For example, when a user filters a Test Execution to display only failed Tests and triggers a remote job, only the filtered Tests should be sent to the CI/CD pipeline.

User friction

Users often need to rerun only a subset of Tests, such as failed Tests. Although Xray allows filtering within a Test Execution, the Remote Jobs Trigger ignores the filter and sends all Tests associated with the Test Execution. This creates additional manual steps and makes the filtering functionality less intuitive in the context of remote execution.

Steps to reproduce (right now) / Actual Result:

• Create a Test Execution containing multiple Tests.
• Execute the Tests and obtain a mix of statuses (PASS, FAIL, etc.).
• Apply a filter, such as Execution Status = FAIL.
• Trigger a Remote Job from the Test Execution.
• Inspect the ${TESTS_KEY} payload received by the CI/CD system.

Actual Result:
 All Tests from the Test Execution are included in ${TESTS_KEY}, regardless of the active filter.

Expected Result:
 An option should be available to send only the Tests currently matching the active filter.

IMPACT

The current behavior introduces unnecessary overhead when teams need to rerun only a targeted subset of Tests. Users must create additional Test Executions solely to align the execution scope with the desired remote job payload.

What would improve if solved:

• More intuitive user experience.
• Faster rerun workflows for failed Tests.
• Reduced need to create temporary or duplicate Test Executions.
• Better integration between Xray filtering capabilities and CI/CD automation.
• Fewer manual preparation steps before triggering automated executions.
  Impact on stakeholders:

Improves efficiency for testers and QA teams by reducing manual effort and simplifying targeted test reruns through CI/CD pipelines.

Current workaround:

Filter the desired Tests, create a new Test Execution containing only those Tests, and trigger the Remote Job from the newly created Test Execution.

CONTEXT & EXAMPLES:

A common use case is rerunning only failed Tests after a pipeline execution. Users naturally expect the filtered view to represent the scope of the next action. However, triggering a Remote Job currently ignores the filter and uses the complete Test Execution scope.

Concrete example:

A Test Execution contains 100 Tests:

• 90 PASS
• 10 FAIL

The user filters the execution to show only the 10 failed Tests and triggers a GitLab pipeline.

Current behavior:
 ${TESTS_KEY} contains all 100 Test keys.

Desired behavior:
 ${TESTS_KEY} contains only the 10 filtered failed Test keys, or a configuration option allows users to choose between sending all Tests and only the filtered Tests.

Workaround risk:

Creating additional Test Executions increases administrative effort and may result in:

• Proliferation of temporary Test Executions.
• Increased maintenance overhead.
• Reduced traceability when multiple executions are created solely to support reruns.
• Greater risk of users triggering the wrong Test Execution by mistake.