Let me be honest: this is a story everyone knows who builds software for others. A client invites you. You listen. You go home, think, show a way to a solution, with an example, with open questions, honestly. Not the solution, the way there. And not too detailed, we have to remind each other of that in the team, because we are makers and we do this with heart. Whoever lets us quickly gets more than they ordered. You send it. And then you hear nothing.
Then it goes quiet
No no. No "we decided otherwise". Just nothing. You follow up once, twice, and then you let it go, because you do not want to be the one who nags.
It took me a long time not to take that personally. The world turns, and at clients it turns in ways you do not always understand from outside. A budget gets moved. A project lead changes. A department is restructured. Another vendor was already in the house. Or it was simply the wrong moment. You never learn any of that, and that is fine. You delivered what you promised: thinking. Not the finished solution, the way. More would have been wrong anyway.
The task
A large organisation, public sector, many applications, many rules. Existing processes that have run this way for years. Jira is there, Xray for the test cases is there, OpenShift is there. And the wish: a pipeline in which a requirement automatically becomes a test, the test automatically becomes a quality gate, and the gate automatically becomes a deployment. Not everything at once. One function first, as a proof of concept, then the next ones.
That is a good task. Clearly bounded, with real benefit, and with a problem I see in almost every house: requirements live in Jira, test cases live in Xray, tests live in code. Three places, three truths, and after a year none of them agrees with the others anymore.
One feature file, one truth
The core of the approach is a single thought: the requirement is written as a feature file, in Gherkin, Given, When, Then. This one file is everything at once.
It is the requirement. The business side can read it without understanding code. "Given the applicant meets the condition, When they submit the application, Then the status is set to SUBMITTED." That is a sentence a case worker can sign off.
It is the Xray test case. Xray can generate and update test cases directly from feature files, as type Cucumber. Nobody types the test case a second time into Jira. The coupling runs via the ID.
It is the automated test. Cucumber executes it, with step definitions behind it, against the REST interface or the UI, with Playwright or REST Assured. The result comes as JSON.
It is the quality gate. Test passed means deploy allowed. The result goes back to Xray via API, as a test run with a status per step. And Helm rolls out to OpenShift, dev, QA, prod, versioned, with rollback.
Fact is: test cases then do not have to be maintained twice, in code and in Jira. That sounds like a small thing. It is the reason why in most houses the test cases in Xray are no longer correct after a year. Not because someone was lazy. Because two places always drift apart.
Domain driven design, because the business side has to have a say
The second part of the approach was to build the function not as a "form with fields" but as a bounded business process. Domain driven design, in small. A bounded context for the application process. An aggregate, the application, with its states: submitted, under review, approved, rejected. A command that submits the application. An event that says it was submitted.
Why that matters: because the feature file then speaks exactly the language of the business side. The event is named the way the case worker would name it. The state is named the way it appears on the screen. And if an organisation with many locations has specialities, everyone does it a bit differently, then the question whether you model that as separate subdomains or standardise is a strategic one. We asked it. It is in the list below.
The pipeline, stage by stage
Requirement in Jira. Epic, story, acceptance criteria. The story gets an ID, and the feature file carries that ID.
Feature file in Git. Versioned, reviewed like code, because it is code. Whoever changes it changes the requirement, and you see that in the diff.
Pipeline executes. Build, then Cucumber against the service, result as JSON. No manual step.
Import to Xray. One call, format Cucumber, project, file. Xray creates the test run, links it to the test case that came from the same file, and to the story.
Gate and deployment. Green means Helm release to the next stage. Red means stop, and the test run in Xray says which step.
Monitoring. Prometheus and Grafana, incoming applications, error rates, stability. That was marked as a question: is this even wanted? Not everyone wants a dashboard at the start.
Whoever has read the article on test data without data sees where this fits together. There NeoCoder produces an Xray test case in words from a finding. Here the Xray test case comes from the feature file. Both land in the same place, both need no manual work, and both need someone who knows the whole system. That is no coincidence. That is the same thought from two sides.
The questions we ask beforehand
The largest part of the document was not the solution. It was questions. Before I build a pipeline, I want to know what it stands on. Not as a questionnaire to fill in, but as a list for a second conversation. An excerpt, as it was in there.
Technology. Which Git platform, which CI system, where do the artifacts live, who runs OpenShift, are there Helm charts already or do we build them.
Test strategy. Is Jira used in a structured way, with acceptance criteria, definition of done, definition of ready? Are there test plans in Xray already? Does the team know Gherkin? Which test frameworks run today? Is there dev, staging, prod?
Organisation. Who is responsible for requirements, tests, QA, DevOps? Is there a release process with quality gates, for example 85 percent of tests must be green? Which data protection rules apply? And how are requirements aligned between stakeholders, now and later, when it scales?
These questions are the real value. Anyone who knows Cucumber and Helm can build the pipeline. The questions tell you whether it will survive in the house. Whoever cannot answer them is not ready yet, and that is no disgrace, that is information.
What I would write differently today
The data question up front. In the document "which data protection rules apply" was one of twenty points. Today it would be the first. Because at an organisation with real applications the test data is the problem, not the pipeline. See yesterday's article.
Separate functional and end-to-end from the start. A feature file for one application is functional. One for "application to payout" is end-to-end and needs different test data, different environments, different people. I should have named that.
Fewer tools in the first sentence. Jira, Xray, Cucumber, Playwright, REST Assured, Helm, OpenShift, Prometheus, Grafana. All correct, all too much for a first document. Today I would write: one feature file, one test run, one gate. The rest in conversation.
And follow up differently. Not "have you read the document" but "what has changed on your side". Sometimes an answer comes after all. Sometimes not. Both are fine.
What stays
The document has been in my files since April 2025. A few pages, an example, a list of questions. It harmed nobody that it sat there. But it helped nobody either. Now it is here, without client, without data, without names. Whoever wants to build a pipeline from requirement to deployment, in a house with Jira and Xray, can start with it. Whoever has questions writes to me. And whoever invites me and then goes quiet: also fine. I will just write it down here.
Being invited, showing a way to a solution, hearing nothing. That is part of it, and you do not always understand the reasons. But a good approach does not belong in a drawer. One feature file as the single truth, from requirement via the Xray test case to deployment, plus the questions you have to ask beforehand. That is the approach. Take it.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by our own twin model, trained on my texts. Sometimes a stumble stays in. That is mine too.