Ambren
On 1/23/18 11:22 PM, Ambreen Khan wrote:
> - Our team is just starting the BDD journey and we are writing user
> stories while also discussing feature files using Gherkin format. We are
> confused how much details we should mention in user story about Feature.
> Should we keep feature file separate and link to actual user story?
The user story represents a small amount of functionality that you want
to add to, or modify, in the application. Its value is a a moment in
time, when you are going from not having that functionality to when you do.
The feature file is a description of the application that lasts as long
as the application does. It is the sum of all the changes that user
stories make and unmake. This is the durable documentation of what the
application does. It's reliable documentation because you can run it to
check that the application still does what is described.
> Just to give you a little background, this is kind of my second
> project in BDD. Our first project ended up being BDAT (behaviour driven
> automated testing) as when we started, due to time constraint and other
> issues, the dev team declined to code using BDD. I continued working on
> it and completed my automation part using Feature File. (Even BA/BSA's
> didn't contribute in writing feature files and at the end I was the only
> one writing and consuming those feature files). I know, not appropriate
> way to do BDD. During that project I explored about BDD using books like
> BDD in Action, The Cucumber Book & Cucumber Cookbook. Now in our second
> project we want to start by following proper procedure, where all 3
> amigos are participating in feature file writing. But now we are
> confused how much detail we should provide in user story, or we should
> use some plugin that can link our Feature Files from Git To JIRA user
> story and shouldn't write feature files as part of user story itself.
The user story is a reminder to have a conversation. As Marit suggested,
Example Mapping is an excellent way of structuring the conversation. The
feature file documents that conversation. It can be written
collaboratively with the three amigos, and that's a good practice to
help each other get good at it when you're first starting. The feature
file can also be written by any one of the three amigos, based on
available time and ability to write well. If written solo, I suggest
getting the other amigos to review it.
User stories have no value once they've been implemented. They are the
steps you took to get to the present position. If there is a question
next year, you don't want to have to read all the steps to figure out
what the final position was.
My preference is to check the feature files into Git with the code, so
that you see the appropriate version of each no matter what revision you
check out. This will give you all the historical information you might
possibly want.
I suggest writing your user stories on tissue paper. They are ephemeral.
Flush them when they are done.
>
> Can anyone provide me some insight or point me to the resources that can
> help me...
Hope this helps,
-- George
--
----------------------------------------------------------------------
* George Dinwiddie *
http://blog.gdinwiddie.com
Software Development
http://www.idiacomputing.com
Consultant and Coach
http://www.agilemaryland.org
----------------------------------------------------------------------