On Sun, Apr 5, 2009 at 11:16 AM, Zach D. [email protected]
It seems that when developers write scenarios they often walk through
everything logically and fill in every input field from a scenario.
When my customers write scenarios they don’t do this, they tend to
think higher level. They write: “Given I register for a conference”.
My customers give me mockups and indeed specify what fields must be
When scenarios too detailed oriented for how “registering for
a conference is done” then it becomes a maintenance burden any time
how registering for a conference is updated.
Fine, but then you’ve shifted the maintenance burden to your view specs.
I like allowing my
scenario to remain expressive about the behaviour of the app while
leaving out the details about every form field being filled in.
In many cases, if not most, what the user types is part of the
behavior of the app. Not for merely descriptive information - agreed.
But in my current app, most fields lead to differences in behavior.
E.g., the challenge is public, Zach has been invited to it, it expires
on a certain day, etc. I consider this information essential to the
behavior of the app, not “merely” the UI.
Of course, I’ve always felt that the UI is the most important part of
the app, anyway. I feel that if certain user actions lead to certain
physical output, then I’ve fufllled the requirements of the app.
I also don’t think the scenario should try to relate the forms on the
UI to the user. There are better tools for this job: wireframes,
screen mockups, and the actual UI itself. It sounds like you may have
an expectation that the scenarios should read like step by step
instructions for using the app? An interesting idea, but it adds an
additional responsibility to the scenarios which I think will
ultimately convolute the value they are trying to express. At least it
has when I tried to do that months back.
You have to test this stuff somewhere. And perhaps I’m just
old-school, but to me, a user story does indeed specify what the user
does. If it’s too general, that makes its acceptance criteria