generalisation should follow (if required later).
-----Original Message-----
From: agile-testing-uk@googlegroups.com
[mailto:agile-testing-uk@googlegroups.com] On Behalf Of Neil McLaughlin
Sent: 22 July 2010 10:27
To: Agile Testing UK
Subject: Re: Starting out with BDD
Thanks for the responses - they have been helpful.
Perhaps a complicating factor is that we are developing a generic
business intelligence tool
which is being driven by the requirements of 3 initial groups of
users. There are therefore
two types of customer; the owner of the tool and the owners of the
solutions implemented using the tool.
So the stories for the tool owner would be focused around the ability
to do generic things like authentication,
creating user defined entities & properties and their relationships
along with reporting on entity properties
across multiple entities, etc.
The stories for the owners of the implementations would be defined
using specific scenarios in terms of
outputs. I guess the concern we had initially was that these stories
seemed too big - there would be a large amout
of development effort (due to the amount of infrastructure work)
sitting under one story. I guess that part
of the problem is about combining the ideas of partitioning by
customer features and developer work
items which in reality are two separate things.
This large story (made up of concrete scenarios) seems a good starting
point but it is all about the 'outside' part
of 'outside-in'. I like the BDD idea described in the Ruby RSpec book
of working inwards using the same scenario
driven approach. Perhaps part of the problem is we focusing on end
users for all parts of our BDD whereas, as we
drive inwards, the behaviour we define is for consumers of our domain
objects (ie the system) rather than end users.
I think that part of our problem is one of partitioning our tests and
identifying who the user is.
Any thoughts?
On Jul 22, 9:02 am, "Nader Talai" <nader.ta...@ukonline.co.uk> wrote:
> Neil
> I would use outside in as Gojko says for defining what we need to do and
> ensure that scope matches what we need.
> When it comes to designing and writing the code use input to outputs i.e.
> follow the inputs to drive out what you do using tdd. This means that
your
> slices end up as thin ones and initially will have very little on the UI
> side but your code goes all the way through and you can start growing your
> design.
> You may need mocks to define what you need from external systems and stay
> focused on your objective and not the external system.
> Nader
> From: agile-testing-uk@googlegroups.com
> [mailto:agile-testing-uk@googlegroups.com] On Behalf Of Pankaj Nakhat
> Sent: 22 July 2010 07:09
> To: agile-testing-uk@googlegroups.com
> Subject: Re: Starting out with BDD
> Hi Neil,
> Apart from what Gojko said, i think the part of the problem falls how
> stories are sliced. I have often seen that stories are big features
(Epic)
> and they are then broken in to slices (Tasks), and individual slice may
not
> deliver business value in its own as it may be too low level or its not
> tangible.
> As Gojko said "Start with the outputs, the reports that the system
produces,
> instead
> of data entry operations. this ensures that you have the data you need
> to produce the reports at the end, and that you don't have superfluous
> data that nobody really cares about",
> I have found this approach really usefiul in terms of slicing the stories
> too.
> Regards,
> Pankaj Nakhatwww.pankajnakhat.com/blog1
> t : @pnakhat
> On Thu, Jul 22, 2010 at 3:01 AM, Gojko Adzic <goj...@gmail.com> wrote:
> Hi,
> (my previous message got dropped half-way, so sorry if this ends up as
> a double post)
> CRUD is not a user story, it's a screen. It's not a business function,
> but implementation detail. Why do the business users need a particular
> CRUD screen? (I know it sounds as a stupid rhetorical question, but
> I'm serious) What does it allow them to do?
> Often you don't need to implement an entire CRUD screen and deliver
> them one by one. Sometimes there is value in releasing two screens
> that allow you to set a subset of properties but together they bring
> value. You can then automate these tests through the UI and use the
> CRUD screens, but that will be hidden in the automation layer. Say for
> example that we have a risk report that lists users and their card
> numbers:
> Scenario: Only regular customers with a specific risk category and
> card type show up in risk reports
> Given the following users
> |name| type| card type| card number| risk category|
> |Mike |VIP | Mastercard |53111 11111 11111 1111|X|
> |Tom |VIP| Visa |41111 11111 11111 1111|Y|
> |John |Regular |Mastercard |51111 11111 11111 1111|X|
> |Steve |Regular |Mastercard |52111 11111 11111 1111|Y|
> Then the risk report for Mastercard and category X contains the
> following data
> |John | 51111 11111 11111 1111|
> This could, for example, invoke the user CRUD to save a user name,
> type and risk category and a completely different CRUD to save card
> details for that user. Any other information that would go on that
> CRUD (addresses, card expiry dates etc) aren't part of this story or
> criteria because they are not important for this particular report.
> Start with the outputs, the reports that the system produces, instead
> of data entry operations. this ensures that you have the data you need
> to produce the reports at the end, and that you don't have superfluous
> data that nobody really cares about. if you don't do that, from my
> experience, data schemas are often overcomplicated and contain many
> things that simply aren't used at the end at all.
> gojko
> On Jul 21, 9:26 pm, Neil McLaughlin <neilbmclaugh...@gmail.com> wrote:
> > Hi All
> > We are just starting out on a greenfield project and are driving our
> > development from executable acceptance tests using an outside-in/BDD
> > approach (SpecFlow + nunit + htmlUnit). We were previously using
> > stories and TDD, but no executable scenarios, as a fairly agile team.
> > Although we have a long way to go things are going OK at the moment
> > and we feel it is bringing some real focus to the development process.
> > However a lot of the early stories are largely admin type CRUD - for
> > example functionaility to set up user defined entities and their user
> > defined properties within the system and to provide a mechanism for
> > relating these entities to each other.
> > I have read Gojkos excellent blog post on the anatomy of good
> > acceptance test (http://gojko.net/2010/06/16/anatomy-of-a-good-
> > acceptance-test/) after having attended the agile testing meeting on
> > which it is based. Although I thought I understood what makes a good
> > test where a business rule needs elaborating I am struggling with this
> > infrastructure stuff - this manifests itself in difficulty in coming
> > up with the "So that I can ..." bit of the story as the infrastructure
> > stuff is only there to support the meat of the application which is
> > capturing entity specific data to support the business.
> > A lot of the scenarios are of the form:
> > Given the system doesn't have something
> > When I create something (using the web interface)
> > Then visiting a listing page shows the thing I created
> > I keep in mind that the scenarios are there to facilitate
> > communication but they seem to state the obvious or do you need to
> > start with the simple stuff to tease out the edge cases. I am also
> > aware that some of the tests are tending towards scripts using the
> > driving the UI.
> > Does anyone have any advice about how to write tests for this sort of
> > stuff or any experiences in starting out with BDD they can share.
> > Thanks in advance
> > Neil
> > Cross posted to the specflow group
