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.

This is the first in a series of articles that will take a look at 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 other story, it's important to choose where to begin – because, contrary to the advice given in the Sound of Music, it's not always a good idea to "start at the very beginning".

This month on the Cucumber Podcast, we sat down with Janet Gregory and Lisa Crispin to talk about their latest book, Agile Testing Condensed. Between them, they have a wealth of real-world experience helping agile teams think differently about testing. This conversation not only covers what you can expect to find in their book, but a wide-range of stories of best practices and the role of testers over the years. Matt Wynne and Seb Rose are asking the questions.

We recently ran a survey as part of the work to bring Cucumber into the SmartBear and HipTest family. It was a quick sample (189 responses collected in under a week) rather than in-depth research, but it yielded a couple of interesting indicators that I want to share.

The team at Cucumber are a special bunch.

Looking back on the first quarter since we were acquired by SmartBear, we took a day out together to reflect on that special-ness. We wanted to try and distill our culture so that we can be deliberate in protecting, celebrating, and spreading it as we integrate into the wider organisation.

This was originally posted on Matt's personal blog.

Barbara is a business analyst.

Until recently, Barbara hated BDD.

This was extracted from BDD Books 2 - Formulation by Seb Rose & Gáspár Nagy.

Over the past few years, there has been a growing recognition that BDD is an approach made up of three practices.

During Discovery, the team will capture concrete examples of how the system is expected to behave. While doing this, they will also uncover important business terminology. Formulation is the process of transforming the concrete examples into business-readable specifications that will guide development and document the product for its whole lifetime.

Who should formulate the scenarios?

I don't know if anyone's counting, but the human race must be creating millions of lines of code every day. It seems to me it would be useful to think about how we judge the value of that code.

I'll run through some of the common answers out there to this question and offer a couple of my own. I've presented them in a rough priority order, starting with the most fundamental, but ending with perhaps the most important.

Over the years that we have been using Gherkin, our approach to writing scenarios has evolved. Because Gherkin is very close to natural language it's very easy to learn, but just like writing reports or stories, it takes practice to do it well. There are three main goals that we try to keep in mind when writing scenarios:

• Scenarios should be thought of as documentation, rather than tests.
• Scenarios should enable collaboration between business and delivery, not prevent it.
• Scenarios should support the evolution of the product, rather than obstruct it.

The following six principles work together to support these goals. To make them easier to remember, we've arranged it so that the first letter of each principle makes up an acronym, BRIEF, which is itself the sixth principle.

Example-guided development is a suggested new catch-all term for the family of practices variously known as Test-Driven Development (TDD), Behaviour-Driven Development (BDD), Acceptance-Test-Driven Development (ATDD) and Specification by Example (SbE) that has been causing a bit of excitement in the agile community. This post aims to give you a summary of where this new term comes from and why it could make a useful addition to our industry's vocabulary.