Feature management and Electronic tracking systems

[Marcus Hammarberg]

Hello,

I'm not quite sure if this is the place to direct this question but it sure brushes on the subject on BDD.

In my opinion the greatest use and benefit of using BDD is the communication within the team. For example using Cucumber-based frameworks you can write executable specifications in a langauge that the business people can not only read and understand, but maybe even write.

However where I have introduce these concepts I often run into questions surrounding traceability or connections to the current tracking system. My customer uses Team Foundation Server (TFS) and the first questions they asked was how to connect the executable specifications to work item within TFS. "How can we keep track of the work item flow through all it's phases; from vision, requirements, development, testing, bug reporting, maintenance etc".

So now finally to my question, does any body have / know of / has ideas on best practices for feature management in electronic tracking systems (such as TFS or JIRA).

Is the best thing to write the specification in .feature (FIT-table, Java-code or whatever) and link that to a work item?
Or would I be better of by generating the .feature-file from the text in the WI, since many tools works best when you to write the features in an IDE (such as SpecFlow and Visual Studio for example).

Or should I simply let the writing of the .features be a part of a developers work, to finish a story. I.e. you discuss the item and document it in the electronic tracking system and then create the .features separately from that? I don't like this since it violates the nice DRY-ness of having a single document (the .feature-file) for specification, test, regression test and development spec.

Please correct my mis-thinking in this and point me to a brilliant solution.

Marcus Hammarberg
@marcusoftnet
marcus...@gmail.com
www.marcusoft.net

[Robert Mischke]

You could try to extend your automated test execution framework in a way, that the output contains a link to the work item. The other way round, you could transform you work item spec automatically to source code, like storyQ (http://storyq.codeplex.com/.)  Fitness is probably the most integrated solution. Hopefully there will happen a lot, in that tool market. 

May be http://www.greenpeppersoftware.com/confluence/display/GPW/Home/ would be another alternative. But I don't have any experience with it. At least the pricing is reasonable :-) (With urban turtle integration, there is TFS integration: http://urbanturtle.com/)

2010/12/16 Marcus Hammarberg <marcusoft.net@gmail.com>

marcusoft.net@gmail.com
www.marcusoft.net

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To post to this group, send email to behaviordriv...@googlegroups.com.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.

[Morgan Persson]

Does the workitem keep the same id through alll phases in TFS? If yes then a simple solution would be to put a tag on the cucumber scenario with the TFS track id.

/Morgan

[Marcus Hammarberg]

Yes - i like that and its probably the way I'll go but: 

- the business people still have to open the cucumber scenario (.feature, c#,  FIT wiki or what have you). Or you could *shrudder* duplicate the content of the file in the WI

- that link is only text... A simple mistype and your connection is lost?

I was thinking of linking the WI with the feature file, as you do with code files for example. That still leaves problem one above though.  

 

/Marcus Hammarberg

www.marcusoft.net 

Skickat från Marcus iPhone

[Andrew Premdas]

This issue based upon a flawed understanding (IMO) of what the cucumber features are. Cucumber features are an executable map of the current functionality of the system. The map describes how the system currently works. The green bits indicate the system works in the way described, the red bits indicate the system doesn't work. There is no easy relationship between this map, and user stories or work items, they operate in different time frames. If you do try and tie features directly to stories or work items, so you can monitor your costs, then you end up destroying the map.

The output of running cucumber features is something you can keep. You can say at this time that system was like this. Comparing maps over time is possible. Using these comparisons, with work monitoring and ticketing systems is possible and should be feasible e.g. between Mar and April we did these tickets at this cost, and the system changed from A to B.

A feature cannot be managed in JIRA. The best you can do with putting them in a ticket is to provide a starting point for development. After that you can't track the feature, you can only track the ticket and the work done on it. When the work is ready for review you can use the ticket and the original feature to guide you, but you won't be able to map this to a current feature. However this does not matter, when you are reviewing you should not be looking at features you should be looking at the application. The feature being green is no proof that the work is done, or to standard

All best

Andrew

[Marcus Hammarberg]

Hi Andew and others! 

I'm think I'm begin to understand how to use and what a feature (in Cucumber)really is. 

You're reasoning harmonize well  with this (http://cuke4ninja.com/sec_collaborative_feature_files.html) from Cuke4Ninja

Thank you 

/Marcus Hammarberg

www.marcusoft.net 

Skickat från Marcus iPhone