Xray für Jira ist ein Test-Management-Add-on, das Testfälle als Jira-Issues führt und automatisierte Testergebnisse über eine REST-API entgegennimmt. Die Tests selbst laufen außerhalb, in Ihrem Framework und Ihrer Pipeline. Nach dem Lauf schickt der CI-Job eine Ergebnisdatei an einen Importendpunkt, und das Tool erzeugt daraus eine Test Execution mit einzelnen Test Runs. Das Marketplace-Listing „Xray - Test Management for Jira“ zählt 25.603 Installationen, 552 Bewertungen und 4,3 von 5 Punkten (Atlassian Marketplace, Stand 30. August 2026).

Kurz gefasst: Xray führt Testfälle, Ausführungen und Fehler als Jira-Issues und nimmt automatisierte Ergebnisse über 8 REST-v2-Endpunkte entgegen, je einen pro Format von JUnit XML bis Behave JSON. Die Ausführung übernimmt Ihr Testframework. Xray ordnet die eingehenden Ergebnisse per Test Key den passenden Test-Issues und deren verknüpften Anforderungen zu.

Abbildung 1: Die 7 Objekttypen, die Xray in Jira ergänzt.

Was ist Xray für Jira?

Xray für Jira ist eine Test-Management-App, die Jira um Testfälle, Testausführungen und Testergebnisse als eigene Issue-Typen erweitert. Die Dokumentation des Herstellers nennt sie „A complete Test Management tool for Jira“ und hält fest, dass für den Betrieb keine weitere Software nötig ist (Xray Docs, 2026).

Entwickelt wird die App von Xblend, vormals Xpand IT. Idera, Inc. übernahm sie im Mai 2021 zusammen mit dem Schwesterprodukt Xporter (Businesswire, 2021). Im Marketplace stehen zwei getrennte Listings: „Xray - Test Management for Jira“ (App 1211769) und das neuere, eigenständige „Xray Enterprise“ (App 1229688).

Auf der eigenen Website nennt der Hersteller über 10.000 Unternehmen, 135 Länder und mehr als 100 Millionen Testfälle (Stand 30. August 2026). Das sind Angaben des Herstellers, keine unabhängig geprüften Zahlen. Für die Cloud gibt es 2 Editionen: Standard und Advanced, das zusätzlich KI-gestützte Testskript-Erzeugung, erweiterten API-Zugriff und mehr Speicher enthält. Was Testmanagement als Disziplin jenseits des Werkzeugs umfasst, klärt der Überblick dazu.

Welche Objekte kennt Xray in Jira?

Xray ergänzt Jira um 7 Objekttypen, die zusammen das Testmodell bilden: Test, Precondition, Test Set, Test Plan, Test Execution, Test Run und Sub Test Execution. Wer diese 7 Begriffe trennt, versteht jeden Bericht und jede API-Antwort.

Zwei dieser Definitionen lohnen sich im Original. Der Hersteller schreibt: „A Test Execution is an Issue type that aggregates a user-determined collection of Tests. It monitors and verifies if those Tests are working as expected in a target context and environment.“ Und direkt danach: „An association between a Test Execution Issue and a Test Issue is called a Test Run. Hence, a Test Execution is a list of Test Runs.“ (Test Execution, Produktdokumentation, 2026).

Ein Detail beim Test Set überrascht viele Teams: Beim Hinzufügen landen dessen Tests in der Test Execution, spätere Änderungen am Test Set wirken jedoch nicht auf diese Ausführung zurück. Das Test Set bleibt nicht dauerhaft mit ihr verknüpft.

Bei den Testarten gibt es 3 Werte: Manual, Cucumber und Generic. Eigene Testtypen sind Bezeichnungen; technisch bildet das Tool jeden automatisierten Test auf Cucumber oder Generic ab. Die Sprache hinter dem Cucumber-Typ behandeln der Beitrag zu Cucumber und ausführbaren Szenarien und die Referenz zur Gherkin-Syntax.

Über welche Endpunkte kommen automatisierte Testergebnisse nach Jira?

Automatisierte Ergebnisse gelangen über 8 Importendpunkte der Xray-Cloud-REST-API v2 nach Jira, je einer pro Ergebnisformat. Die Dokumentation formuliert es so: „Execution results can be imported to Jira through JSON/XML representation formats specified in Integrating with Testing Frameworks or using the proprietary Xray JSON format“ (Xray Docs, 2026).

Abbildung 2: Vom Pipeline-Lauf über den REST-Import zur Test Execution.

Jeder dieser Endpunkte hat eine Variante mit dem Suffix /multipart, die zusätzlich JSON mit Issue-Feldern entgegennimmt. Damit steuert der CI-Job, wie die erzeugte Test Execution in Jira aussieht. Für Teams mit bestehender JUnit-XML-Ausgabe ist das der kürzeste Weg von der Pipeline ins Testmanagement.

Wie authentifizieren sich Xray Cloud und Server/Data Center unterschiedlich?

Die Authentifizierung ist die häufigste Fehlerquelle beim ersten Import: Xray Cloud nutzt eine eigene Anmeldung auf App-Ebene, Server und Data Center hängen sich an die Benutzeranmeldung von Jira.

Abbildung 3: Authentifizierung in Xray Cloud und in Server/Data Center im Vergleich.

In der Cloud legen Sie in den Xray Global Settings unter API Keys einen Schlüssel für einen Benutzer an. Dessen client_id und client_secret schicken Sie per POST an https://xray.cloud.getxray.app/api/v2/authenticate und erhalten ein Bearer-Token zurück. Das Token ist 24 Stunden gültig (Authentication REST v2, Produktdokumentation, 2026). Ein CI-Job holt es daher zu Beginn jedes Laufs neu.

Server und Data Center verwenden die REST-Authentifizierung von Jira selbst: HTTP Basic Auth oder Personal Access Tokens, verfügbar seit Jira 8.14, gesendet als Authorization-Header mit Bearer-Token (REST API für Server und Data Center, 2026). Ein Skript, das gegen die Cloud läuft, funktioniert dort ohne Anpassung nicht.

Wie richten Sie den Ergebnisimport ein?

Der Ergebnisimport ist in 6 Schritten eingerichtet, wenn die Vorbereitung stimmt. Vorher brauchen Sie:

• Ein Jira-Projekt, in dem Xray aktiviert ist, und Schreibrechte auf die zugehörigen Issue-Typen.

• Einen API-Key (Cloud) oder ein Personal Access Token (Server/DC) für einen technischen Benutzer.

• Eine Testautomatisierung, die eines der 8 unterstützten Ergebnisformate schreibt.

• Test-Issues in Jira, deren Keys im Automationscode referenziert werden können.

1. Legen Sie die automatisierten Testfälle als Test-Issues in Jira an und notieren Sie deren Issue-Keys.

2. Hinterlegen Sie den Test Key im Automationscode, etwa als Annotation oder Tag am jeweiligen Testfall. Standardmäßig ist der Test Key das Element, über das die App ein importiertes Ergebnis dem richtigen Test zuordnet.

3. Verknüpfen Sie jedes Test-Issue über den Link-Typ „Tests“ mit der Story oder Anforderung, die es abdeckt. Ohne diese Verknüpfung bleibt jeder Traceability-Bericht leer.

4. Erzeugen Sie den API-Key beziehungsweise das Token und legen Sie beides als Secret in der Pipeline ab.

5. Ergänzen Sie im CI-Job nach dem Testlauf einen POST der Ergebnisdatei an den passenden v2-Endpunkt. Wer Felder der Test Execution setzen will, nutzt die /multipart-Variante.

6. Prüfen Sie die erzeugte Test Execution in Jira: Enthält sie die erwarteten Test Runs, und stimmen Status und Zeitstempel?

Schritt 6 gehört in jeden Pipeline-Lauf. In Kundenprojekten sehen wir häufig Importe, die monatelang stillschweigend leere Executions erzeugen, weil niemand diese Prüfung automatisiert hat. Wie sich Testläufe und Qualitätsprüfungen in Build-Pipelines einbetten lassen, beschreibt der Beitrag zur Testautomatisierung in CI/CD.

Was zeigt der Requirement Traceability Report?

Der Requirement Traceability Report zeigt laut Dokumentation „the Requirements traceability through Tests, Test Runs, and Defects“ (Xray Docs, 2026). Der Bericht folgt einer Anforderung in beide Richtungen und kommt mit mehrstufigen Hierarchien zurecht, etwa Epic, Story und Sub-Task.

Grundlage ist die Verknüpfung aus Schritt 3: Test-Issues zeigen über den Link-Typ „Tests“ auf Story- oder Anforderungs-Issues. Aus diesen Verbindungen entsteht in den Berichten ein Requirement Status. Ein begleitender Coverage-Bericht gibt „an overview of the requirement’s current status, its coverage by tests and executions and reported defects“ und steht auch als Dashboard-Gadget „Overall Test Coverage“ bereit (Overall Test Coverage Gadget, Produktdokumentation, 2026).

In regulierten Umgebungen entsteht hier der Nachweis. Welche Spalten ein Prüfer erwartet, behandelt der Beitrag zur Traceability-Matrix.

Führt Xray automatisierte Tests aus?

Nein. Xray führt keine automatisierten Tests aus. Es steuert weder Browser noch APIs noch Mobilgeräte, sondern nimmt fertige Ergebnisse per REST-Import entgegen und ordnet sie ein. Ein Beitrag in der Atlassian Community, das heißt nutzergenerierter Inhalt ohne redaktionelle Prüfung, beschreibt den Ablauf treffend: „Execution of the automated test pipeline imports results into Xray, creating test executions and test runs“ (Atlassian Community, 2026).

Abbildung 4: Ausführung und Verwaltung sind zwei getrennte Schichten.

Der Test-Key-Mechanismus aus Schritt 2 erklärt, warum das so ist. Die App erfährt von einem Testlauf erst, wenn eine Ergebnisdatei ankommt, in der ein bekannter Test Key steht. Bis dahin existiert der Testfall in Jira als Dokument. Ausführung, Wartezeiten, Retries und Selektoren liegen vollständig beim Automationswerkzeug.

Genau hier ergänzen sich die beiden Schichten. Autemos ist eine KI-gestützte Software für Testautomatisierung und damit eine Ausführungsschicht: Web-, Mobile-, API- und Desktop-Tests, Ergebnisse über Allure, Anbindung an Jira/Xray, GitLab, GitHub Actions, Jenkins und HP ALM. Die fachliche Ordnung der Ergebnisse gegen Anforderungen bleibt in Xray. Wie sich wiederkehrende Abläufe strukturieren lassen, zeigen die Test-Workflows.

Was kostet Xray für Jira?

Der Preis richtet sich nach der Anzahl der Jira-Benutzer, wie bei Marketplace-Apps üblich. Eine belastbare Tarifübersicht ließ sich zum Stand 30. August 2026 nicht aus erster Hand bestätigen: Der Pricing-Tab des Marketplace-Listings lieferte beim Abruf keine Tarifdaten aus.

Die einzige Preisangabe aus erster Hand gehört zum getrennten Produkt Xray Enterprise und trägt auf der Herstellerseite einen Vorbehalt zur Gültigkeit. Sie beschreibt nicht die Preise des Test-Management-Listings. Prüfen Sie deshalb den Pricing-Tab des Marketplace-Listings mit Ihrer tatsächlichen Nutzerzahl.

Für den Vergleich mit Zephyr Scale, TestRail, qTest oder Azure Test Plans lohnt der Blick in die Übersicht der Testmanagement-Tools. Ein Punkt daraus gehört hierher: TestRail und Azure Test Plans sind nicht Jira-nativ. TestRail bindet sich über eine offizielle Integration und eine begleitende Jira-App an; die Verwaltung bleibt außerhalb von Jira (TestRail Support, 2026).

Häufig gestellte Fragen

Die 5 häufigsten Fragen betreffen Ausführung, Formate, Authentifizierung, Zuordnung und Editionen. Alle Antworten stützen sich auf die Cloud-Dokumentation des Herstellers (Import Execution Results REST v2, 2026).

Kann Xray automatisierte Tests selbst starten?

Xray startet keine automatisierten Tests. Es ist eine Management- und Reportingschicht in Jira, die Ergebnisse per REST-Import entgegennimmt. Browser, API-Clients und Mobilgeräte steuert Ihr Automationswerkzeug, etwa Selenium, Playwright oder Autemos.

Welche Ergebnisformate importiert Xray?

Die Cloud-Edition importiert 8 Formate über die REST-API v2: Xray JSON, Cucumber JSON, JUnit XML, NUnit XML, xUnit XML, TestNG XML, Robot Framework XML und Behave JSON. Jeder Endpunkt hat eine /multipart-Variante, die zusätzlich JSON mit Issue-Feldern annimmt.

Wie unterscheidet sich die Authentifizierung in Cloud und Data Center?

Xray Cloud nutzt einen eigenen API-Key: client_id und client_secret gehen per POST an den Authenticate-Endpunkt und liefern ein Bearer-Token mit 24 Stunden Gültigkeit. Server und Data Center nutzen die Jira-eigene Anmeldung: HTTP Basic Auth oder Personal Access Tokens ab Jira 8.14.

Wie ordnet Xray ein Ergebnis dem richtigen Testfall zu?

Standardmäßig ordnet Xray über den Test Key zu. Der Automationscode referenziert den Issue-Key des Test-Issues, etwa per Annotation. Fehlt der Key, entsteht keine belastbare Verbindung zur Anforderung.

Welche Xray-Editionen gibt es in der Cloud?

Xray Cloud bietet Standard und Advanced. Advanced enthält zusätzlich KI-gestützte Erzeugung von Testskripten, erweiterten API-Zugriff und mehr Speicher. Die Preise pro Jira-Benutzer stehen im Pricing-Tab des Marketplace-Listings.

Fazit

Xray macht aus Jira ein Testmanagement-System, indem es Testfälle, Ausführungen und Ergebnisse als Issues führt und sie über den Link-Typ „Tests“ mit Anforderungen verbindet. Automatisierte Ergebnisse kommen über 8 REST-v2-Endpunkte hinein, abgesichert per API-Key in der Cloud oder per Personal Access Token in Server und Data Center.

Die Arbeit steckt in 3 unspektakulären Details: gepflegte Test Keys im Automationscode, konsequente Verknüpfung zu Stories und ein Pipeline-Schritt, der den Import prüft. Das Tool führt dabei nichts aus. Diese Rolle bleibt beim Automationswerkzeug, und genau dort setzt Autemos an. Welche Kombination zu Ihrer Pipeline und Ihren Nachweispflichten passt, klärt am schnellsten ein Gespräch mit dem Autemos-Team.