From: "Gary Feldman" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
Sent: Wednesday, December 29, 2004 9:11 PM
Subject: Re: [XP] User Stories and 'the Big Picture'
>
> [EMAIL PROTECTED] wrote:
>
>> It gets included in the Executable Acceptance Test. That's
>> one of the nice things about using FIT/FitNesse - since the
>> EAT is simply an HTML document, you can include anything
>> you want in it. That typically includes enough explanatory text
>> to clarify what the tables do, but it can also include links to
>> other documents, etc.
>
> Here's a question that's been bothering me: How do you know that the
> information captured in the Executable Acceptance Test is a reliable and
> complete representation of the story?
>
> Your comment gives a different perspective: If you're saying that you can
> put anything you want into the EAT document, that implies you can put the
> original stories, use cases, scenarios, or whatever there. If you do
> this, then of course the issues about throwing away the originals become
> moot. Furthermore, this documentation isn't executable. So while the
> idea of using the acceptance tests as the container for the important
> parts of the early artifacts seems quite reasonable to me, it also
> sidesteps the questions that are being raised.
The non-table parts aren't executable. That's quite true.
However, that's also not all that relevant - what's important
is the tables that get executed by FIT. Everything else should
be minimized.
As far as stories go, see Ron's (and others) comments.
The story is basically a placeholder. It's one to three
sentences, and so what. Everything essential should be
captured in the tables in the EAT.
As far as scenarios: use case scenarios should be captured
in the executable part. There's no benefit in duplicating them
with any more text than is necessary to clarify them, and that
should, hopefully, be zero.
The amount of other documentation you put into the
EAT text varies by project. At a minimum, it's zero.
It grows if your project requires more ceremony because
of quality or regulatory targets, etc.
For example, if I had a traceability requirement, I'd
look strongly at what I could do to tie all the artifacts
together cheaply.
If you're doing use cases, a wiki based solution would
probably assign each use case and each stakeholder
a WikiWord that you could use as a crossreference.
Quick and easy. If you are using a batch solution, then
a quick Perl, Python or Ruby script could put things
together and make sure all the links worked.
The key item here is that before you put anything
other than the tables in a FIT test, you know who is
going to use it, what they're going to use it for, where
they need it and when they need it. If you can't define
that, you simply don't do it.
And you never let someone else tell you that you're
the one that should be using it.
John Roth
>
> Gary
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
