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.
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.
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.
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 answersout 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.
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.
This month on the Cucumber Podcast we sit down with Alex Schladebeck who identifies as a Tester. Sal Freudenberg and Steve Tooke - co-founders of Cucumber - ask her about her recent keynote appearance at CukenFest London as well as her thoughts on the role of modern testers on agile teams. Alex can be found on Twitter and works for Bredex a software consultancy shop based in Germany.
When creating our scenarios, we want to fully describe the desired functionality, but not over-describe it. We want our scenarios to do more than check for correct operation. We want to paint a picture of what’s intended that aids understanding by others (or even ourselves) in the future. Which details should we leave visible, and which should we hide? In this webinar presentation, we will look at ways to distil our scenarios down to their essence and remove distracting incidental details.
In this webinar recording, George Dinwiddie, an experienced BDD writer, practitioner, and enthusiast, gives you some tips for writing scenarios which sing.