Comments on marcusoft.net: What i learned from 'From User stories to Acceptan...

Hello Oliver, brrr - being referred to as "...

2011-12-13T13:02:41.121+01:00

Hello Oliver,

brrr - being referred to as "the one who shall settle our argument" feels scary. I'll give you my point of view and you'll two will have to fight it out. :)

I think that you're right in that the scenario only can "guarantee" what is in it's context.

One can also wonder if it's feasible to write scenarios for every thinkable possibility...

I like Gjoko's definition "Key examples" which I interpret as being "enough to understand the key business rules". So the specifications you write on this level should not (in my opinion) be test of every thinkable permutation, but rather examples that are representative for the business logic and understand how it behaves.

You could of course write tests for all possible permutations (or maybe not but a lot of them :)) but I see no reason to automate that end-to-end. Most likely those permutations will be faster and easier to implement with the use of mock-objects and you setting up a known state and test against that.
Examples of this is how a page is rendered, or advanced business logic and calculations etc.

So, in my careful nature (:)), you are both right. But I think it's better to focus the scenarios on the Key examples you need to understand the business rules.

Well that's my view on the matter

Hi Marcus, thanks very much for sharing your impr...

2011-12-12T23:40:59.817+01:00

Hi Marcus,

thanks very much for sharing your impressions from the workshop and all the advice you put together in your post. It was very inspiring to our team (teamaton.com) and we had a great spec writing session right the day after reading your post :-)

Today, though, a tough question came up that my colleague and I were not able to answer for ourselves, even after almost an hour of lively discussion.

Our problem is with the boundaries and responsibilities of a given feature and its scenarios. My colleague argued that writing a specification for a given feature should imply that there should be no more behavior than that specified in the scenarios for that feature and that the tests should guarantee that. I argued that a set of scenarios cannot possibly guarantee anything outside of its own scope - every scenario can't even say anything about any other scenario in the given feature. For example, if we test the product page of our portal to contain certain elements, lets say a header and a picture, then in my opinion it does not imply that there can't be other elements as well, e.g. a picture subtitle, unless I explicitly specify so, whereas my colleague argues that this should be implicit since otherwise we could produce a situation where all our scenarios would succeed but we would see something on the product page that was never meant to be there. This in turn would mean that we cannot rely 100% on our specifications to tell us if the current development state is ready to deploy. How do you approach this kind of problem?

We would really appreciate your opinion on this hot topic!

Cheers, Oliver

2011-12-12T23:39:12.968+01:00

This comment has been removed by the author.

Yes, absolutely! Thanks for the clarification :)

2011-12-02T20:01:23.915+01:00

Yes, absolutely! Thanks for the clarification :)

Hi Pawel - When you write scenario or example you...

2011-12-01T11:08:20.837+01:00

Hi Pawel -

When you write scenario or example you want to write more than one example to show the different values and their expected results.

But when should you stop? At 3? 4? 1000? 1001?

That is a very hard question to answer in general terms as "it depends".

You should probably strive to have as few examples as possible and have them represent the different values that are interesting for the feature under test.

So if the example is about people getting free delivery for 5 books then examples with 4 and 5 books might a good start. That shows that you don't get free delivery for 4 books but do get free delivery with 5. That's the boundary.

But what can we more do? Can we "drill a hole" in the examples, break the knowledge they represent?

Yes, maybe... What about something else than books? Let's write an example with 1 CD. Should the customer get free delivery then? "No, it's just for books" or maybe "Yes, it's for CD's and books"

By using this technique we have not strengthen the examples and extended our knowledge.

I hope this clarify this a bit

Nice write-up! I wonder if you could explain a lit...

2011-11-30T19:01:08.309+01:00

Nice write-up! I wonder if you could explain a little more on the concepts of 'finding boundaries' and 'breaking tests' (a.k.a. 'finding holes in them'). Best greetings! :)