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 “stupid” questions. 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:
- 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.
So on to my suggestions. How do I Manage BDD features in my project (using Team Foundation Server (TFS)).
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:
- “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?”
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. 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.
target=”_blank”>BDD</a> or Specification by example
A 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 close. What 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! There are 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.
So that leads us to the features. What are those? What do they represent? And who writes them? A 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] I want [Y] so that [Z]
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: