Integrationen: Jira, Xray, Azure DevOps, Slack und Telegram

Nexus Studio verbindet sich mit fünf Diensten: Jira Cloud, Xray Cloud, Azure DevOps, Slack und Telegram. Jeder ist deaktiviert, bis Sie ihn einschalten, und jeder wird direkt von Ihrem Rechner aus erreicht, niemals über unsere Server. Diese Seite erklärt, was jeder Dienst tut, welche Schlüssel er liest und was er niemals tut.

Vom Nexus Studio-Team, Verdict System LLC. 9. Oktober 2026.

Wie jede Integration funktioniert

• Deaktiviert, bis Sie sie einschalten. Jeder Dienst verfügt über einen eigenen Schalter: JIRA_ENABLED, XRAY_ENABLED, AZURE_BOARDS_ENABLED, SLACK_ENABLED und TELEGRAM_ENABLED. Jeder steht standardmäßig auf false.
• Direkt von Ihrem Computer. Die Engine ruft die jeweilige API des Dienstes direkt von dem Rechner auf, der die Tests ausführt. Nichts läuft über unsere Server, und wir sehen Ihre Vorgänge, Benachrichtigungen oder Ergebnisse zu keinem Zeitpunkt.
• Schlüssel verbleiben im Workspace. Token und Schlüssel sind Zeilen in der .env-Datei des Workspaces auf Ihrer Festplatte. Die Einstellungen unter Integrations bearbeiten diese und zeigen jeden Token, Schlüssel und Webhook zensiert an.
• Sandbox-Durchläufe bleiben außen vor. Ein Sandbox-Durchlauf ist ein Test im Aufbau, kein Befund: Er erstellt, kommentiert oder schließt niemals einen Vorgang.

Ein Vorgang pro Test, solange er fehlschlägt

Jira und Azure Boards folgen demselben Lebenszyklus. Das Issue gehört zum Test, nicht zum Durchlauf. Ein Test, der jede Nacht fehlschlägt, ist also ein einzelnes Issue mit einer Historie, nicht jede Nacht ein neues Issue.

1. Der erste Fehler öffnet ein Issue. Ein Durchlauf, der mit BREACHED, BREACHED_FLAKY, CHAOS_BREACHED oder TIMEOUT endet, öffnet ein Issue für diesen Test – mit angehängtem Fehler und Screenshot des Fehlers.
2. Ein wiederholter Fehler kommentiert es. Solange dieses Issue geöffnet ist, fügt der nächste Fehler einen Kommentar hinzu, an den der neue Screenshot angehängt wird. Zwei Browser, die gleichzeitig fehlschlagen, ergänzen dasselbe Issue.
3. Ein erfolgreicher Durchlauf schließt es. Wenn der Test in jedem Browser eines Durchlaufs fehlerfrei besteht, erhält das Issue einen entsprechenden Kommentar und wechselt in seinen Erledigt-Status. Wenn der Workflow keinen solchen Übergang oder Status aufweist, erhält es nur den Kommentar.
4. Ein darauf folgender Fehler öffnet ein neues Issue. Dasselbe gilt für einen Fehler, dessen Issue gelöscht oder verschoben wurde.

Anhänge: standardmäßig nur der Screenshot. Der Playwright-Trace und das Ausführungsprotokoll werden nur dann ebenfalls angehängt, wenn Sie dies per Opt-in über NEXUS_ISSUE_ATTACH_TRACE=true in den Einstellungen aktivieren, da sie Sitzungsdaten enthalten können: Cookies, Autorisierungs-Header und eingegebene Passwörter. Jede Datei wird bis zu einer Größe von 10 MB angehängt.

FLAKY erstellt niemals einen Eintrag: Ein Durchlauf, der fehlschlug und dann bei einem Wiederholungsversuch erfolgreich war, ist kein Bug. Dasselbe gilt für BLOCKED, UNREACHABLE, CRASHED oder einen Konfigurationsfehler, die die Umgebung betreffen und nicht Ihre Anwendung (wie Urteile gefällt werden). Welches Issue zu welchem Test gehört, wird in evidence/integrations/issue-map.json im Workspace festgehalten.

Jira Cloud

• Verbinden: Ihre Atlassian-Konto-E-Mail und ein API-Token, erstellt unter id.atlassian.com. Fügen Sie in den Einstellungen unter Integrationen einen beliebigen Link von Ihrer Jira-Website ein: Das Studio übernimmt die Website und den Projektschlüssel. Die Website-Adresse, JIRA_BASE_URL, muss https sein. Verbindung prüfen testet diese und erstellt nichts.
• Issues: ein Bug in JIRA_PROJECT_KEY, der dem oben genannten Lebenszyklus folgt. Bei einem fehlerfreien Durchlauf durchläuft das Issue den in JIRA_DONE_TRANSITION benannten Übergang, standardmäßig Done, unabhängig von der Groß-/Kleinschreibung nach Name abgeglichen.
• Keine Duplikate: Wenn in den letzten 24 Stunden ein Bug mit derselben Zusammenfassung erstellt wurde, wird kein zweiter gemeldet.
• Manuell: Das Evidence Locker kann einen Fehler an Jira senden, wenn Sie dies möchten.

Xray Cloud

Mit XRAY_ENABLED=true importiert jeder nexus ci-Durchlauf sein JUnit-XML als Test Execution in Xray Cloud – in XRAY_PROJECT_KEY oder in JIRA_PROJECT_KEY, wenn dieses leer ist, sowie unter dem Test Plan in XRAY_TEST_PLAN_KEY, sofern Sie einen festgelegt haben.

• Verbinden: ein API-Schlüsselpaar, XRAY_CLIENT_ID und XRAY_CLIENT_SECRET, erstellt in Jira unter Apps, Xray, Globale Einstellungen, API-Schlüssel.
• Was übertragen wird: die JUnit-Datei dieses Durchlaufs und sonst nichts. Eine von einem früheren Durchlauf übrig gebliebene JUnit-Datei wird niemals importiert.
• Lässt den Durchlauf niemals fehlschlagen: Wenn der Import fehlschlägt, gibt das Protokoll des Durchlaufs den Grund in einer einzigen Zeile an, wobei das Secret unkenntlich gemacht wird.

Azure DevOps: Boards, Test Plans und Pipelines

Ein persönliches Zugriffstoken (PAT) und ein Projekt in AZURE_DEVOPS_ORG_URL (https://dev.azure.com/<org> oder https://<org>.visualstudio.com) und AZURE_DEVOPS_PROJECT. Das PAT wird ausschließlich an die eigenen Hosts von Azure DevOps gesendet und erscheint niemals in einer Protokollzeile. In den Einstellungen unter Integrationen überprüft Azure DevOps verbinden das Projekt sowie den Work-Item-Typ und erstellt nichts.

• Azure Boards: Mit AZURE_BOARDS_ENABLED=true öffnet ein Fehlschlag ein Work-Item des Typs AZURE_BOARDS_WORK_ITEM_TYPE, standardmäßig Bug, gemäß dem oben beschriebenen Lebenszyklus. Bei einem erfolgreichen Durchlauf wechselt es in den Status in AZURE_BOARDS_DONE_STATE, standardmäßig Resolved; ein Prozess, der diesen Status verweigert, erhält nur den Kommentar. Das PAT benötigt Work Items (Lesen & Schreiben). Der Evidence Locker kann einen Fehlschlag auch manuell an Azure Boards senden.
• Azure Test Plans: Die von der CI/CD-Ansicht generierte azure-pipelines.yml veröffentlicht das JUnit-XML des Durchlaufs mit der Aufgabe PublishTestResults@2, sodass jeder Pipeline-Durchlauf unter Test Plans, Runs angezeigt wird.
• Azure Pipelines: nexus ci-remote --provider=azure reiht einen Durchlauf der Pipeline in AZURE_PIPELINE_ID in die Warteschlange ein, wartet darauf und überträgt das JUnit-XML zurück auf diesen Rechner. Das PAT benötigt hierfür Build (Lesen & Ausführen).

Slack

• Verbinden: Eine Incoming-Webhook-URL in SLACK_WEBHOOK_URL. In den Einstellungen gibt es die Schaltfläche Testnachricht senden.
• Was empfangen wird: Block-Kit-Nachrichten: die Zusammenfassung des Durchlaufs und mit NEXUS_SLACK_NOTIFY=true eine Nachricht pro fehlschlagendem, instabilem, Chaos- oder visuellem Regressionstest. Eine Nachricht über einen Fehlschlag verlinkt das entsprechende Jira-Ticket, sofern eines existiert.
• Manuell: Der Evidence Locker kann eine Textzusammenfassung eines Fehlschlags in Slack posten. Slack erhält keine Dateien.

Telegram

• Verbinden: Ein eigener Bot, einmalig mit @BotFather erstellt, in TELEGRAM_TOKEN. In den Einstellungen verknüpft Per QR verbinden Ihren Chat und füllt TELEGRAM_CHAT_ID aus. Es gibt keinen geteilten Bot.
• Was empfangen wird: Benachrichtigungen bei Fehlschlägen, eine pro Test mit NEXUS_TELEGRAM_NOTIFY=true, sowie die Berichte und Dateien, die Sie über das Studio teilen möchten.
• Bevor Sie es aktivieren: Telegram kann Dateien wie Berichte und PDFs empfangen, und diese werden an die Server von Telegram übertragen. In einer regulierten Umgebung sollten Sie sich zunächst an Ihr Compliance-Team wenden.

Die Schlüssel

Jeder Schlüssel ist eine Zeile in der .env des Workspace. Über die Einstellungen können alle bearbeitet werden.

In einer Pipeline sind dieselben Schlüssel – alle außer AZURE_PIPELINE_ID – die geheimen Variablen der Pipeline, und ein Schlüssel, den Sie nicht setzen, belässt den zugehörigen Dienst deaktiviert (Secrets in CI/CD).

Fragen

Sieht Nexus Studio meine Jira- oder Azure DevOps-Daten?

Nein. Die Engine kommuniziert mit Jira, Xray, Azure DevOps, Slack und Telegram direkt von Ihrem Rechner aus und mit Ihren Schlüsseln. Nichts davon durchläuft unsere Server.

Eröffnet ein unzuverlässiger (flaky) Test ein Ticket?

Nein. FLAKY erstellt nichts. BREACHED_FLAKY schon: Der Fehler selbst war inkonsistent, und ein erneuter Versuch verbirgt ihn nicht.

Ein Test ist diese Woche 30 Mal fehlgeschlagen. Wie viele Issues sind das?

Eines, mit einem Kommentar und einem neuen Screenshot für jeden Fehler nach dem ersten, bis der Test in jedem Browser fehlerfrei durchläuft.

Kann ich Jira und Azure Boards gleichzeitig verwenden?

Ja. Jedes System führt sein eigenes Issue pro Test.