Is BDD Testing? Collaboration and testers

Share on FacebookTweet about this on TwitterShare on LinkedIn

This is the second part of my blog series looking into exploring the question, is BDD testing? In the previous post I discussed my motivations for creating this series and I also shared this model:

Is BDD Testing? A model to help testers understand BDD better

For this next post, I want to explore the first part of this model, collaboration, in more detail.


‘If you’re not having conversations, you’re not doing BDD’
Liz Keogh –

Through interviews and conversations with testers I seen that a lot of tests tend to perceive BDD as the use of Gherkin syntax and automation tools. Testers tend to pay very little attention to the collaborative aspects of BDD. I suspect that part of the reason is due to testers first exposure to BDD coming from Dan North’s article ‘Introduction to BDD’, which is heavy on tooling and light on collaborative exercises. This isn’t a criticism of the article since it was one of the first to be written. However, BDD has changed over the years and even Dan himself has said that the work he did with JBehave was more of a ‘thought experiment'[1].

‘There are things about your domain that you don’t know, or you’ve misunderstood, or that nobody’s thought of yet. By talking through examples in groups, the chances of uncovering these gaps and misunderstandings is increased.’
Liz Keogh –

BDD is about conversations

It’s about talking about your domain from the user’s perspective to ensure you are building the right thing, and this can be achieved by coming together as a team to have conversations. We involve members from testing, development, design and the business in an informal meeting that is more typically known as ‘Three amigos‘ to discuss and question what we plan to build. The goal is to dispel any incorrect assumptions we may have, and remove any ignorance we have around what we want to deliver.

There are tools we can use during our three amigos sessions to help us. A testers goal is to generate questions and ensure the conversation stays inside the scope of the feature. As a tester, questions are your best tool for collaboration sessions. I find the following techniques or phrases help in a session

  • The five Ws – What, Who, Where, When, Why
  • ‘This maybe a stupid question but…’ – Those stupid questions weed out a lot of assumptions
  • ‘So just to confirm….’ – Again, verbalising what is required will weed out assumptions

Gherkin and Examples

Another tool, that is synonymous with BDD is Gherkin. Gherkin uses Given, When, Then syntax to allow us to create examples in the form of Scenarios to demonstrate how we might expect acceptance criteria to behave. For example:

Given the user has not ordered yet
When the user adds a book into the shopping cart
Then a discount of 10% is applied to the total.

Unfortunately, Gherkin syntax is another of the tripping points for testers. To be clear Gherkin should not be used to create test cases, the goal of Gherkin is to help distill examples of how we expect Acceptance-criteria to behave. For example, a series of examples may focus on behaviour around a boundary of a specific value that results in different behaviour. It’s important to remember, as testers, that these boundaries are put into examples because they are core to what the business wants to deliver. They are not there as boundary value tests.

Gherkin examples are there to illustrate behaviour not to exhaustively test and it’s important that testers, when involved in Three amigo sessions, use their skills and knowledge to raise questions and share information, not design hundreds of tests. As an aside, if you are still using test cases in your day to day testing, then keep them separate from Gherkin examples and consider adopting new approaches such as exploratory testing.

Example mapping

Writing examples in Gherkin is hard. However, there is a new approach called Example mapping created by Matt Wynne that has been designed to help teams keep their discussion in scope, handle questions and ensure the right examples are being created. Matt Wynne has described in detail Example mapping here but in short it uses different coloured post-it notes as visual aids to help keep track of rules (acceptance-criteria), examples (Gherkin scenarios) and questions. You can read more about how Testers have got on with Example mapping here:


As I’ve said at the start of this section most of the testers I’ve met, when they think about BDD, think about Gherkin as a means to create test cases for automation. Although the outside in development section hasn’t been discussed yet. To me, the collaborative phase is the single most important part of BDD. The focus on discovery, raising questions and revealing information about what we plan to build is a cornerstone of testing. So it’s vital that we ensure this part of the process is carried out and that testing is involved.

Testers input into the delivery of a feature is more profound in the collaborative phase than in outside in development. I would even argue that you could execute the collaborative phase, not pursue the automation side of things and still see huge benefits. I firmly believe now that to carry out BDD successfully you must have the collaborative phase and to miss this part out will leave you exposed to failure.

Related posts:

Share on FacebookTweet about this on TwitterShare on LinkedIn


  • Thank you for this very interesting read. The main takeaway for me (sorry if I repeat what you already pointed out but that’s my way of reinforcing my understanding) is that regardless of whatever-driven-design, the most important tool is the one that may most frequently botch the entire thing is the peopleware, and the botching ensues through failure to correctly implement one of its principal capabilities which is that of communication – communicate something badly/incorrectly/insufficiently/vaguely/etc. and you’re in some serious soup, and lots of cash will be wasted unnecessarily, especially when the communication process fails at the beginning and little is done later to remedy things later. The communication thingy is strictly connected with information, which also should be clear/precise/etc/etc (and sometimes the customer may waste money in a really silly way just by delaying passing the information the developers may rather urgently need) and the information thingy should be considered as one of the most valuable aspects of development making it possible at all, and any tester/SDE worth its salt should be well aware of that. Using tools is secondary to that.

    • Mark Winteringham

      Hi Tom,

      Exactly, a lot of the BDD practitioners and trainers stress that if your team doesn’t have the maturity and process to collaborate with one another then no amount of tooling is going to help you. Unfortunately, it’s my experience that this is exactly what happens with teams trying to implement the tools first and wondering why it’s so hard.