Telling your stories using some concepts of BDD

Within the testing community, the statement is going around that Behaviour Driven Development (BDD) is some kind of threat for testing. I must say that I have a different point of view on that.
The threat is that business is somehow “enforcing” the tester to test the user stories as written down in requirements using an agreed Domain Specific Language (DSL). It can/will limit us by only testing these requirements and not look further than that.I look to it from another point of view. Let me elaborate on that.

As I’m an exploratory tester, requirements are just guidelines for me. It is useful information and it helps me to generate test ideas, to identify areas of risks where to focus on. I start my tests with looking at the product, walk thru the generic flows and at a certain moment going into the deep. For every exploratory session I do (between 60 – 120 minutes), I write down my observations. These observations are my notes to show what I have done, when someone wants to see that.

But the notes are written down in such a way that it is possible that other people might not understand them and that it can not be re-used. To make my notes more accessible, easy to understand, I defined with my team mate a Domain Specific Language that would benefit us, me as a tester and him as an automator.

We decided to use Gherkin for that. That means for me as an exploratory tester that I write down my notes in a “language” that can be understood by my stakeholders. Note that I did not write down all my notes in this Domain Specific Language. Only the tests that I have done and were recognized as candidates for the scripted regression test suite. By doing this, I directly support my team mate with his automation. The so called feature file containing the Gherkin script can be automated directly.

Not only the automation team benefits from this approach, also other stakeholders. Stakeholders like End-to- End test team, Functional Maintenance to used these test for regression test purposes. Business Analysts and Solution Designers to understand how the requirements are tested. The Product Owner, it is easy to read for her.

An example, I use a banking App screen mentioned in figure 1

figure 1 : Transfer screen

My exploratory test note may look like:

In screen ‘Transfer’, I fill in the amount ‘1.10’. For Recipient I fill in the name ’S.P. Schrijver’ and account number ’NL82INGB0556099186’
I tap on button ‘Next’ to approve the transfer

As I write it down in Gherkin, it will look like this:

I see the screen “Transfer”
I enter “<amount>” in the “amount field”
I enter “<name>” in the “beneficiary field”
I enter “<account number>” in the “account number field”
I tap on button “Next”

See figure 2 for more context

figure 2 : Transfer screen with Gherkin statements

“<amount>”, “<name>” and “<account number>” are variables, so this small script can be used multiple times in an automation script

In stead of the Business being in charge of this so called Behaviour Driven Development, I as a tester am in control. I write a so called BDD script after I have executed a test, while the business is doing it upfront, before the test phase starts. So when I create my session report for this specific test situation, I tell my story using some concepts of BDD.


One Comment Add yours

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s