Toeing the agile line can lead to automated tests with high cost and low value. Listening to people who understand business needs will give you the insight to write only the most valuable tests.
By Paul Hicks at IntegrationQA
It's great to get together with so many people with an interest in solving the sorts of problems that come up so often during my working day; translating requirements into products and tests.
A room full of agile delegates from some of the largest (and smallest) companies in Australasia gathered in at CukeUp! Australia 2015 to share a concern: that behaviour-driven development is being swallowed by the tests it spawns. And we shared a common solution: forget the tests and concentrate on using BDD as a way to build understanding and agreement on a way forward. Together we explored the theme of Collaboration in a prison block in Sydney.
Cucumber, JBehave, SpecFlow and all the other tools that make specifications executable have an amazing allure to people who haven't ever used them. BDD done well is not about the tests that it might lead to, it is about collaboration and deliberate discovery. Teams that dive into BDD without learning this can quickly become disillusioned, swamped by thousands of poorly-writen specifications and hundreds of hard-to-maintain tests. Matt Wynne, speaker at CukeUp! and maintainer of Cucumber, will tell you "that is not BDD even if you're using Cucumber. (It is) building software backwards."
We spent most of the time at the conference exploring techniques and games that facilitiate this collaboration. Things like example mapping and event storming were used to quickly share the real meaning behind the stories that pass between business and project teams. Almost no mention was made of acceptance criteria or automated tests. Throughout the conference, everyone was echoing what Dan North said in the foreword to John Smart's BDD In Action: "The goal isn't generating acceptance criteria or feature files; it isn't automation; it isn't testing; (it) is to use software to create business impact."
BDD came bundled with gherkins and shiny new executable specifications, and people lost sight of the aim of BDD: collaborating *before* developing. We came away from CukeUp! with the intention of changing the focus from writing specifications to talking about requirements.
By Paul Hicks at IntegrationQA
It's great to get together with so many people with an interest in solving the sorts of problems that come up so often during my working day; translating requirements into products and tests.
A room full of agile delegates from some of the largest (and smallest) companies in Australasia gathered in at CukeUp! Australia 2015 to share a concern: that behaviour-driven development is being swallowed by the tests it spawns. And we shared a common solution: forget the tests and concentrate on using BDD as a way to build understanding and agreement on a way forward. Together we explored the theme of Collaboration in a prison block in Sydney.
Cucumber, JBehave, SpecFlow and all the other tools that make specifications executable have an amazing allure to people who haven't ever used them. BDD done well is not about the tests that it might lead to, it is about collaboration and deliberate discovery. Teams that dive into BDD without learning this can quickly become disillusioned, swamped by thousands of poorly-writen specifications and hundreds of hard-to-maintain tests. Matt Wynne, speaker at CukeUp! and maintainer of Cucumber, will tell you "that is not BDD even if you're using Cucumber. (It is) building software backwards."
We spent most of the time at the conference exploring techniques and games that facilitiate this collaboration. Things like example mapping and event storming were used to quickly share the real meaning behind the stories that pass between business and project teams. Almost no mention was made of acceptance criteria or automated tests. Throughout the conference, everyone was echoing what Dan North said in the foreword to John Smart's BDD In Action: "The goal isn't generating acceptance criteria or feature files; it isn't automation; it isn't testing; (it) is to use software to create business impact."
BDD came bundled with gherkins and shiny new executable specifications, and people lost sight of the aim of BDD: collaborating *before* developing. We came away from CukeUp! with the intention of changing the focus from writing specifications to talking about requirements.