2008/11/9 Mauro Talevi <[EMAIL PROTECTED]> > 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).
As a practical point, you can present a subversion repository as a Windows "Internet Share", using Apache and mod_dav. This appears as just a regular share to your users so they can map it as their G: drive or something. Each time they save a document on the share, it creates a new version in the repository. That way they don't even need to know they are using version control unless they want to, and they can get back to any previous version of their scenarios. Another possibility is to keep all the scenario text in a flat file-based wiki (like moin moin) and keep the wiki content itself in the same repository as the code, so you can see the scenarios evolving with the codebase. Liz is doing this on her current project (although it's .NET so she isn't driving jbehave scenarios from the wiki text). Hmm - perhaps that would make a nice plugin - reading the scenario from a URL rather than a text file? 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. Perhaps we should start collecting the different use cases for how BAs, testers and other non-developers might want to interact with the scenario text? > 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 agree. You can open and edit a text file in Word if you want to (and you might want to because of things like the spelling checker, and the simple fact that it's a familiar environment). > 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). I would go the other way, and edit plain text or html files using Word, which can happily save as either. 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. Exactly. I think it would be a useful exercise to describe the different use cases you can envisage. Cheers, Dan
