specification by example

Executable specifications – what would you do?

Augusto Evangelisti Uncategorized , ,

Can you help?

Executable specifications are used in BDD/Spec By Example as a mean to describe an application behaviour in business language. They are executable because they are linked to tests that exercise the behaviour of the application itself.

Let’s imagine we want to develop the solution to the FizzBuzz problem, Which one of the following solutions would you adopt and why? If you have a different better solution than the two I list, please add it!

1. Specific examples:

Given we are printing numbers using FizzBuzz
When the number is <number>
Then we will print <answer>

|number|answer|
|      1      |     1    |
|      3      | Fizz    |
|      5      | Buzz  |
|      6      |  Fizz   |
|      10    | Buzz   |
|      15    |FizzBuzz|

2. Generic Rules

Given we are printing numbers using FizzBuzz
When the number is a multiple of 3
Then we will print Fizz

Given we are printing numbers using FizzBuzz
When the number is a multiple of 5
Then we will print Buzz

Given we are printing numbers using FizzBuzz
When the number is a multiple of 3 and 5
Then we will print FizzBuzz

Given we are printing numbers using FizzBuzz
When the number is a not a multiple of either 3 or 5
Then we will print the number

Be lean, ask “why?”

Augusto Evangelisti Agile Software development, Agile Testing, BDD, Lean Software Development , , , , , , , , , , , ,

why-god-why1

Your best piece of code is the one you won’t have to write.

Yes I am serious, and no, I am not intoxicated, let me tell you a story.

It was a sunny summer day in Dublin and “the three amigos” (Tester, Developer and Product Owner) were discussing the next user story to deliver.  It all started as usual with the Product Owner explaining what we were meant to do and as the story was quite small and easy we were soon starting to write our examples that would become acceptance tests and eventually code.

Everything was going smoothly, we had already agreed that we would add a field to our payload with the new information, until out of the blue, the tester said:  “why? I mean, why do we need to do this?”

The product Owner said: “Because we need to send extra information to customer A!”

The tester insisted: “But why do we need to send it to customer A?”

The product Owner said: “Because we always send it to system X so that it can create product Y”

Then the tester said: “But customer A doesn’t use system X and doesn’t sell product Y, so why do we have to send it?”

The product Owner said: “You might be right, but Mr. SuperBoss said he wants to send it!”

The tester said: “Well, we need to ask Mr. SuperBoss WHY he wants to send it”

The product Owner stood up, went straight to Mr. SuperBoss and asked him.

The fact is, there was no reason, we were wrongly assuming that customer A would need it.

Would you agree with me that the code we didn’t write is super clean, extremely cheap to develop, test, deploy, maintain and sunset?

It only ever costed a conversation, and a few whys, I bet you can’t do it much cheaper!

If you don’t see the business value of what you are delivering, ask for it, you might get a nice surprise and find out you don’t need it at all.