Hi Jake.
This is already happening on real projects (albeit Java and .Net ones using
things like Selenium to automate the scenarios). On most projects in
ThoughtWorks, when a tester finds a defect they describe it in terms of a
(failing) scenario. What it means is that the original story was missing an
edge case - or there was an invalid assumption - that has been flushed out
by testing.
Sometimes they use the defect number from the tracking system in the
scenario name. On one recent project the team didn't even have a separate
process for tracking bugs. A defect just came into the next iteration's
planning session as a failing scenario (described on a card rather than
automated at this stage) and got played into the workstream like any other
piece of work. The team found they actually had less to do because they
didn't have the overhead of managing a separate defect-tracking process.
On 11/6/07, Jake Howerton <jake.howerton at gmail.com> wrote:
>> This makes me wonder if some sort of bug tracking system could be
> integrated into the browser story editor where testers/customers could
> enter the passing and failing story.
>> Bug Scenario: bad addition to cart
> Given user has two apples in cart
>> When user adds two apples to cart
>> Then user has three apples in cart
>> Expected Scenario: proper addition to cart
> Given user has two apples in cart
>> When user adds two apples to cart
>> Then user has four apples in cart
>> When you fix the bug you can promote the expected scenario to a first
> class scenario ( or merge it with the one that did not cover the bug
> properly), and store the bug regression stories somewhere to ensure
> they do not fail in the future.
>> WDYT?
>> Jake
>> On Nov 6, 2007 4:25 PM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On Nov 6, 2007 7:39 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> > > Are stories intended to mean "it worked in one case" to indicate a
> > > feature is present instead of being an exhaustive description of how
> > > edge cases are handled?
> > >
> >
> > Ideally, yes. You'll typically have one scenario for each edge case. A
> > story has many scenarios (which again have many steps - G/W/T)
> >
> > Aslak
> >
> > > Are stories supposed to be comprehensive enough to pass a rigorous
> > > "heckling"?
> > >
> > > Thanks,
> > >
> > > Alvin.
> > > > ------------------------------
> > > >
> > > > Message: 9
> > > > Date: Tue, 6 Nov 2007 13:43:23 +0000
> > > > From: "Dan North" <tastapod at gmail.com>
> > > > Subject: Re: [rspec-devel] Stories vs. examples
> > > > To: rspec-devel <rspec-devel at rubyforge.org>
> > > > Message-ID:
> > > > <d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> > > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > >
> > > > Hi Ian.
> > > >
> > > > I find it helps to think about the audience for your documentation.
> (It is
> > > > documentation after all, it just happens to run, which is rather
> nice.)
> > > >
> > > > For the specs, the audience is developers. They want to know what an
> object
> > > > of a particular type - or more specifically in a particular role -
> does,
> > > > which other objects it interacts with and why. This audience wants
> to see
> > > > progress without leaving their IDE or editor, which is why we put
> effort
> > > > into making TextMate plugins and why we want to play nice with all
> the
> > > > Test::Unit runners.
> > > >
> > > > For the stories, the audience is testers, analysts and ultimately
> the
> > > > various stakeholders who are requesting the features. They want to
> know what
> > > > the system does and how to interact with it to get work done. They
> don't
> > > > really care what happens under the hood. Typically they are
> non-technical
> > > > (or less technical than developers) which is why we think there is
> so much
> > > > value in making their documentation look like documentation - just
> plain
> > > > words on a page. Even better, if you can give them green words on a
> page
> > > > when the feature is implemented and working, or red words on a page
> when the
> > > > feature isn't working, or grey words for unimplemented features,
> they can
> > > > see progress in a living document. Now make that document editable,
> like a
> > > > regular document, and you are well on your way to acceptance testing
> > > > Nirvana.
> > > >
> > > > So the process (described as "outside in" as opposed to "top down"
> or
> > > > "bottom up") starts by expressing a feature request as a story,
> driving out
> > > > the scenarios that define "done" for that story and automating the
> steps
> > > > that make up the scenarios. Then you use code-level examples to
> drive
> > > > inwards (that word "drive" again) from the outermost objects that
> the steps
> > > > identified. All the time you want to implement just enough behaviour
> to get
> > > > the steps to work, to drive the scenarios. Then you're done and you
> go to
> > > > the pub for a well-earned drink. Hence "beer-driven development".
> > > >
> > > > Hope that helps,
> > > > Dan
> > > >
> > > > On 11/6/07, Ian Dees <undees at gmail.com> wrote:
> > > >
> > > >> Hi, all.
> > > >>
> > > >> I'm posting a philosophical question here, rather than cluttering
> up
> > > >> the tracker for the patch where it originated.
> > > >>
> > > >> Quoth David, in response to some fuzzy thinking on my part:
> > > >>
> > > >>
> > > >>> Stories are not just another way to express examples - they're a
> > > >>>
> > > >> completely different animal.
> > > >>
> > > >> The offending clause of mine: "stories are another way to write
> your
> > > >> tests.... examples are meant for small, targeted descriptions of
> your
> > > >> code's behavior... stories are suited to longer, more detailed
> > > >> narratives."
> > > >>
> > > >> The intent wasn't to say that stories are a different syntax for
> > > >> examples; it was that stories and examples are two different
> syntaxes
> > > >> for two different test-writing purposes. But now I'm wondering if
> I
> > > >> even have _that_ right.
> > > >>
> > > >> In Rails-land, the distinction is much clearer: you typically see
> > > >> examples for testing code, and stories for testing applications (in
> > > >> the blog posts I've read, anyway).
> > > >>
> > > >> But in GUI-land, the picture blurs a great deal: you're always
> testing
> > > >> applications, but sometimes you're giving a tiny example of how one
> > > >> feature works, and at other times you're writing a story about
> several
> > > >> steps of an interaction between the customer and the UI.
> > > >>
> > > >> Anyone want to jump into these muddy waters?
> > > >> _______________________________________________
> > > >> rspec-devel mailing list
> > > >> rspec-devel at rubyforge.org> > > >> http://rubyforge.org/mailman/listinfo/rspec-devel> > > >>
> > > >>
> > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org> > > http://rubyforge.org/mailman/listinfo/rspec-devel> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org> > http://rubyforge.org/mailman/listinfo/rspec-devel> >
> _______________________________________________
> rspec-devel mailing list
>rspec-devel at rubyforge.org>http://rubyforge.org/mailman/listinfo/rspec-devel>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071106/d0ea50d5/attachment-0001.html