I’ve set myself a challenge to attend at least 3 meetups a month, which includes 1 I’ve never attended before. Click here to read about the other meetups I’ve attended this year.

Here is my progress so far:
Meetups attended in 2020: 7/36
New meetups attended in 2020: 3/12
(Last updated 10th March 2020)

Event: South West Test
Date: 6pm Thursday 27th February 2020
Host: Samantha Miller
Sponsor: Socially Responsible Recruitment
Location: The Station, Silver Street, Bristol
Talk: BDD is not Testing
Presenter: Aslak Hellesøy

I’ve been wanting to attend this meetup for some time. For almost every month in the last year I’d committed myself to attend. However, various obstacles kept getting in the way.

I finally made it, and it was well work the journey.

The main purpose of Aslak’s talk was to help us understand the titular statement “BDD is not testing”. This was done by first explaining its origin.

From TDD to BDD

Test Driven Development (TDD) came before Behavior Driven Development (BDD). Although Aslak went back even further and introduced FIT (framework for Integrated Testing).

FIT integrated the the work of all stakeholders including non-technical customers and analysts. Customers could explain the requirements by providing a table of input and output values. These tabulated requirements helped the programmer develop the right thing.

This eventually led to the implementation of TDD, a process for writing test, and then developing the code so that the test passes. After this, the code is refactored (an alternative word for ‘cleaning up your own mess’).

General rules are that no production code can be written unless it is to make a failing test pass. Also, only enough of the test should be written so that the test fails. Once the test failed, the developer can work to make the test pass.

TDD is a process that aids software development. It is meant for developers, not testers. TDD involves writing tests, but this does not mean it is testing. Confused? That is not at all surprising.

It was not long before Behavior Driven Development (BDD) came along. BDD is very similar to TDD, but offers something more. Instead of writing tests that only the developer understood, tests were written in a way that other stakeholders like Business Analysts could understand. It provides a common and shared understanding of what the code was meant to do. This makes a lot of sense. How can we be certain the requirements have been understood when the developer is the only person who understands the tests?

But remember, neither BDD or TDD are testing!

What should Testers be doing?

Since we’ve established that neither BDD or TDD are development processes, and therefore not testing, what are testers supposed to be doing?

Aslak sought to answer this question by first discussing the idea of Burned Toast Development. It was mentioned why this is called this, but I have forgotten the answer. I’ve seen this process developed too many times, and I confess I also took part in this at a time during my early years as a tester – a time when I was younger and not as smart.

The issue with this is it can result in a lengthy feedback loop. The programmer doesn’t realize they’ve created a bug until the business has prioritized it. Business analysts are very busy people and don’t always have time to review bugs every hour of every day. If there is only a weekly review, it could take a week for the developer to become aware of the bug.

Burned Toast process which continues in a loop
Developer writes code
Tester finds bug
Business prioritizes bug
Developer fixes bug
Burned Toad Development

Testers need to provide developers with fast feedback, so we need to reduce the feedback loop. Even better, we could reduce the risk of them being created in the first place. Bugs are often created from misunderstandings.

A process that includes discovery, formulation and then automation could help ensure the team is developing and testing the right thing.

Discovery
	3 Amigos
	Example Mapping
	Done by whole team 
Formulation
	Write gherkin test cases (GIVEN, WHEN, THEN)
	Written by developers and testers
	Reviewed by business analysts
Automation
	Option for pair programming
	Done by developers or testers
Discovery, Formulation and Automation

Discovery

Many teams like to include ‘3 Amigos’ in the decision making process. What are ‘3 Amigos’? They are a diverse group of people with different insights into how a user story should be implemented. Common members of the group include a developer, tester and business analyst – but is not limited to this. The aim of getting the ‘3 Amigos’ together is to discuss the user story, clear up any misunderstandings, and generally discover what the team does not know.

The team could take part in Example Mapping as a way of ensuring everyone understands the rules. This gives the team an opportunity to discuss the different rules and requirements, create some examples and raise any questions. A great article that describes example mapping can be found here.

Example mapping example

Formulation

There might be a temptation to write the gherkin scripts during the discovery phase. This is not the best time as valuable meeting time could be wasted sitting down writing up test scripts. The team should be discussing the requirements and creating some examples.

The examples, written up during example mapping, are transferred into gherkin test scripts which use the GIVEN, WHEN, THEN format. Writing test scripts in this way allows all members to understand them, regardless of programming ability.

The gherkin test scripts should still be written with someone who can program (developer and tester), and then reviewed by the business analyst to ensure that there are no further misunderstandings.

Automation

Once the examples have been agreed on by the team, and converted into gherkin test scripts, they tests can be automated. Generally, this needs to be done by someone who knows how to code like a developer. However, this could also be done by a tester.

Cucumber

Gherkin test script in Cucumer

The talk ended with a demo of Cucumber. As someone who already uses Specflow for test automation, I was very keen to see Cucumber in action. It follows a very similar process. The tests were written out in a feature file using gherkin syntax. A method is then created for each step which contains the code for the step to be automated. It was very interesting to watch, and I’d definitely like to give this a go myself – get a proper insight to how it compares with Specflow.

Next Meetups

I’m really excited to announce that I will be giving talks at 2 meetups over the next month.

Click here to see more blog posts about meetups I’ve attended in 2020.

Further Reading