+972 52-548-6969
My BDD experiment
I am trying to get BDD. As such, I started with building a list of specifications. Here is what I have so far. Now you get the chance to tell me why I am wrong...
As a user
I want to be able to see the latest webcast summary on the homepage
So that I have great visibility on what is new
-------------------
Acceptance criteria:
- Can see the name of the latest webcast
- Can see the date it was published
- Can read the short description
===============================================================
As a user
I want to be able to see the details of a webcast
So that I can see more details about the webcast
-------------------
Acceptance criteria:
- Can see the name of the latest webcast
- Can read the short description
- Can view number of downloads
- Can view relevant files
===============================================================
As a user
I want to be able to browse the archives of the site
So I can see old shows
-------------------
Acceptance criteria:
- Can see the names of all published webcasts
- Can click to the details of each webcast
- Can view number of downloads
- Can sort the list
===============================================================
As a user
I want to be able to subscribe to an RSS feed of the webcasts
So that I wouldn't have to check the site all the time
-------------------
Acceptance criteria:
- Each page on the site should have RSS link for news
- Publishing a new webcast would appear on the RSS
===============================================================
As an administor
I want to be able to add a new webcast
So that I can publish new webcasts
-------------------
Acceptance criteria:
- Can get to admin part of the site
- Can add a new webcast
- Will go through validation
- Can use rich text editor for the description
- Can set publish date
===============================================================
As an administrator
I want to be able to edit the details of an existing webcast
So that I can fix typos and change the data if I need to
-------------------
Acceptance criteria:
- Requires login
- Goes through validation
- Will update the RSS feed
===============================================================
As an administrator
I want to be able to login to the site
So that I can perform administrative functions
-------------------
Acceptance criteria:
- Requires login
- Unauthenticated users cannot login
- Non administrators cannot login
- Passwords are not kept in the clear
===============================================================
Comments
Ayende,
Our team has been using BDD for the last four months or so, and I must admit that I am completely hooked. BDD has generated the same amount of interest for me as TDD did initially.
It appears that you are aiming for executable stories. Personally, this is something that I avoid. I tend to speak about system behaviors more in the small. I still call out domain concepts in my BDD specifications, but those concepts may be much more granular than user-story level.
I am working on an extensive example that I hope to have available next week. If you're interested, feel free to shoot me an email or watch my blog (www.testinfected.net).
Oh no. It is not executable, and it is not a DSL.
Those are notes about the story
What?!?!? No DSL?!?!
You've changed man. You've changed...
;)
I think you are heading down the same rabbit hole that I have been going down, in terms of the stories you are writing - and it becomes problematic really quickly.
the problem is that we are developers and we constantly have the developer goggles on, even when we don't think we do. so we end up writing stories in the wrong format: As a [role], I want to [Do some specific thing] so that [I can do some specific thing]. What we really need to be writing is, As a [role], I want to [goal], so that [motivation].
The difference is subtle, but has a profound impact on the stories. The major difference is in the motivation - a true motivation is not to do what you already said you want to do, or to do your job (as I've written in several stories).
THe other issue is the role you've specified. "User" isn't a valid role; and perhaps "role" is the wrong word. Dan North, again, suggested the word "stakeholder". I've suggested "persona" a few times, as well. We have to keep in mind that the "motivation" is directly attributable to the role - why does this person want to accomplish the set task. a "user" just wants to "use" the system. However, a "Software developer" may want to "learn about (insert webcast topic here)".
As an example, look the first two stories that you've written. You basically have "i want to see stuff so that i can see stuff". I would re-write the first two stories here, into a single story with better motivation:
As a software developer, I want to find webcasts that are relevant to me, so that I can learn more about these topics and become a better developer.
Acceptance Criteria:
When displaying a webcast summary, include the following information
Name
Date Published
Short Description
When viewing the details of a webcast, display all relevant infomration about the webcast, including
Name
Date Published
Short Description
Number of Downloads
Relevant files and links
... other stuff...
Should display the most recent webcast summary on the homepage
There are some very critical distinctions made in this story and criteria, vs. what you have originally written.
Notice that the story avoid the "do this so i can do that" format. It talks about a "software developer", which is the persona or stakeholder that you are targeting with your webcasts. It also talks about wanting to learn more about the topics in the webcasts - which is ultimately why we want to watch webcasts, in the first place.
The acceptance criteria is also significantly different. Notice that we've completely separated the "homepage" language into a separate criteria. This is because the word homepage begins to talk more about technical details or implementation. It's critical that we know to put the summary on the homepage, but we should not mix the behavioral criteria (displaying the summary) with the implementation criteria (display it on the homepage). Keeping these separate will give you more clearly defined criteria to work with and allow your unit tests to be more clearly written and scoped. For example, you should not need to write an integration test to view the homepage, just to test the summary display. By separating these criteria, we are not forced into that situation.
...
Dan North pointed these same problems in my stories, and pointed me to this post, which helped me understand what I was doing wrong:
http://iansrobinson.com/2008/06/05/rediscovering-business-benefits/
For a bit more information on my perspective in user stories and acceptance criteria, see the following post from a week or two ago:
http://www.derickbailey.com/2008/05/29/UserStoryAndAcceptanceCriteriaFormatting.aspx
Derick,
This is exactly the sort of info I was looking for when I posted that. Thanks!
Thanks Derick
Comment preview