Egil Østhus wrote:
This is exactly what I want to highlight. Starting with JBehave, I found
that the tools set made available, was pretty much developer centric.
First of all, in my case the BAs does not have access to SVN. (Not sure
if this is something one could argue is something they should have).
From my (as a developer as well as JBehave's) prespective it makes
totally sense to have the .scenarios file in SVN. What I would like to
see, is a GUI front end to the .scenarios as well, that is synchronized
with SVN, that makes them available to the BA without having to deal
with scripts to be ran, or similar. I think my reason for bringing
attention to this, is that this is what I see as the hardest part to
"sell" to the BA when suggesting to go more BDD. What I have seen so
far, this is the weakest part of the BDD/JBehave "story".
Not really sure what you have in mind by "GUI front-end to the
scenarios". If the BAs don't have access to source control, what is the
GUI going to interface to?
Personally, I would consider the reasons why BAs don't have access to
SVN. In an agile team, all members should have access to the source.
And you have plenty of GUI tools for SVN, especially on Windows (which
I'm assuming is your OS, based on the tools you mentions below).
Alternatively, having a script that checks out or exports scenarios into
a common filesystem area is a way of exposing them to people that don't
have access to source control. But is a simple sysadmin task, and one
that can hardly be generalized.
Else, BAs could write their scenarios as story cards using whatever
system you're using to track them. Even something as simple as a wiki
would do. Again, it's up to your team to decide what works best for
your development environment. JBehave keeps the requirements very simple.
What I see is that BA's most often uses tools like powerpoint, excel and
similar in their everyday worklife. Some has background using a
commandline interface, but most have not. I'm not sure that "forcing
developer centric" tools upon them is really the easiest way to gain
acceptance for BDD and tools like JBehave.
The simple text file format has been chosen because it is universally
usable - any editing tool would be able to open it.
I have been thinking about supporting imports from other binary formats,
into a textual format - which is the only one suited for source control
(created issue to track it http://jira.codehaus.org/browse/JBEHAVE-149).
But in the end it still means opening a file and writing the scenarios
using plain language words. If they can do it in Excel, the can surely
do it WordPad. While I can understand the reluctance of non-developers
to have to edit Java code files - or even HTML files - I can understand
less the objections to writing a simple text file.
Totally agree on you on this. My intention was never to say that the
BA's should never "see" the .scneario files (nor that they are not smart
people, those I've met are very, very clever and smart persons). I'm
sorry that my reasoning was interpreted this way, it was not what I
tried to say. Again, as mentioned above, my conern is more on _how_ the
BAs are getting access to the .scenario files. From what you are saying,
there is no single way to the goal here, which means that the developers
needs to spend some time to get this process in place.
Yes - because each development and business environment differs from
another. If you can highlight a usecase that can be generalised, we'll
be happy to take into consideration.
Cheers
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email