Behavior-Driven Development with its emblematic “Given-When-Then” scenarios syntax has lately been quite hyped for its possible uses as a boundary object for software functionality assessment.

I definitely agree that Gherkin, or whichever feature definition script you prefer, is a business-readable DSL, and already provides value as such.

However, I disagree that it is writable by non-programmers (as does Martin Fowler).

Does anyone have accounts of scenarios being written by non-programmers, then instrumented by developers?

If there is indeed a consensus on the lack of writability, then would you see a problem with a tool that, instead of starting with the scenarios and instrumenting them, would generate business-readable scenarios from the actual tests?

Behavior-Driven Development with its emblematic “Given-When-Then” scenarios syntax has lately been quite hyped for its possible uses as a boundary object for software functionality assessment.

I definitely agree that Gherkin, or whichever feature definition script you prefer, is a business-readable DSL, and already provides value as such.

However, I disagree that it is writable by non-programmers (as does Martin Fowler).

Does anyone have accounts of scenarios being written by non-programmers, then instrumented by developers?

If there is indeed a consensus on the lack of writability, then would you see a problem with a tool that, instead of starting with the scenarios and instrumenting them, would generate business-readable scenarios from the actual tests?

Update: regarding the “scenario-generator” tool, it would of course not guess business language magically  ;)  But, just like we currently use regexp matchers to create tests in a top-down approach (on the abstraction dimension), we could use string builders to create scenarios in a bottom-up approach.

A “to give an idea only” example:

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Behavior-Driven Development with its emblematic “Given-When-Then” scenarios syntax has lately been quite hyped for its possible uses as a boundary object for software functionality assessment.

I definitely agree that Gherkin, or whichever feature definition script you prefer, is a business-readable DSL, and already provides value as such.

However, I disagree that it is writable by non-programmers (as does Martin Fowler).

Does anyone have accounts of scenarios being written by non-programmers, then instrumented by developers?

If there is indeed a consensus on the lack of writability, then would you see a problem with a solution that, instead of starting with the scenarios and instrumenting them, would generate business-readable scenarios from the actual tests?

Behavior-Driven Development with its emblematic “Given-When-Then” scenarios syntax has lately been quite hyped for its possible uses as a boundary object for software functionality assessment.

I definitely agree that Gherkin, or whichever feature definition script you prefer, is a business-readable DSL, and already provides value as such.

However, I disagree that it is writable by non-programmers (as does Martin Fowler).

Does anyone have accounts of scenarios being written by non-programmers, then instrumented by developers?

If there is indeed a consensus on the lack of writability, then would you see a problem with a tool that, instead of starting with the scenarios and instrumenting them, would generate business-readable scenarios from the actual tests?