Bdd Liz Keogh
description
Transcript of Bdd Liz Keogh
This is an extract; the full document can be downloaded from
http://www.slideshare.net/lunivore/behavior-driven-development-11754474
1
1
BehaviourDrivenDevelopment
Liz Keogh@lunivore
2
Behaviour-Driven
DevelopmenFeature Injection
Cynefin and Differentiati
onSplitting Stories
3
BDDuses examples
to illustrate behavior
4
An Example of an Example
Given Fred has bought a microwaveAnd the microwave cost £100
When we refund the microwaveThen Fred should be refunded
£100.
5Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
An Example of an Example
Given baby rabbits cost £10When we sell Snowy the Baby Rabbit
Then the customer should be charged £10.
6Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
Examples
Given a contextWhen an event happens
Then an outcome should occur
7
“Given Scenario” – an antipattern
Given Fred puts a microwave in the basket
And the microwave cost £100When Fred buys the microwave
Then he should be charged £100When we refund the microwave
Then Fred should be refunded £100.
8This is actually two scenarios.
The first scenario is concerned with payments. The second scenario is concerned with refunds. The first scenario is setting up the context for the second scenario.
Talking through scenarios like this is absolutely fine. If you capture them, you might want to separate the two scenarios. As we’ll see later when we start looking for different outcomes and more interesting scenarios, once things start getting complicated these scenarios can be hard to maintain.
Usually, if you see this, you’ll find there are either two different concerns in play, or that one of the scenarios is redundant.
Cucumber
Feature: Addition In order to avoid silly mistakes As a math idiot I want to be told the sum of two numbers Scenario: Add two numbers Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then the result should be 120 on the screen
9There are tools available which will take your English-language steps and turn them into real automated regression tests! Cucumber, Cucumber for the JVM, SpecFlow and JBehave are all examples of system-level BDD tools. There are others which run against smaller elements of code or classes, such as RSpec and MSpec, but you don’t have to worry about those unless you’re a developer.
Cucumber
Feature: Addition In order to avoid silly mistakes As a math idiot I want to be told the sum of two numbers Scenario: Add two numbers Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then the result should be 120 on the screen
This is what most peopleassociate with BDD
9There are tools available which will take your English-language steps and turn them into real automated regression tests! Cucumber, Cucumber for the JVM, SpecFlow and JBehave are all examples of system-level BDD tools. There are others which run against smaller elements of code or classes, such as RSpec and MSpec, but you don’t have to worry about those unless you’re a developer.
10
11However, the conversations are the most important bit, so start with those.
11However, the conversations are the most important bit, so start with those.
BDD is about having conversations
11However, the conversations are the most important bit, so start with those.
12Remember that the point of BDD is to create working software. If you find that it’s getting in the way of that, you’re probably focusing too much on the process, and too little on the goal.
BDD should make it easyto create software
12Remember that the point of BDD is to create working software. If you find that it’s getting in the way of that, you’re probably focusing too much on the process, and too little on the goal.
13A lot of teams that use BDD insist on having very clear examples for everything they attempt. As we’ll see later, some things resist well-defined outcomes, especially when they’re very new or innovative. BDD should be a collaboration tool, not a contractual one; it’s about trying to understand what the business want, not making it “their fault” if we end up producing the wrong thing.
A scenario is an idea, not a promise
13A lot of teams that use BDD insist on having very clear examples for everything they attempt. As we’ll see later, some things resist well-defined outcomes, especially when they’re very new or innovative. BDD should be a collaboration tool, not a contractual one; it’s about trying to understand what the business want, not making it “their fault” if we end up producing the wrong thing.
14We should always be looking for what we want next, or what we’ve got wrong, or what we could do differently.
A scenario is an idea, not a promise
14We should always be looking for what we want next, or what we’ve got wrong, or what we could do differently.
Having conversations
15
Having conversationsis more important thancapturing conversations
15
Having conversationsis more important thancapturing conversations
is more important thanautomating conversations
15
Exercise
Think of thebest conversations
you’ve had.What made them awesome?
16
Entertaining
Learning
Questions
ChallengeDifferentopinions
Uncertainty
Shared context
Newpeople
IdeasSupportCertainty
17These were some of the ideas I came up with. Others might be relevance, unexpectedness and surprise, being funny… these can all come into your scenarios, too. Make them memorable.
How many people said, “These are things I value in conversations…” and started listing them, and how many shared stories of conversations they’d had? We are “homo narrans”; we learn best from stories.
A storybecause devs love
empty lists
18When I spoke to the Head of Client Management, I said, “Given a client manager has some clients, when he logs in, then he should see his clients. Given he has no clients, what should he see when he logs in then?” I was thinking about the case when they had an empty list of clients.
But the Head of Client Management said, “If you’re a client manager and you have no clients, I’m about to fire you! Get on the phone and get some clients!”
From my dev perspective, I was worried about empty lists. From his perspective, an empty list was a business about to be bankrupted. So that taught me quite a bit about the domain!
Boring!Given Fred bought a microwave
And has receipt number 1857123And receipt 1857123 lists it at £100
When we scan the receiptThen the screen should show the list of
itemsWhen we select the microwave
And we refund itAnd scan Fred’s credit card
Then Fred should be refunded £100.
19If you find yourself talking in ways that seem unnatural, you’re probably thinking too hard about the solution, rather than the problem. This is a very solution-focused scenario. Also try and avoid any reference to the UI, as that’s part of the solution space too.
Examples
Given a contextWhen an event happens
Then an outcome should occur
20“Should” is a magic word that allows us to question whether an example really should happen.
Should it?
21Should it happen now, or should it happen later? Or at all? Should it always happen? Is there a context in which it doesn’t happen?
Make sure you get it right
22In Waterfall, we make sure we get it right because it’s expensive to change later. In Agile, we assume we got it wrong to change as quickly as we can. Given I’ve worked on projects which had a years’ worth of analysis and still didn’t get it right, it makes sense to assume that we got it wrong, especially given how little we worked on the requirements! So feedback and keeping things easy to change is essential.
Make sure you get it rightAssume you got it wrong
22In Waterfall, we make sure we get it right because it’s expensive to change later. In Agile, we assume we got it wrong to change as quickly as we can. Given I’ve worked on projects which had a years’ worth of analysis and still didn’t get it right, it makes sense to assume that we got it wrong, especially given how little we worked on the requirements! So feedback and keeping things easy to change is essential.
Is there a context in whichthis event will createa different outcome?
23This is the pattern I call “context questioning”.
Examples
Given Fred has bought a microwaveAnd the microwave cost £100
And the microwave was on 10% discount
When we refund the microwaveThen Fred should be refunded £90.
24
Examples
Given Fluffy the baby rabbitis 1 ½ months old
When we try to sell FluffyThen we should be told he’s too
young
25
Is this the only outcomethat matters?
If we could achieve it with pixies, would it be enough?
26This is the pattern I call “outcome questioning”.
A pixie is a small person. If you’ve ever read Terry Pratchett’s “Discworld” novels, you’ll know that when you take a photo in the Discworld, a little goblin or person inside the camera quickly paints the picture for you! I sometimes find it helpful to imagine that there are similar tiny people inside all of our machines, painting on the inside of our computer monitors and sitting crouched in our cash machines.
As a developer, I love writing code. I can’t help it! So as soon as you start talking to me about the problem, I start writing software in my head – moving to the solution space. If I can imagine that pixies are going to do the job instead, it makes it much easier to think about, and question, what the pixies should do, instead of the implementation of it.
Examples
Given Fred has bought a microwaveAnd the microwave cost £100
When we refund the microwaveThen the microwave should be
added to the stock count.
27I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
Examples
Given each rabbit eats an average of
20g of carrots a dayWhen we sell 10 rabbitsAnd 5 rabbits are born
Then our order for carrots shouldgo down by 700g a week
28I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
Same scenario?
Then Fred should be refunded £100
Then the microwave should be added
to the stock count
29These are two separate aspects of behaviour, so you probably want to put them in different scenarios. It’s OK to get this wrong, though, and if someone comes up with an interesting outcome, it’s probably better just to capture it quickly. Remember that it’s more important to keep the conversation fluid and allow ideas to flow than to do it “right”.
Same scenario?
Then I should be given £20
And £20 should be debitedfrom my account
30These are not two separate aspects of behaviour. This is one transaction. It needs to happen in the same scenario, because we can’t ship one without the other. That just isn’t useful.
Then my eyes glaze over…When we select “baby rabbit” from the list of petsAnd the customer declines all special offersAnd we want a VAT receiptAnd we select payment by credit cardAnd the customer is presentThen the receipt should say £10And we should have £10 more takingsAnd the number of rabbits in stock should decreaseAnd …
31If you have a scenario that gets like this, you might want to start splitting it up. Nobody is really interested in talking about all these outcomes at once.
Then my eyes glaze over moreWhen we click the “Pets” drop-downAnd we select “baby rabbits”And we click “No”And we check “VAT receipt”And we click “Pay”And we select “Credit Card”And we click “Yes”And …
32This is even worse. Focusing on the GUI ties you to a particular GUI. If you ever have a search box instead of a drop down, this is going to be a maintenance nightmare. I can tell from this scenario that whoever wrote it hasn’t actually had any conversations with anyone!
Exercise
Come up with two scenarios
withtwo outcomes
from your own work,one of which can be splitand one of which can’t.
(They don’t have to be about software)
33Transactional outcomes often have two different outcomes for two different stakeholders.
Imagine paying someone money online. You want to have some kind of confirmation, don’t you? Would it be OK to pay the other person without getting that confirmation? Or get the confirmation when you haven’t paid? These kind of outcomes have to be shipped together.
And you can keep going…
Given Fred has bought a microwaveAnd the microwave cost £100And the microwave is faulty
When we refund the microwaveThen a fault ticket should be
printed.
34As you talk through different scenarios, you’ll find new requirements. If you’re after an MVP (Minimum Viable Product) – the smallest thing that you could usefully ship and make money from or learn from – then think about whether you really *need* to ship the scenario or not. For instance, you could usefully deploy a cash machine which doesn’t work for people who have overdrafts, and it will still cut the bank queues down.
Exercise
What other benefitscan you think of
that might come fromtalking through
different scenarios?
35Another benefit we talked about is that developers start using the language in the code, so that they can talk more easily to the business and their code is easier to read and more maintainable.
Acceptance criteria vs. Scenarios
Given Fred has bought a microwaveAnd the microwave cost £100
And the microwave was on 10% discount
When we refund the microwaveThen Fred should be refunded £90.
36This is a scenario with specific data. We can’t tell from this what the actual rules are. It’s an exemplar; an example made to *illustrate* behaviour. It’s not really a description of the behaviour.
Acceptance criteria vs. Scenarios
Given an item was soldwith a discount
When a customer gets a refundThen he should only be refunded
the discounted price.
37This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It’s a description of the behaviour which is true for all the contexts mentioned… unless you can think of another context which changes this!
Acceptance criteria vs. Scenarios
Items should be refundedat the price at which they were
sold.
38We don’t need to phrase things as GWT if the scenarios can easily be derived.
Acceptance criteria vs. Scenarios
Given Fluffy the baby rabbitis 1 ½ months old
When we try to sellFluffy the baby rabbit
Then we should be toldthat he’s too young
39
Acceptance criteria vs. Scenarios
Given a pet is belowrecommended selling age
When we try to sellthat pet
Then we should be toldthat the pet is too young
40This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It gives us the rules for all pets, not just rabbits. If someone started with this, we could ask them, “Can you give us an example?” Using concrete examples with real baby rabbits entices our imaginations in a way that abstractions don’t. I bet you even have an image in your head of what colour Fluffy is too!
Acceptance criteria vs. Scenarios
We shouldn’t be ableto sell pets
younger than therecommended
selling age
41There are multiple ways of phrasing acceptance criteria. If we can’t imagine scenarios from the criteria then we can create some to help illustrate the behaviour. It’s perfectly OK to capture obvious scenarios in this form – you don’t have to write *everything* down! The trick with BDD is to get to the things we’re discovering which are new as quickly as possible.
ExerciseCan you derive some scenariosfrom these acceptance criteria?
The user should be able to add and remove bold, italics and underlines.
When browsing an item, users should be able to see what other users who browsed the item
bought.
Pets shouldn’t be listed for saleuntil they’re old enough.
42When we talked through the examples, a lot of them read as acceptance criteria. I ask concrete questions like, “What’s his name? Can you think of an example of text that Fred might want to make bold? Can you think of an example of that?” Even just repeating “Can you give me an example of that?” usually helps reduce abstract acceptance criteria to something that really fires the imagination.
Feature Injection
43When Chris Matts taught me Feature Injection, he explained it in much the way I explained it to you. However, he has some different emphasis that’s worth reading, and is strongly aligned with the later sections on differentiation. Here’s his article on it: http://www.infoq.com/articles/feature-injection-success
Vision
Makes moneySaves money
Protects moneyPrimaryStake-holder
44There’s always someone who cares about the project; who has fought to get the budget for it, or perhaps funded it directly. This is the project owner. Everyone else is a proxy.
Goal
Neededto go liveIncidental
Stake-holder
45As well as the project owner, there will be several other stakeholders whose needs have to be met in order to go live. Often these are “gatekeeping” stakeholders – security, support, audit, legal, etc. You can engage these stakeholders before-hand and get some tests for their goals.
Tom Gilb is pretty big on quantifying goals. Here’s a good article on it: http://projectmanagement.atwork-network.com/2012/03/20/qa-tom-gilb-on-quantifying-project-objectives/
You may also find my blog post on identifying stakeholders across the whole value stream useful: http://leansystemssociety.org/value-streams-are-made-of-people/
Capability
Userscan achievea businessoutcome
Business Analyst
46To deliver the stakeholder goals, we look to see what capabilities are needed. A capability is “the capability to do something”. For instance:
- The capability to trade copper- The capability to book a holiday- The capability to comment on an article- The capability to calculate counterparty exposure
etc. We can also find smaller capabilities within larger ones if we need to. A 1-year, enterprise-wide project in a trading company we used this in had about 30 capabilities for the whole project, some of which were – in a rough estimate – 10 times smaller than others. Capabilities may also be principles that extend across the whole project (security, performance, etc.) They *all* have stakeholders, even the ones we refer to as “non-functional” or “technical”. Working out who the stakeholder for a requirement is, and phrasing it in terms of the business benefit, can really help to narrow down what actually *needs* to be delivered.
Feature
User interfacecomponent
which enablesa capability
UIDesigner
47Some capabilities will be delivered in the form of software features. There may be one or many features related to a capability. For instance, in order to comment on an article we may need user registration, comment reporting (in case of spam, vulgarity or libel), and the comment box itself.
The features that we choose to implement may change frequently during a project, especially if the capabilities we’re delivering are new. Capabilities don’t change often, though, so one trick is to find the newest capabilities, and work out a way to get feedback on those quickly!
More on that in the differentiation / Cynefin section.
Story
A slice througha featureto enable
faster feedback
Often adeveloper
48The reason we split features into stories is to get feedback and trust. Showing that you’ve delivered *something* that the stakeholders can see and play with is usually more valuable than trying to get a whole “complete vertical slice”. If there’s a way to show progress or get feedback more quickly, do that. Why code an entire slice if you can throw something smaller away?
Scenario
An exampleof how the system
might behavefrom a userperspective
Dev, tester,analyst
49Scenarios can be used to help discover the scope of features and capabilities, and to split features into stories. If we can’t think of an example in which a capability or feature proves its value to the business, maybe it won’t…
Code
Ideas turning intorealityDeveloper
50And finally, we get to code.
Vision Goal Capability Feature Story Scenario Code
51And later on in this talk, I show why this doesn’t actually work as neatly as this diagram shows But it’s a useful model to bear in mind for the moment.
Vis Go Ca Fea Sto Sce CoCa
pabi
lit
52We focus on the capability wherever possible because it gives us options for changing the lower-level steps beneath. The features we use to deliver a stakeholders’ goals often change, but the capabilities the business needs to meet those goals rarely do.
Vis Go Ca Fea Sto Sce Co
Scen
ario
53We focus on scenarios in BDD because it’s the place where the technical, problem-solving developers and the non-technical business analysts and problem-finding testers meet.
Exercise
Who are your stakeholders?
54Who are the stakeholders for your project?
Are there any which are missing? Are there capabilities that are simply delivered as an industry standard? Do you actually need them?
Examples can help youdiscover
things early
55
Is there a stakeholder for whomthis application will not meet their goal?
56Remember the “context questioning” question? (Do you?)
This is what it looks like when we apply it at the stakeholder level.
Are all of the stakeholder’s goalsmet by this?
If we could achieve it with pixies, would it be enough?
57This is what outcome questioning looks like (do you remember that?)
We can also do this for the other levels. Is there some context in which this feature won’t be usable? Is there some market context in which we won’t make money with this?
Traditional
Developers Testers
58Traditionally, we give up our choices about what the project will do quite early on, well before the testers get involved! Implementation is a commitment.
Testers know how to break our code before we even get a chance to code it, but we don’t always ask them *how* they’ll break our code. We just go ahead and code, and they use their evil, evil deliberate discovery skills and “hand it back to us in tatters”, as Dan North said.
Here’s Dan’s blog post on Deliberate Discovery: http://dannorth.net/2010/08/30/introducing-deliberate-discovery/
Traditional
Developers Testers
Deliberate Discovery skills
58Traditionally, we give up our choices about what the project will do quite early on, well before the testers get involved! Implementation is a commitment.
Testers know how to break our code before we even get a chance to code it, but we don’t always ask them *how* they’ll break our code. We just go ahead and code, and they use their evil, evil deliberate discovery skills and “hand it back to us in tatters”, as Dan North said.
Here’s Dan’s blog post on Deliberate Discovery: http://dannorth.net/2010/08/30/introducing-deliberate-discovery/
Traditional
Rework
Developers Testers
Deliberate Discovery skills
58Traditionally, we give up our choices about what the project will do quite early on, well before the testers get involved! Implementation is a commitment.
Testers know how to break our code before we even get a chance to code it, but we don’t always ask them *how* they’ll break our code. We just go ahead and code, and they use their evil, evil deliberate discovery skills and “hand it back to us in tatters”, as Dan North said.
Here’s Dan’s blog post on Deliberate Discovery: http://dannorth.net/2010/08/30/introducing-deliberate-discovery/
BDD
Developers Testers
59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”
They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.
BDD
Developers TestersTesters
59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”
They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.
BDD
Developers Testers
Deliberate Discovery skills
Testers
59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”
They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.
BDD
Less Rework
Developers Testers
Deliberate Discovery skills
Testers
59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”
They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.
1 2 4 5
60Here’s how evil testers are. A dev once asked me, “Why do we need testers, if we’re doing automated testing and having conversations around scenarios?” So I wrote this on a napkin. “What’s in the middle?” I asked.
1 2 3 4 5
61“It’s a 3,” he said.
“Put your tester hat on. What’s in the middle now?”
1 2 ? 4 5
62“I don’t know,” he said. “I mean, it might be a 3. But if I’m a tester, I’ll ask.”
“That’s why we need testers. Of course it’s a 3, but a tester thinks about what really ought to be there, and we devs just fill in the gaps.”
Then I showed it to a *real* tester.
1 2 : 4 5
63“Might not be a 3,” the real tester said.
Evil. Evil! And very, very, valuable.
Real Options
64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.
Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.
Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.
Automation is also a commitment!
BDD, done well, helps us find the right balance between conversation and prototype.
Real Options
Options have value.
64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.
Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.
Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.
Automation is also a commitment!
BDD, done well, helps us find the right balance between conversation and prototype.
Real Options
Options have value.
64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.
Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.
Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.
Automation is also a commitment!
BDD, done well, helps us find the right balance between conversation and prototype.
Real Options
Options have value.
Options expire.
64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.
Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.
Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.
Automation is also a commitment!
BDD, done well, helps us find the right balance between conversation and prototype.
Real Options
Options have value.
Options expire.
64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.
Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.
Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.
Automation is also a commitment!
BDD, done well, helps us find the right balance between conversation and prototype.
Real Options
Options have value.
Options expire.
Never commit earlyunless you know why.
64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.
Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.
Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.
Automation is also a commitment!
BDD, done well, helps us find the right balance between conversation and prototype.
Business Analyst
Developer Tester
65If you don’t have actual testers, get someone to play that role. Someone who *isn’t* a dev. Us devs are very good at abstraction, and will start solving a problem before we see the whole problem. I don’t believe that an awesome dev can also be an awesome tester, or vice-versa.