Recap Cukenfest 2018, London~ 6 min.

The Cukenfest is a conference about everything related with Cucumber and BDD. This year it took place in London on the 19th of April and there were talks about topics like example mapping, collaboration, mob testing and other interesting topics. What I liked a lot was the size of the conference. It wasn‘t that big, so that it was very easy to get in touch with other attendees. The talks were all about 20 minutes long, so that you could listen to lots of different topics and get a lot of input. Let‘s have a look on my summary of the day and my sketchnotes of the talks:

How to break the rules

Dan North
Dan was talking about Goldratt‘s four questions:

1. What is the power of technology?
2. What limitation does it diminish?
3. Which rules enabled us to manage this limitation?
4. Which new rules will we need?

He then applied them on ERP, cucumber and BDD. These are the answers:
ERP

1. Collect and analyse information across the organisation
2. Ignorance of what other divisions are doing
3. You must use cost accounting rules to run your division
4. Use throughput accounting to measure flow of value

Cucumber

1. Whole team can drive scenarios using plain text specification
2. Handoffs between silos of responsibility
3. Analysis must hand off requirements to programmers to automate and programmers must hand off code to testers to check
4. Team works together to define, automate,… tests

BDD

1. Whole team can focus on delivering software that matters
2. Speculative features and over engineering
3. Requirements must be comprehensive and unambiguous, solution must be flexible and extensible
4. Iterate quickly to provide valuable feedback and work in small chunks, also assume we are wrong

He concluded that rules are holding us back. So this is how to break the rules:

1. Understand the power of the new technology
2. Recognize the limitation it will diminish
3. Identify the existing rules we use to manage limitations
4. Identify and implement the new rules

Design through incremental learning

Konstantin Kudryashov
Konstantin‘s talk was about how at his company they achieved to gain more data and build features onto that. The key learnings are:

• Business also cares about tech
• Encoded learning increases knowledge sharing
• Technical details in scenarios decrease with certainty
• Reduced time working on wrong design and solution
• Not just living, but growing documentation

Do repeat yourself

Sabrina Leandro
Sabrina was talking about how to communicate your progress. First of all you should have these three components: a clear business goal, incremental steps and milestones for each step. Repeat yourself multiple times, be persistent, get your message out, use the same words and let the organisation know about your project. Before the project starts, you should create excitement. Use metaphors, draw red or green diagrams, make an application inventory and use the Bones Muscles Fat framework. During the project you should not only update your team about the progress, but the whole organisation. Update diagrams, graphs and the burndown, track progress removing code and try to turn this into a game. After the project finishes, you shouldn‘t forget to celebrate it with everyone.

Example mapping

Aslak Hellesøy
With software development and testing there are several problems that might occur in teams. For example scenarios which are way too long for anybody to understand or requirements that lead to different understandings. Example mapping might be a great solution as this is all about communication and discussing stories. You can use this approach during your Three Amigos meeting. Start with a story, write down acceptance criteria, find examples that illustrate those rules and then write down questions. With this method your meetings have a better structure and you can gain shared understanding, write better Gherkin scenarios, build empacy and get early feedback.

BDD in an agency

Toby Dykes
Toby was talking about introducing BDD to companies as an agency. It is essential to keep the discovery phase as short as possible. During this time you should give some training, set an expectation, discuss objectives, get to know each other and the business, practice BDD and agree on a commercial model. You should keep in mind that dynamic has challenges, commercials must reflect agile values, you need to agree on how to work, understand that collaboration is crucial and use BDD from the outset.

Collaborative Cucumber practices to increase BDD

Kayla Razavi and Katherine Bomkamp
The task of the two ladies was to increase the collaboration between product and engineering, for what they used Cucumber as a tool. The first case study was about discussing your stories/tickets. It is crucial to adapt the workflow if it doesn‘t contain collaboration. Audit your process, involve people and collaborate. The second case study was about learning stuff and getting better at it. Talk to developers to learn their language, ask for help and remember that if you can write English, you can write Gherkin. The conclusion was to build meaningful working relationships, to involve everyone in Cucumber and to remember that the Three Amigos are not the Three Adversaries.

BDD: the three-headed monster

Liz Keogh
Liz started with the statement that BDD is not about testing. It’s more about behaviour. After talking about Cynefin, she said that the new rule is to minimize speculative investment. The smallest investion is conversation. Find out whether you are doing things right or wrong. Try things out and keep in mind, that nobody uses the Gherkin syntax in normal conversations. Therefore you should write down the words that are used and worry about Gherkin later.

Hitting the testing iceberg

Gáspár Nagy
The test automation pyramid shouldn‘t be a goal, but it should be used as a tool. You should try to challenge things and ask questions. Think about your goal and why you are doing things to build good quality at bearable costs.

Empathy-driven testing

Shamyla Sidd
Shamyla was talking about using empathy as a tool to drive software testing. She started with a Bug Bash Story (timeboxed session in which everyone searches for bugs – actions should be fulfilled within 3 seconds). The conclusion is to include empathy-driven personas into your automation code to be constantly thinking about the end user. Then she continued with a Support Call Story with which she wanted to say, that you should look out for test ideas from support calls and social media posts.

Modified mob testing

Anand Shirkande
Knowledge sharing and creating learning processes especially is important, if a new member joins the team or if somebody leaves it. Traditionally this is made via documentation, sharing sessions or demos. But these lead to issues as they are monochromatic procedures, minor gaps turn into blockers and system configurations are missing. You could also use modified mob testing to focus on knowledge sharing. With the driver, navigator and observer you create an interactive process with some benefits. This is a process for polychrome knowledge sharing, you get detailed documentation, there are no gaps, you have one round of guided practice, there is no missing configuration and abbreviated details are shared.

Why software changes, and how that should change what we change when we change software

Nat Pryce
Nat was talking about Lehman‘s categories of software system (s-type, p-type and e-type) and how software evolution is crucial. Software must change or it becomes less useful and as the system evolves, the complexity increases and it gets harder to maintain. So the system is only useful if you can change what it does. People who use or change the system, the changes themselves, the deployment tools that are used for the changes and the tests are all part of the system.

The one with the compiler always wins

Ulrika Malmgren
As a programmer you decide…

• What is possible
• Who knows about how it works
• Over your time
• What quality level it has
• How long it takes
• What the code will look like

You should stand up for what you‘re doing, because you have great power, but also great responsibility. Acknowledge the power and use it for good and don‘t forget to follow your values and beliefs. Try to be something that makes you happy. If that is not the case, consider if you should change direction.

The second day was an unconference with a lot of intersting sessions and discussions. I‘ve managed to do some sketchnotes of several ones:

Reducing step duplications

How to avoid overly long scenarios

Example mapping – how to get started

How to get devs/wider company to buy into testing

As you can see lots of topics have been touched and I learned quite some interesting stuff and met great people, like Marit, James and Sascha. I liked that you could dive into cucumber related topics and get to know insights and experience. I hope you enjoy my article – let me know if you need the sketchnotes in high resolution.