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:
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.
When we founded Cucumber in 2013, our goal was to provide commercial services and products that would fund the development of the Cucumber open source project.
Today I’m excited to announce that Cucumber Ltd has been acquired by SmartBear. We have spent half a year getting to know each other, and I am very confident that the Cucumber project will be in good hands.