Last week Elisabeth Hendrickson published a blog post called Momentum > Urgency. Please go read it if you haven’t already. In the post she shared a list of observations that she had made when teams achieved a sense of momentum:

• Everyone on the team has a shared understanding of the big picture and what “good” looks like so they don’t burn cycles on unnecessary or non-useful work.
• The team breaks the work into small pieces (a couple days of work at most) that still represent incremental business value (even if not user-facing features).
• The team embraces the technical practices necessary to ensure that the code they deliver does what they intended it to do.
• There’s an engaged and responsive product manager* who is considered part of the team, and who does hands-on acceptance of the work.
• When the work is “accepted,” it’s done. The entire team can stop thinking about it.
• The work, and the status of the work, is visible to everyone.
• The team as a whole has a strong sense of partnership and trust, so the visibility never becomes a mechanism for micromanagement.

Reading the list, I realised that these were very similar to observations that we have made of teams that practiced BDD successfully.

There have been a couple of articles published recently by Nikolay Advolodkin (SDTimes and SauceLabs) that use a straw man argument to critique Behaviour-Driven Development (BDD). BDD is not test automation -- it’s collaborative requirements analysis combined with test-driven development (TDD), which despite the name, isn’t testing either.

The Test Automation Pyramid was popularised by Mike Cohn in his book, Succeeding with Agile.

https://martinfowler.com/articles/practical-test-pyramid.html

Over the years it has been rendered in dozens of different ways.

It has been applied, misapplied, discussed, dismissed, and repurposed. Through all it’s many changes, it remains just as useful at starting heated discussions as it ever was. In this article I add fuel to the fire by revisiting the eviscerated triangle that I first published in 2015.

Previously…

1. Origins and evolution of the user story
2. Discovery-discovery/?utm_source=userstories4&utm_medium=blogpost&utm_campaign=User-stories-4-BP)
3. Small or far away?

This is the fourth in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. This post is the last in this series, but certainly not the last time I'll be talking about user stories. However, since it brings the current narrative arc to a close, it is perhaps the end of the beginning.

This month, Matt Wynne and Seb Rose sat down with Richard Lawrence and Paul Rayner to talk about their new book "Behavior-Driven Development with Cucumber". The book incorporates their many combined years of experience teaching BDD to agile teams.

Matt and Seb explore what readers can expect from the book as well as digging into their own experiences teaching and coaching teams in adopting BDD and agile practices.

This is the third in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every good story, there's a beginning, a middle, and an end. This post is a continuation of the middle.

In the first post in this series we introduced the concept of the Screenplay pattern and busted a couple of popular myths about it. Now it's time to start digging into some code to give us a real example to demonstrate the pattern on.

The problem with writing this kind of tutorial, always, is finding the right balance between an example that's so complicated it gets in the way of your understanding the thing we're actually trying to learn about, and one that's so simplistic that the need for any kind of software design seems superfluous. If you'll forgive me, we'll err towards the simplistic here, and I'll trust that you've seen enough complex code in the wild to recognise the need for some design work.

TL;DR: Since v1, Cucumber-Ruby has used Ruby's load to auto-load support and step definition files. This can result in surprising behaviour where files you've already loaded are asked to be loaded a second time by Cucumber. As of v4, users will get the option to specify whether Cucumber should use require or load by setting the top-level configuration option Cucumber.use_legacy_autoloader. If unset or set to false, then Cucumber uses the require keyword. If set to true, then Cucumber uses the load keyword, which reloads the files. This is a breaking change; hence releasing it in v4.

This is the second in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every good story, there's a beginning, a middle, and an end. Welcome to the middle!

Once you've decided to invest in test automation, sooner or later you'll begin to realise that you need to care about the maintainability of that test automation code just as much as you do about the implementation code itself.

For acceptance tests this problem is particularly acute: driving the application from its outside edges involves connecting to APIs, databases, web UIs etc., and this code can quickly get out of hand. Having tried several different approaches myself over the years, I've come to believe that the Screenplay pattern is the best technique we have today.

But it doesn't get the attention it deserves.