Jetzt mal ganz ehrlich: Das hier ist eine Geschichte, die jeder kennt, der Software für andere baut. Ein Kunde lädt dich ein. Du hörst zu. Du gehst nach Hause, denkst nach, zeigst einen Lösungsweg auf, mit Beispiel, mit offenen Fragen, ehrlich. Nicht die Lösung, den Weg dorthin. Und nicht zu detailliert, daran müssen wir uns im Team gegenseitig erinnern, weil wir Macher sind und das mit Herzblut machen. Wer uns lässt, bekommt schnell mehr, als er bestellt hat. Du schickst es. Und dann hörst du nichts mehr.
Dann wird es still
Kein Nein. Kein „wir haben uns anders entschieden". Einfach nichts. Man fragt einmal nach, zweimal, und dann lässt man es, weil man nicht der sein will, der nervt.
Ich habe lange gebraucht, um das nicht persönlich zu nehmen. Die Welt dreht sich, bei Kunden dreht sie sich auf eine Art, die man von aussen nicht immer versteht. Ein Budget wird verschoben. Ein Projektleiter wechselt. Eine Abteilung wird umgebaut. Ein anderer Anbieter war schon im Haus. Oder es war einfach der falsche Moment. Das alles erfährt man nicht, und das ist in Ordnung. Man hat geliefert, was man versprochen hat: Denken. Nicht die fertige Lösung, den Weg. Mehr wäre auch falsch gewesen.
Die Aufgabe
Ein grosser Betrieb, öffentlich, viele Anträge, viele Regeln. Bestehende Prozesse, die seit Jahren so laufen. Jira ist da, Xray für die Testfälle ist da, OpenShift ist da. Und der Wunsch: eine Pipeline, in der eine Anforderung automatisch zum Test wird, der Test automatisch zum Quality Gate, und das Gate automatisch zum Deployment. Nicht alles auf einmal. Eine Funktionalität zuerst, als Proof of Concept, dann die nächsten.
Das ist eine gute Aufgabe. Klar abgegrenzt, mit echtem Nutzen, und mit einem Problem, das ich in fast jedem Haus sehe: Anforderungen stehen in Jira, Testfälle stehen in Xray, Tests stehen im Code. Drei Orte, drei Wahrheiten, und nach einem Jahr stimmt keine mehr mit der anderen überein.
Eine Feature-Datei, eine Wahrheit
Der Kern des Ansatzes ist ein einziger Gedanke: Die Anforderung wird als Feature-Datei geschrieben, in Gherkin, Given, When, Then. Diese eine Datei ist alles zugleich.
Sie ist die Anforderung. Die Fachseite kann sie lesen, ohne Code zu verstehen. „Given der Antragsteller erfüllt die Voraussetzung, When er reicht den Antrag ein, Then wird der Status auf EINGEREICHT gesetzt." Das ist ein Satz, den ein Sachbearbeiter abnicken kann.
Sie ist der Xray-Testfall. Xray kann Testfälle direkt aus Feature-Dateien erzeugen und aktualisieren, als Typ Cucumber. Niemand tippt den Testfall ein zweites Mal in Jira. Die Kopplung läuft über die ID.
Sie ist der automatisierte Test. Cucumber führt sie aus, mit Step Definitions dahinter, gegen die REST-Schnittstelle oder die Oberfläche, mit Playwright oder REST Assured. Das Ergebnis kommt als JSON.
Sie ist das Quality Gate. Test bestanden heisst Deploy erlaubt. Das Ergebnis geht per API zurück an Xray, als Testlauf mit Status pro Schritt. Und Helm rollt auf OpenShift aus, Dev, QA, Prod, versioniert, mit Rollback.
Fakt ist: Testfälle müssen dann nicht doppelt gepflegt werden, im Code und in Jira. Das klingt nach einer Kleinigkeit. Es ist der Grund, warum in den meisten Häusern die Testfälle in Xray nach einem Jahr nicht mehr stimmen. Nicht, weil jemand faul war. Weil zwei Orte immer auseinanderlaufen.
Domain Driven Design, weil die Fachseite mitreden muss
Der zweite Teil des Ansatzes war, die Funktionalität nicht als „Formular mit Feldern" zu bauen, sondern als abgegrenzten fachlichen Prozess. Domain Driven Design, in klein. Ein Bounded Context für den Antragsprozess. Ein Aggregate, der Antrag, mit seinen Zuständen: eingereicht, in Prüfung, genehmigt, abgelehnt. Ein Command, der den Antrag einreicht. Ein Event, das sagt, dass er eingereicht wurde.
Warum das wichtig ist: Weil die Feature-Datei dann genau die Sprache der Fachseite spricht. Das Event heisst so, wie der Sachbearbeiter es nennen würde. Der Zustand heisst so, wie er auf dem Bildschirm steht. Und wenn es bei einem Betrieb mit vielen Standorten Spezialitäten gibt, jeder macht es ein bisschen anders, dann ist die Frage, ob man das als eigene Subdomains abbildet oder standardisiert, eine strategische Frage. Die haben wir gestellt. Sie steht unten in der Liste.
Die Pipeline, Stufe für Stufe
Anforderung in Jira. Epic, Story, Akzeptanzkriterien. Die Story bekommt eine ID, und die Feature-Datei trägt diese ID.
Feature-Datei im Git. Versioniert, reviewt wie Code, weil sie Code ist. Wer sie ändert, ändert die Anforderung, und das sieht man im Diff.
Pipeline führt aus. Build, dann Cucumber gegen den Service, Ergebnis als JSON. Kein manueller Schritt.
Import nach Xray. Ein Aufruf, Format Cucumber, Projekt, Datei. Xray legt den Testlauf an, verknüpft ihn mit dem Testfall, der aus derselben Datei entstanden ist, und mit der Story.
Gate und Deployment. Grün heisst Helm-Release auf die nächste Stage. Rot heisst Stopp, und der Testlauf in Xray sagt, welcher Schritt.
Monitoring. Prometheus und Grafana, Antragseingänge, Fehlerquoten, Stabilität. Das war als Frage markiert: Ist das überhaupt gewünscht? Nicht jeder will am Anfang ein Dashboard.
Wer den Artikel über Testdaten ohne Daten gelesen hat, sieht, wo das zusammenpasst. Dort erzeugt NeoCoder aus einem Befund einen Xray-Testfall in Worten. Hier entsteht der Xray-Testfall aus der Feature-Datei. Beides landet am selben Ort, beides ist ohne Handarbeit, und beides braucht jemanden, der das ganze System kennt. Das ist kein Zufall. Das ist derselbe Gedanke von zwei Seiten.
Die Fragen, die wir vorher stellen
Der grösste Teil des Dokuments war nicht die Lösung. Es waren Fragen. Bevor ich eine Pipeline baue, will ich wissen, worauf sie steht. Nicht als Fragebogen zum Ausfüllen, sondern als Liste für ein zweites Gespräch. Ein Auszug, so wie er drinstand.
Technik. Welche Git-Plattform, welches CI-System, wo liegen die Artefakte, wer betreibt OpenShift, gibt es schon Helm-Charts oder bauen wir sie.
Teststrategie. Ist Jira strukturiert im Einsatz, mit Akzeptanzkriterien, Definition of Done, Definition of Ready? Gibt es in Xray schon Testpläne? Kennt das Team Gherkin? Welche Testframeworks laufen heute? Gibt es Dev, Staging, Prod?
Organisation. Wer ist zuständig für Anforderungen, Tests, QA, DevOps? Gibt es einen Releaseprozess mit Quality Gates, zum Beispiel 85 Prozent der Tests müssen grün sein? Welche Datenschutzvorgaben gelten? Und wie werden Anforderungen zwischen den Stakeholdern abgestimmt, jetzt und später, wenn es skaliert?
Diese Fragen sind der eigentliche Wert. Die Pipeline kann jeder bauen, der Cucumber und Helm kennt. Die Fragen sagen, ob sie im Haus überleben wird. Wer sie nicht beantworten kann, ist noch nicht bereit, und das ist keine Schande, das ist eine Information.
Was ich heute anders schreiben würde
Die Datenfrage nach vorne. Im Dokument stand „Welche Datenschutzvorgaben sind zu beachten" als einer von zwanzig Punkten. Heute wäre es der erste. Weil bei einem Betrieb mit echten Anträgen die Testdaten das Problem sind, nicht die Pipeline. Dazu der Artikel von gestern.
Funktional und End-to-End trennen, von Anfang an. Eine Feature-Datei für einen Antrag ist funktional. Eine für „Antrag bis Auszahlung" ist End-to-End und braucht andere Testdaten, andere Umgebungen, andere Leute. Das hätte ich benennen sollen.
Weniger Werkzeuge im ersten Satz. Jira, Xray, Cucumber, Playwright, REST Assured, Helm, OpenShift, Prometheus, Grafana. Alles richtig, alles zu viel für ein erstes Dokument. Heute würde ich schreiben: eine Feature-Datei, ein Testlauf, ein Gate. Den Rest im Gespräch.
Und nachfragen, anders. Nicht „habt ihr das Dokument gelesen", sondern „was hat sich bei euch verändert". Manchmal kommt dann doch eine Antwort. Manchmal nicht. Beides ist in Ordnung.
Was bleibt
Das Dokument liegt seit April 2025 in meiner Ablage. Ein paar Seiten, ein Beispiel, eine Liste mit Fragen. Es hat niemandem geschadet, dass es dort lag. Aber es hat auch niemandem genützt. Jetzt liegt es hier, ohne Kunde, ohne Daten, ohne Namen. Wer eine Pipeline von der Anforderung bis zum Deployment bauen will, in einem Haus mit Jira und Xray, kann damit anfangen. Wer Fragen hat, schreibt mir. Und wer mich einlädt und dann still wird: auch in Ordnung. Ich schreibe es dann eben hier auf.
Eingeladen werden, einen Lösungsweg aufzeigen, nichts mehr hören. Das gehört dazu, und man versteht die Gründe nicht immer. Aber ein guter Ansatz gehört nicht in die Schublade. Eine Feature-Datei als einzige Wahrheit, von der Anforderung über den Xray-Testfall bis zum Deployment, plus die Fragen, die man vorher stellen muss. Das ist der Ansatz. Nehmt ihn.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.