Well, that was quite a week. I feel I've been on a Behaviour Driven Development "INTENSIVE"... but I've come through it unscathed; I now have a deeper appreciation for BDD than ever before. Enjoy the episode!
Really great and clear explanation. Love the way you have carefully edited the video to make it easier to absorb the information without causing any distractions. Nice!
Three years late - but this was exciting to watch! That... or the coffee kicked in. Or was it both? Did order matter? Should I drink coffee then watch?
A question please: When you say that implementation details should be left to the devolpment team, does this include PO or even the PO should left it for dev team? In the same logic of my misunderstanding: does the PO's work consists of systems requirement (How) or it is also a functional specification (What)? Cuz, I see the what and the how as one calling the other, mading loops!
Great question. The point I was trying to make is that avoiding implementation details in (a) functional specs and (b) behavioural tests ... helps to make them more "robust". ( = less likely to change over time.) But we need to those implementation details at some point... and you're right that this should be collaborative: Product Owners, UI Designers, UX designers ( and, ideally, end users) should all get a say. Is that how you see it?
As a state hater I would argue that "verify" (or "ensure") is an "action" and therefore a "behavior". I think "state" is an old skool term that needs to go away. It's too confusing & ambiguous because it is an abstraction and thus refers to one of many (infinite) levels of abstraction. For example, if you see a corpse can you tell me if it is "alive" or "dead"? The answer should depend on the level of abstraction. At a high level of abstraction we would probably say "of course it's dead, it's a corpse". But at a low level, it is actually full of life -- the life that will consume it, and therefore (arguably) very alive. State can only be determined by making an inquiry, (an action) at some particular level of abstraction. And the answer is only relevant to that exact question, at that exact (infinitesimal) moment. It's like the Schrödinger's cat thought experiment (why all the cat harming analogies, I don't know) where observation (an action) collapses around a particular state. Anyway, I like how you've emphasized that the ordering of related state-related observations is pretty much arbitrary; which makes me think that maybe it's because ideally, in theory, they occur at the same (infinitesimal) moment in time.
When Liz Keogh talks about this she offers up that the outcome step could contain the phrase "should", much in the same way that you've suggested using "Verify" - although looking at this I wonder how that would read. Then the account should be debited And the cash should be dispensed And the card should be returned Written that way...they sound like events don't they? Although they could happen in any order and grammatically make sense. I find that the other is actually important at the outcome stage, but to get that order there should be a discussion in the team to define the behaviour they are going to build. I feel conflicted here as I like both.
I'm conflicted too! Quite like the word "should". You've made me wonder whether a change of tense would help: - Then the account should have been debited - And the cash should have been dispensed - And the card should have been returned Order - as you said - is the tricky one. The "card dip case" has me thinking of "pre-conditions" (in any order) ... the Event.... and "post-conditions" (in any order). Of course, there's an aspect of BDD that I conveniently ignored in the video: the requirement that the steps be executable. Executing means "executing them in order"! There will be cases where we need to be specific about the order, in order to play nice with the executing code... although the resulting order is usually a logical one: - Customer exists - Customer is in credit
The tense definitely makes the word "should" fit more easily, but then do make it more dictatorial as opposed to defining a behaviour? This is Liz's example she uses that has the "should" word in: Scenario: A customer returns an item for refund Given Fred has bought a microwave And the Microwave cost £100 When we refund the microwave Then Fred _should_ be refunded £100 The base structure here is (I'm lifting this from her material): Given a context When an event happens Then an outcome _should_ occur The theory behind the _should_ is that it allows for uncertainty. It allows you to question the behaviour - you say something should occur...but should it? Should it be done now, or should it be done later? Maybe it should do something else. Enter: "useful conversation", stage right. This actually leads me to a point you've made in your reply above: "the requirement that the steps be executable." - there's actually no requirement for the scenarios to be executable, they just have to capture the behaviour. Being executable is a requirement for Cucumber, but it's not a requirement for BDD as it was intended. It is, primarily, an analysis tool - the automation side of things really just leverages parts of BDD to make easily readable test scripts.
"The theory behind the should is that it allows for uncertainty." Now I'm LESS happy with the word "should"! Let's back up a bit: Behaviour Driven Development. My interpretation of "BDD" is that we (a) decide/fix/establish the required behaviour, and (b) write the code to produce the required behaviour. Of course discussion is always a good thing. But we can't have "woolly" scenarios: once we're "cutting code", we need certainty. This MUST be true at the beginning; this MUST be true at the end. The words "Acceptance criteria should be executable" appear as a main headline in Dan's original article (dannorth.net/introducing-bdd/). I can't imagine how BDD would work without executable steps.
Hmmmm yes I see what you mean. So for me the "should" phrase is really there to state (there is that word again) the outcome that should happen, rather than prescribing how it will be done. So you have the conversation and agree "yes, it should do this" and then you need to work out the how. After talking to Dan North at a meetup I got confirmation on a suspicion I had about the term "executable" in that article. He meant it in the sense that the team could execute on building functionality to enable the behaviour, as opposed to it being programmatically executable. This last bit is where Matt Wynne steps in with Cucumber - this does actually make the scenario executable as a test, but they aren't intrinsically the same thing. Or maybe they are now, but they weren't when it was created. I think. It's a bit of a minefield. The main thing is that BDD isn't a test automation framework, but you never state that it is, and that makes me happy.
After sleeping on it something else occurred to me which contradicts what I said above - Dan created BDD with Liz Keogh and Chris Matts when they were working with JBehave....so it must have been executable tests (but not in the Cucumber sense).
I see the point to avoid the implementation details but doing so is it not a big risk that there will be gaps in the requirements that the developers will be given too much room for interpretation. So what I am trying to ask is how do one ensure that there are no gaps in the behavioral design allowing for the developers getting it wrong?
"the developers will be given too much room for interpretation" What makes you think that a BA at the start of the project won't have the same problem? How does anyone at the start of the project know what all of the details should be? The reason why big up front design, such as in waterfall, doesn't work is because no one knows what all the details are, or what the best implementation will be. We instead learn these things through the development process, and as such, details should be deferred until the latest possible point. Often this means it'll be the developer who encounters these issues first, but there's no reason why BAs and other team members can't collaborate with the developer as the issue is discovered, and indeed they should.
So basically requirements should never tell the "how." System requirements should define the things the product shall do or qualities the product shall have. In my universe, using a requirement to describe the how, defining the solution.
First thing to say is that it's been a long time since I've seen a specification document of any kind: Agile made them kind of redundant. One of the things that helped me to understand the difference between the "Functional" and the "Systems" docs, is that there could be more than one "Systems" doc: there might be a Systems doc for a Desktop Application, and another for a mobile "App".
Hi Gary. I can see an internal project flowing without the need of any specs doc, just going throught several interactions and molding itself into something good. However, when working for a client who expects quote and timeframe for a feature then I cannot see an alternative apart from writing the doc and a lot of educated guessing. How did/would you approach the conflict of having to "plan everything" ahead vs. doing Agile? I really liked the videos "Agile Estimating - Why bother" but I noticed it is mostly comparing different features as in value/effort, very important once the work is in progress. Now, if you had to estimate the whole system and put a pricetag on it, which approach would you prefer? Maybe your quote will not be approved and any preemptive work could be in vain. Thank you for all your good work!
So how do you deal with the possibility that the card needs to be removed before the cash is dispensed? The developers would need to add another step for the user pulling out the card, otherwise no cash would be dispensed.
You're right; the scenario we've talked about is, I suppose, the "happy path" for getting cash. For every happy path, there are usually several "not so happy" paths.
What the whole card thing means to the state required for this test is more “ensure card verification” than about the order in which it’s taken in or out, and of course the card having been returned to the user at some point in the process is a high-level desirable outcome of it. So I imagine the tests for the specifics of when the card gets inserted and removed would belong in the unit/integration testing realm (since that component is just a gatekeeper for other transactions) and most likely on the E2E testing phase where the specifics of how the interface handles the physical card will be more relevant.
