5 ms·

> Saving Agile with BDD and Cucumber First value of Agile Manifesto: "Individuals and interactions over processes and tools"

deanCommie 11y ago
"over", not "instead of". Having not yet read this interview (did you?), I'm willing to give the benefit of the doubt that he identifies some problems with Agile teams that COULD be solved with BDD and Cucumber (for teams that want and choose this approach)
phlyingpenguin 11y ago
One of the nice things about BDD tests in Cucumber/Gherkin is that they're written down in plain text (English), a language that managers, testers, and developers all presumably speak. The Gherkin language is actually very useful for facilitating communication/interactions.
- rubiquity 11y ago
  The myths of having non-developers read tests have been dispelled for years. I'm not even going there.
  - HenryTheHorse 11y ago
    That's too broad a claim. Why are non-developers in your organization not willing/able to read test cases?
    - estefan 11y ago
      I've never worked somewhere where non-devs have done anything with tests. They've been too busy doing non-developery things.
    - sanderjd 11y ago
      I won't be quite so pessimistic about the possibilities as other people here, but I share their experiences. It seems possible in theory but nearly impossible in practice to walk the tightrope of creating a language convenient enough for non-technical people to read and write without getting frustrated by it, while retaining its programmability and maintainability without driving the developers crazy. It's just a special case of the general problem with tools that aim to be easy for non-programmers to use while doing the same things as programming languages. It's always a leaky abstraction.
  - matthewmacleod 11y ago
    They haven't, in my direct experience. I've found it very useful, where there's ambiguity about how a particular feature works, to write a Gherkin spec that describes it. It's easy to understand, and can be agreed upon or even edited by my colleagues who aren't developers, but remain part of a CI process. YMMV, but this remains one of the lazier dismissals of BDD.
  - wpietri 11y ago
    But non-developers read specs all the time. The BDD goal is to create readable specs that also work as executable tests.
ryanmarsh 11y ago
"over" not "instead of"
kabouseng 11y ago
Thats perhaps why he says in the interview it's not important to write all the tests out in detail right there and then, but the discussion between the developer, business person and tester is the important part. (paraphrased)
omouse 11y ago
Except that when most teams adopt the SCRUM flavour of Agile, they're dropping much of the processes and tools that help (pair programming, test-driven development, etc.) So yeah, it's important to value individuals and interactions but not at the expense of light-weight processes and tools that help deliver a quality product.
dragonwriter 11y ago
> First value of Agile Manifesto: > "Individuals and interactions over processes and tools" Right. That means processes and tools should serve individuals by supporting their interactions, rather than individuals and their interactions being reformed to fit preconceived processes and tools. That doesn't mean that processes and tools are irrelevant, or that sharing experiences and ideas about how particular processes and tools can serve individuals in their interactions is contrary to Agile. (In terms of promotion of processes and tools, it really has nothing directly to do with whether or even how those things should be promoted: it does have a lot to do with how -- and who on -- teams should evaluate processes and tools that are being promoted, though.)
s73v3r 11y ago
And does not the Agile Manifesto say they still find value on the stuff on the right?

deanCommie 11y ago

"over", not "instead of". Having not yet read this interview (did you?), I'm willing to give the benefit of the doubt that he identifies some problems with Agile teams that COULD be solved with BDD and Cucumber (for teams that want and choose this approach)

phlyingpenguin 11y ago

One of the nice things about BDD tests in Cucumber/Gherkin is that they're written down in plain text (English), a language that managers, testers, and developers all presumably speak. The Gherkin language is actually very useful for facilitating communication/interactions.

rubiquity 11y ago
The myths of having non-developers read tests have been dispelled for years. I'm not even going there.
- HenryTheHorse 11y ago
  That's too broad a claim. Why are non-developers in your organization not willing/able to read test cases?
  - estefan 11y ago
    I've never worked somewhere where non-devs have done anything with tests. They've been too busy doing non-developery things.
  - sanderjd 11y ago
    I won't be quite so pessimistic about the possibilities as other people here, but I share their experiences. It seems possible in theory but nearly impossible in practice to walk the tightrope of creating a language convenient enough for non-technical people to read and write without getting frustrated by it, while retaining its programmability and maintainability without driving the developers crazy. It's just a special case of the general problem with tools that aim to be easy for non-programmers to use while doing the same things as programming languages. It's always a leaky abstraction.
- matthewmacleod 11y ago
  They haven't, in my direct experience. I've found it very useful, where there's ambiguity about how a particular feature works, to write a Gherkin spec that describes it. It's easy to understand, and can be agreed upon or even edited by my colleagues who aren't developers, but remain part of a CI process. YMMV, but this remains one of the lazier dismissals of BDD.
- wpietri 11y ago
  But non-developers read specs all the time. The BDD goal is to create readable specs that also work as executable tests.

ryanmarsh 11y ago

"over" not "instead of"

kabouseng 11y ago

Thats perhaps why he says in the interview it's not important to write all the tests out in detail right there and then, but the discussion between the developer, business person and tester is the important part. (paraphrased)

omouse 11y ago

Except that when most teams adopt the SCRUM flavour of Agile, they're dropping much of the processes and tools that help (pair programming, test-driven development, etc.) So yeah, it's important to value individuals and interactions but not at the expense of light-weight processes and tools that help deliver a quality product.

dragonwriter 11y ago

> First value of Agile Manifesto: > "Individuals and interactions over processes and tools" Right. That means processes and tools should serve individuals by supporting their interactions, rather than individuals and their interactions being reformed to fit preconceived processes and tools. That doesn't mean that processes and tools are irrelevant, or that sharing experiences and ideas about how particular processes and tools can serve individuals in their interactions is contrary to Agile. (In terms of promotion of processes and tools, it really has nothing directly to do with whether or even how those things should be promoted: it does have a lot to do with how -- and who on -- teams should evaluate processes and tools that are being promoted, though.)

s73v3r 11y ago

And does not the Agile Manifesto say they still find value on the stuff on the right?