Behaviour Driven Development (BDD) Starter for 10
A couple of years ago, my role was to train users on how to use the software they had just purchased. I always wanted to learn a bit of the lingo, the normal phrases, hello, goodbye,nice to meet you, and, most important, 2 beers please!
I got the opportunity to visit a large customer, just outside of Budapest, on the Pest side. So I thought, time to learn some Hungarian. It was the most complicated language I had ever come across, it was totally unique, the languages I could cobble together, in the past, had some basis in Latin, German, even Slav and I would be able to pick up a phrase, but this was something else, it was HARD!
When I arrived and did my normal introduction, where I would apologizes for murdering their Hungarian language, I ended up insulting them even more, as they spoke Magyar (even if Google calls it Hungarian). I never even got their language name correct!
I learned my lesson, and as long as I can order 2 beers that is as far as now I go!
So when I was introduced to a new Language in Development, called Gherkin, and was told it only had 3 words, I was delighted.
How can you write a specification for a Development using 3 simple words?
Although inverted, this is a great diagram, of a User Journey.
We start at given, go to when, arrive at then! Given is the things we need to do the next thing, the When. The When is the action we undertake that will lead us to the Then and the end of our journey.
Given I Am On Google Search When I Search For Scotland Then I See The Results For Scotland
When I was introduced to BDD we were shown a website on the big screen. 9 of the 10 of us left the class, and one by one brought back in we were shown different things on the website (press this and that happens, this and that happens, these together, this happens and so on), and we were told to document what we seen.
Then when we were all back, we handed our document to the person next to us. Of course we were trying to show off, some had been able to write War and Peace in the 30 seconds. We then followed the instructions of our neighbour, to replicate what the other had seen. Not one of us could follow the other persons instructions!
It proved that even 10 QA nerds in a room, would write things down in different ways. The introduction of BDD and Gherkin changed that.
The next time, different demo was shown to us, and we all used Gherkin, and without fail, when handed the bit of paper we could follow it. I'm not saying everything was correct, it was Friday afternoon by this point. But it was so much better to follow
When I Click On Red Button Then Green Light Came On Given Switch is off When I Click On Red Button Then Blue Light Came on
BDD changed the way I worked in QA, in fact my life. I dream in Gherkin, Given I wake Up with my alarm, Then I'm going to have a Coffee, Then Go To Work. Which normally becomes Given I Have Slept In, Then I have No Time for Coffee, Then Go To Work!
It reads natural, but more importantly, reading the above paragraph, I can see the steps. I can see the different journeys. I still go to work, but because the Given has changed, my prerequisite for this journey is I have overslept, I still go to my work, just no coffee today!
That leads perfectly on to BDD User Stories/Journeys.
I mention the "As a User, I want..". I do not like that, as what happens if a scenario comes up where you are not a user? I'm testing the security, does that change my User Story to be, "As a Non User? I want..." As soon as you introduce inconsistencies in the language, it becomes difficult to follow, and allows different people to do write it in different ways.
"As a User, I want to..." what happens if the user I am using doesn't have the permission to do the thing? But the user you are using, does? Or maybe we have the same permissions but something is missing from my user Journey, to stop me doing the thing? As soon as you introduce vagueness in the language, we can not all follow.
So let me introduce the first and most important statement in BDD
Given I Am User "X"
There is no inconsistency there, I am User X, there is no vagueness, I am User X, and I expect X to be able to login, as I've said he is a User. Everything that comes after this, will be done as User X.
Do not be scared to have a company directory as part of your test suite. One of my previous employers had a file with stock photos for each imaginary user. Even including background on on their personallities. I always wanted to be Michelle, she seen a button and clicked on it. You knew when you seen a test case with Given I Am User Michelle you were expecting to do some random stuff!
A directory does help everyone when writing the BDD to put themselves in the users shoes, and know what permissions EXACTLY they have.
User - Mark Duffy
Username - MDUFFY
Roles - Admin
User - Joe Bloggs
Username - JBLOGGS
Roles - Read Only To X
Read Only To Y
So your first line in any Feature Test should be:-
Given I Am User "Joe Bloggs"
Given I Am User "Mark Duffy"
As the QA to the above, I'm going to login as Mark Duffy, or Joe Bloggs, not some random User whom I hope has the permissions you want me to have!
For every step you write, it can be reused by others. Every step you write will one day become part of...
Given I Am User "Mark Duffy" When I Run Full Regression Test Then Full Regression Test Passes
And my next blog will be on how BDD Builds up, and after that initial overhead, it speeds up the process.