BDD can work

“No tendency is quite so strong in human nature as the desire to lay down rules of conduct for other people.” ~William Howard Taft There are way more case studies about disasters than success. And I don’t believe, as I have worked on some projects that on the face of it, ran poorly but still managed to deliver. It is very easy to dissect a project negatively - there is always room for improvement.

How much do we need to say?

how much do we need to say? “Every so often, we get the bungee jumps, but as a whole, life mostly floats along. We make our lives exciting in retrospect, but life is a lot of mundane moments, which isn’t bad” - Dr. Matthias Mehl While we may imagine we communicate in a clever complex manner, a lot of what we say that is actually useful is a lot smaller vocabulary than you would imagine.

What did they mean?

What did they mean? Let’s take the user story from previous post, and start with the granularity (i.e. the scenario steps). While specifying steps is an even better guide for developers to follow in their implementation, it’s important to remember anything we say can be misinterpreted! Feature: As a online shopper, I want to be able to add multiple items to my shopping cart, in order to progress through payment process quickly Scenario: Add single item to shopping cart Scenario: Add multiple items to shopping cart Scenario: Add multiple of same item to shopping cart Scenario: Remove items from shopping cart The first scenario is basic check that I am able to add a product to my shopping cart, so will use that as first example of how to make the scenario into an automated acceptance test.

What do you mean?

What do you mean? After working on several BDD (Behaviour Driven Development) projects, I was struck firstly by what a great development approach it is, if only from a test engineering viewpoint. While on the tech side, BDD is more clearly understood, clients may find the style of writing requirement commonly expected with this approach, more involved than they are used to. There is still value in defining user stories only, if you are happy with trusting team to take care of implementation, and ask relevant questions.