Is BDD testing? Part 2 - Collaboration and testers

For my second post aimed at answering the question “Is BDD testing?”, I want to explore the first part of my previously shared model, collaboration, in more detail.

A reminder of the model can be found here:

Collaboration

“If you’re not having conversations, you’re not doing BDD.” (Liz Keogh)

Through interviews and conversations with testers I had 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’.

“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 may be 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 to 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 distil 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 amigos’ 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 isn’t easy. 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:

Conclusion (so far)

As I 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 of my model 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 is 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.

BDD & Cucumber-JVM Training

Transitioning to behaviour driven development is much easier when you harness the expertise of real-world, experienced BDD practitioners. You can learn how to successfully use BDD techniques and Cucumber-JVM with our 2-day BDD training course.

Originally published at www.hindsightsoftware.com.