Ha this reminds me of the craze for BDD/Cucumber type testing. Don’t think I ever once saw a product owner take interest in a human readable test case haha
They had some previous negative experiences with uncertainty about what "was working" in releases, and a pretty slapdash process before I came on board, so it was an important trust building tool.
This is so often completely missed in these conversations about these tools.
Great point.
https://github.com/hitchdev/hitchstory/blob/master/examples/...
Gherkin isnt really a suitable language for writing test cases in though - it's verbose, lacks inheritance, has clunky syntax, is stringly typed and the parser demands you write regexes to parse it.
https://en.wikipedia.org/wiki/Attempto_Controlled_English?wp...
But you’re right, many of them are wizards in <whatever query language our tool uses>. Like VizQL for Tableau.
On the other hand, sql is also dangerous in that it gives you a result, even if the aggregation is completely wrong! Forgetting empty groups in a group by, loosing rows in a join or ignoring null values is common to see. Many cases of non techies “knowing” sql often turn out to be some basic query that give seemingly good data out but actually is complete nonsense when put under deeper review, a bit like AI hallucinations.
So, in the end, we abandoned that project and years later just rewrote the system so we could write claim rules in EDN format (from the Clojure world) to make our own lives easier.
In theory, the business users could also learn how to write in this EDN format, but it wasn't something the stakeholders outside of engineering even wanted. On the one hand, their expertise was in insurance claims---they didn't want to write code. More importantly, they felt they would be held accountable for any mistakes in the rules that could well result in thousands and thousands of dollars in overpayments.