So, a few years ago I was involved in an agile transformation.
I was part of the consultancy brought in to work with a client.
As part of our learning through trial and error, we decided to try Behaviour Driven Development.
I wanted to learn from what we went through and share it with others.
I also wanted to learn what some of the people on the client site learned.
I worked with two separate people and we came up with 2 talks.
We worked with the same theme but taking their different experiences and personalities we created different talks.
It worked quite well.
Thanks to @andrewjutton and @brightoniant for joining me on this exercise and also being willing to go through their first presentation experience with me.
Recently @friendlytester wrote a post which reminded me of that time.
His post prompted me to write this post.
Are you sitting comfortably? Good. Then we'll begin.
Many moons ago, a few people came across SpecFlow and this lead them to Behaviour Driven Development.
We didn't spend time thinking through exactly what we wanted to achieve, or how we'd know if we were getting there.
SpecFlow, however, was shiny and new and we were still working on how exactly we were going to use automation in testing.
We were lucky that people with the business knowledge were available.
We were unlucky in that the people with business knowledge were offsite most of the time.
We decided to trial BDD, which was driven by the tool and by the 'Software makers', which at the time did not include anybody from the business.
This (now) seems wrong and didn't work as effectively as it could have.
I have no evidence to back this up, but I believe that having the business suggest the idea of BDD would change the approach completely.
BDD is about focusing on collaboration, not focusing on a tool.
You can work with BDD without ever using automation and receive plenty of value.
In-some cases you'll be better off as you won't get lost in the tool and focus on the collaboration.
Collaboration is the key and point.
So, there we were; Giving it, Whening it and Thening like mad.
Mostly written (solely) by the Business Analysts and therefore bypassing a shared understanding and attempting to share one person's understanding.
Here's an example:
Scenario: Display ‘Insurer Selection’ screen
Given that Insurer selection screen has been invoked
When the Insurer selection UI is rendered
Then the ‘Insurer Selection’ page is displayed
And the ‘Risk Variation Name’ field is displayed
And the ‘Risk Variation Name’ field is selected
And the ‘Customer Name’ is displayed
And only breadcrumb ‘Select Insurer’ is displayed
And all insurers setup in the system for the policy type are displayed
And all insurers setup in the system for the policy type are not selected
And the ‘Next’ button is disabled
We were learning.
We hadn't quite grasped yet that the how wasn't important, it's the what that is important.
What is actually trying to be completed?
End of part one.
