From time to time I find myself in the position where I ask “stupid” questions. I’ve found that it’s often the case that
the question is not that “stupid” after all and if it is you get to learn a lot in the process. I have never been
verbally abused, flamed or laughed at for my questions – which often are the reasons that people don’t want to ask to
So recently I’ve been asking “stupid” (final time I use that word in this post, promise)
questions surrounding the management of features (.feature-files for us Cucumber freaks). And at the same time I've
searching high and low on the net for best practices on how to managing your features through the course of a project.
I didn't find much due a couple of reason:
So on to my suggestions. How do I Manage BDD features in my project (using Team Foundation Server (TFS)).
- the Ruby/ cucumber inheritance of .net tools such as SpecFlow is great - you can learn a lot(!!) from that
community. But there is not much written on BDD project management in .net. Also the whole Ruby environment is very
different than the typical .net setup. This allows for other kind of solutions.
- I was asking the wrong question. My initial thoughts were centered on how to get the business side responsible for
the features and the writing of them. Wrong! More on that below.
- there might not yet be a best practice surrounding this for .net projects using TFS. We're still catching up with
the BDD community in general.
Managing What it the deal with this? As I introduce the concept of Specification by example to business people they always
ask me about these things:
I personally might not put so much emphasizes on this but it might be important to big organizations to have this
unbroken chain of traceability in an electronic system such as TFS.
- “How do we link this to our current project templates”
- “What about traceability in our electronic tracking system”
- “I want to follow the whole chain from vision to maintenance and bug reporting in TFS. How can your BDD-features
hook into that?”
But I think this was what lead me of the agile,
collaborative track for a while. I don’t think it’s impossible to achieve but I think it might not be the tracking
system that is the master of the feature-data. More on that below.
BDD or Specification by
exampleA phrase I’ve heard a lot when reading about specification by example is “It’s not in the tool”. That
tells us that the or a tool is not the solution. But what is then – Collaboration is the solution. It’s no silver bullet – but it comes close, very
this means is that the real benefit from using the agile methodology of BDD is that you meet all the people involved in
realizing a feature and write down how you expect the feature to work. In a language that all of you understand. Using
examples that later can be used to test that the application behaves as expected.
That’s the thing!
tools that help you to drive that process and run your scenarios but that’s not nearly as important as the fact that you
meet and write the scenarios down, together.
FeaturesSo that leads us to the features. What are those? What do they represent? And who writes them?
feature is a behavior in the system that some person (or role) benefits from (see Introducing BDD by Dan North). Often they written
in the form of user stories since that practice
and form capture the three elements in a very concise format:
As a [X]Who
writes the stories then? It’s easy to think that this a business / requirement thing. But as a great answer
to my question, great authoritative resources and even links off old
post of mine shows that misses the point of BDD. You want to write the features and their scenarios together as I
wrote above. A bit like this maybe:
I want [Y]
so that [Z]
(Short side note – I actually was on to that track in an earlier post also, which I hope lessen the
stupidity of my question and reasoning a bit ).
In the picture above we see that the roles needed to grasp the story meet, bringing all the documentation of the
work they have done up to now and record their common understanding of the problem in a feature with scenarios. They
write the feature together.
In the answer to my
question on the BDD list another view was also suggested:
“Cucumber features are an executable map of the currentI like this idea a lot! (Thanks Andrew
Premdas). In a way this means that the content of the .feature files are like source code that can be run to see
how well the system fulfills the current requirements.
functionality of the system”
of running cucumber features is something you can keep. You can
say at this time that system was like this.”
So in short – you meet and write the features down
together. Probably this can be sketched out during the meeting and nailed by somebody later (to better match existing
steps or to keep the language consistent for example).
The feature is then checked in with the source code as it
can be executed to produce a map between our common understanding of the requirements and how well the system fulfills
Associate with work item in TFSNow we can see how to associate the feature we write together with a work item
in TFS. The link between the two can be achieved two-way like this:
- in the .feature file you can tag the feature or scenario with the work item id, @TFS_432453 for example. That can be used
to search for the item among your scenarios and to control which items that are run again see this post).
- you can also use a comment with a link to the work item on the TFS Server. For example this link (http://tfs:8080/tfs/WorkItemTracking/Workitem.aspx?artifactMoniker=68717)
will take me to the WI 68717 on the TFS web site.
when the .feature file is created, associate it with the work
item of choice (for example a work item with some relevant documentation attached to it) just like you do with any
other check in.
Suggested workflowAn example on who this can be worked into a workflow of an feature would be this:
- When the item is about to be developed, gather the required people and skills that you need to formulate the
scenarios of the item. This would typically be the sprint planning meeting or an analyze step on a Kanban board
- Sketch down the feature and a couple of scenarios. There’s a lot to be said about this (see http://www.cuke4ninja.com/ for some good
advices and directions) but all the roles need to have their say and input in how to formulate the scenarios. So
- Requirements get all the important business rules and effects into the story
- Developers might think of edge cases and some special cases
- Testers get the coverage and spread of test data that is needed
- Maintenance get their say on how the function behaves etc.
- Get one person to write down the story in a .feature-file, do the check in and associate the .feature with the
required work items.
- As work is commenced the different steps will give the developers a possibility to work outside-in and complete
the feature step-by-step.
- When new knowledge arises (as it always does) that can easily be incorporated into the feature by updating and
changing the scenarios. Of course after communicating within the team.
- Likewise when testing is done new scenarios and new data might be added to further enhance the story. The use of
tags can be used
here to differentiate between the different test and when to run them
ConclusionI am sure that I will find some better way to do this as we go along but this is the way we do it now
and it works quite nice and also fulfills the need of connecting the agile workflow of specification by example with