TheBDDBooks-Discoverybddbooks.com/samples/discovery-sample.pdfPreface 3 Whyyoushouldlistentous...

The BDD Books - DiscoveryExplore behaviour using examples

Gaacutespaacuter Nagy and Seb Rose

This book is for sale at httpleanpubcombddbooks-discovery

This version was published on 2017-08-08

This is a Leanpub book Leanpub empowers authors and publishers with the LeanPublishing process Lean Publishing is the act of publishing an in-progress ebookusing lightweight tools and many iterations to get reader feedback pivot until youhave the right book and build traction once you do

copy 2017 Gaacutespaacuter Nagy and Seb Rose

Contents

Preface 1Who this book is for 2Why you should listen to us 3Acknowledgements 3How this book series is organised 4What is not in this book 4Online resources 5

Chapter 1 ndash What is BDD 611 ndash The missing link 612 ndash How does BDD work 913 ndash What about testing 1314 ndash A language that is understood by everyone 1515 ndash Living documentation 1616 ndash What is BDD then 1717 ndash What we just learned 19

Chapter 2 ndash Structured conversation 2121 ndash Where is my pizza 2122 ndash A useful meeting 2123 ndash Collecting examples 2324 ndash Example mapping in a nutshell 3225 ndash How to establish structured conversations 3526 ndash What we just learned 39

Chapter 3 ndash What is an example 4031 ndash How hard is concrete 40

CONTENTS

32 ndash Is all that concrete essential 4133 ndash How many examples do we need 4134 ndash Why stop now 4335 ndash Rules vs examples 4436 ndash My example illustrates multiple rules 4637 ndash The bigger picture 4838 ndash What we just learned 49

Chapter 4 ndash Who does what and when 5041 ndash The BDD approach 5042 ndash BDD in Scrum 5643 ndash BDD in LeanKanban 6144 ndash BDD in Distributed Teams 6245 ndash BDD in fixed scope projects 6546 ndash BDD in regulated environments 6747 ndash What we just learned 69

Chapter 5 ndash How to get business involved 7051 ndash Learn from otherrsquos stories 7052 ndash The one where the business is not involved 7153 ndash BDD is for solving problems 7354 ndash But my product owner never reads the scenarios 7955 ndash What we just learned 80

PrefaceWe belong to the second generation of the software industry (we could call ourselvesGeneration Y - there are a lot of similarities) We donrsquot believe in buzzwords or well-named methodologies but we like to try them out to see if they work This bookis about some foundational aspects of Behaviour Driven Development (BDD) Youdonrsquot have to ldquobelieverdquo in BDD for it to work Itrsquos not a question of belief

BDD has been proven to be successful in hundreds of projects around the worldon different platforms in diverse industries and various project sizes The set ofpractices BDD is based on originates from the experience of many people over manyyears working to uncover better ways of delivering software This does not meanunfortunately that every BDD project will be successful There is a learning period(or more accurately a practicing period) for BDD so it will take a couple of monthsbefore you start seeing a return on your investment This is mainly because BDDfocuses on the long-term quality and maintainability of your software

The most visible benefit of BDD is usually the reduction in the number of productionissues Although it is very hard to gather scientific evidence of this fact (because it ishard to find a ldquocontrol projectrdquo) we have seen significantly fewer production issuesin projects that have successfully adopted a BDD approach For a broad review ofoutcomes from a wide variety of teams you canrsquot do better than reading GojkoAdzicrsquos ldquoSpecification By Examplerdquo 1

Another significant benefit is that BDD helps preserve the quality and maintain-ability of the software which keeps the implementation costs of new features undercontrol This is in contrast to many other projects where as the codebase growsthe cost of adding (or modifying) a feature increases exponentially If allowed todeteriorate in this way your project will finally reach the point where it is notpossible to add new features anymore in a cost-efficient way and people will starttalking about a ldquorewriterdquo

1Adzic Gojko Specification by Example How Successful Teams Deliver the Right Software Shelter Island NY Manning2011 Print

Preface 2

Our goal with this book is to ease your way through the learning period avoidingthe mistakes that we made while we were learning

One typical mistake is to see BDD as a tool-thing BDD is primarily about collabo-ration and domain discovery any ldquoBDD toolrdquo can be only useful in supporting thisprocess You have to start by investing in collaborative discussions and the creationof a shared vocabulary Just going after automation (using Cucumber or SpecFlow)does not work

It doesnrsquot

Honest

As we said BDD does not require you to believe in it but it is important to doit at full throttle during the evaluation period You might feel uncomfortable orskeptical when you start doing BDD (like with any other new approach) That isabsolutely fine but donrsquot let the evaluation be hampered by your fears Once youhave decided to evaluate how BDD could work for your team give yourself enoughtime to get comfortable with the approach Try as far as possible to follow ourrecommendations

Yoursquore at the beginning of a brave new world Let us help you to explore that worldand discover the benefits that are waiting

Who this book is for

This book is written for everyone involved in the specification and delivery ofsoftware (including product owners business analysts developers and testers) Thebook starts by explaining the reasons that BDD exists in the first place and describestechniques for getting the most out of collaboration between technical and non-technical team members

Just to re-iterate this book is aimed at everyone involved in the project whether theyare technical or not whether they come from a software background or not

Itrsquos also worth stressing that this book is tool agnostic Whether you use CucumberSpecFlow JBehave Fit FITNESSE RSpec Jasmine Behave or any other BDD toolndash this book will help your team collaborate

Preface 3

Why you should listen to us

Gaacutespaacuter is the creator and main contributor of SpecFlow the most widely usedATDDBDD framework for NET

He is an independent coach trainer and test automation expert focusing on helpingteams implementing BDD and SpecFlow through his company called Spec SolutionsHe has more than 15 years of experience in enterprise software development as heworked as an architect and agile developer coach

He shares useful BDD and test automation related tips on his blog (httpgasparnagycom)and on Twitter (gasparnagy) He edits a monthly newsletter (httpbddaddictcom)about interesting articles videos and news related to BDD SpecFlow and Cucumber

Seb has been a consultant coach designer analyst and developer for over 30 yearsHe has been involved in the full development lifecycle with experience that rangesfrom Architecture to Support from BASIC to Ruby

During his career he has worked for companies large (eg IBM Amazon) and smalland has extensive experience of failed projects Hersquos now a partner in CucumberLimited who help teams adopt and refine their agile practices with a particularfocus on collaboration and automated testing

Hersquos a regular speaker at conferences a contributing author to ldquo97 Things EveryProgrammer Should Knowrdquo (OrsquoReilly) and the lead author of ldquoThe Cucumber forJava Bookrdquo (Pragmatic Programmers)

He blogs at cucumberio and tweets as sebrose

Together Seb and Gaacutespaacuter have over 50 years of software experience

Acknowledgements

This book would not have been possible without the help of our reviewers

bull Garret Burnsbull Darren Cauthonbull Claude Hanhart

Preface 4

bull Dave Hanlonbull Sam Holderbull Alexandra Fungbull Gilbert Liddellbull Viktor Nemesbull Paul Raynerbull Steve Tookebull Andreas Willich

How this book series is organised

This is the first of the BDD Books series that will guide you through the end-to-end adoption of BDD including specific practices needed to successfully drivedevelopment using collabratively authored specifications and living documentation

Once yoursquove implemented the approach we described you can read

bull Formulation (Book 2) express examples using GivenWhenThen2

bull Automation with SpecFlow (Book 3)3

What is not in this book

bull Formulationbull Structuring documentationbull Gherkinbull Toolsbull Automationbull Code2Nagy Gaacutespaacuter and Seb Rose The BDD Books Formulation In preparation httpbddbookscomformulation3Nagy Gaacutespaacuter and Seb Rose The BDD Books Automation with SpecFlow In preparation httpbddbookscomspecflow

Preface 5

Online resources

httpbddbookscom

Gaacutespaacuter Nagy and Seb Rose August 2017

Chapter 2 ndash StructuredconversationIn this chapter we are going to peer into the daily work of a software product team tolearn more about how they use structured conversations to help them discover whatthe expected behaviour of the next feature should be Wersquoll start by describing one oftheir requirement workshops This will introduce concepts that yoursquore not familiarwith but donrsquot worry all your questions will be answered later in the chapter

21 ndash Where is my pizza

The team we will be visiting is developing a pizza delivery management applicationfor a large pizza company The application will allow clients to track the real-timelocation of their order(s) so they have come up with a fun name for the applicationldquoWhere is my pizzardquo Some wag on the team noticed that this abbreviates to WIMPndash ldquoa weak cowardly or ineffectual personrdquo (Merriam-Webster) The rest of the teamstill know that the product will be awesome

There are lots of other exciting features too but for the rest of this book wersquoll beconsidering a clientrsquos ability to modify the delivery address of an order after theorder has been submitted

22 ndash A useful meeting

Itrsquos 9 am on Wednesday morning and the team is assembling in the team roomfor another requirement workshop Therersquos a good turnout today - Patricia (the PO)Dave and Dishita (from Development) Tracey (from Test) and Ian (the new intern)

Chapter 2 ndash Structured conversation 22

Requirement workshopThe team meets regularly (usually several times a week) to discuss the work thattheyrsquoll be undertaking in the next sprint or two The purpose of this meetingis to explore a story understand itrsquos scope and illustrate it unambiguously withconcrete examples While theyrsquore doing this they may discover new details aboutthe story They may also ask questions that no one at the meeting is able to answerright away

What matters most in this meeting is to bring diverse perspectives together so thatthey can learn about what needs to be done and work together more effectivelyIn other organizations similar meetings have been variously called 3 amigosmeeting discovery workshop specification workshop and backlog grooming ndash asalways the name is less important that the purpose

Theyrsquore very comfortable with this meeting format because they meet several timesa week for short focused sessions that often work only on a single user story Theidea came from a blog post by Matt Wynne Introducing Example Mapping27 thatDishita had recently read

Patricia grabs the box of colored index cards and marker pens from the stationerycupboard and puts them in the middle of the table Everyone knows which storyPatricia has been preparing because she sent out an email yesterday Patricia readsout the story that shersquos already written on a yellow index card

In order to fix an incorrect delivery address

As a client

I want to be able to change the delivery address after the order has beenplaced

ldquoThe system will need to be able to check whether itrsquos possible to change the deliveryaddressrdquo says Patricia ldquoWersquoll have to check that the new address is not too far from

27httpscucumberioblog20151208example-mapping-introduction


the current one Andwersquoll need to check the state of the order toordquo ldquoThis will be easyrdquosays Dave and they all smile They have heard this sentence many times beforeldquoWersquoll seerdquo answers Tracey ldquoletrsquos try to come up with a few examplesrdquo And theworkshop begins

Explaining a team discussion in a book is hard because you need to keeptrack of the goals and perspectives of many people with different rolesand backgrounds To make it easier to follow we have chosen the namesof our team members so that their initials describe their role Patricia isthe Product Owner Dave and Dishita are Developers Tracey is a Testerand Ian is an Intern from the University

As we mentioned in Section 16 What is BDD then one typical mistake is tolook at BDD as a tool-thing A similar mistake would be to think of BDD as amechanical process such as filling out a GivenWhenThen template We need allteam members to actively challenge their understanding of the user story by comingup with concrete examples

There are many ways you can organize your team for better collaboration Everyteam and every project is different We are going to focus on a technique calledExample Mapping that is a simple and efficient way to facilitate your requirementworkshops This is one technique for carrying out a structured conversation andit has worked very well for us but you may need to find an alternative that ismore suited to your context Before you do refer to Chapter 4 Who does what andwhen where we will show how requirement workshops can fit into an agile projectfollowing Scrum LeanKanban or even into a fixed scope project with distributedteams

So letrsquos get back to our teamhellip

23 ndash Collecting examples

ldquoLetrsquos start with the happy path where the customer should be allowed to changethe delivery addresshellip and see if itrsquos as lsquoeasyrsquo as Dave thinks it will be What wouldbe a typical example for thisrdquo asks Tracey


ldquoYes this is the case where the order is in preparationrdquo starts Patricia Tracey whovolunteered to facilitate the meeting today takes a green card and writes Order is inpreparation on the top of it

ldquoWhich persona shall we use to describe this examplerdquo asks Patricia and they alllook at the wall where posters of different user types called personas28 are displayedThe team introduced the personas a year ago when Ulla the UX expert joined thecompany

ldquoLetrsquos use Peter He regularly orders pizzas at home and at the office He probablygets the delivery address mixed up from time to timerdquo suggests Dishita

ldquoOK So letrsquos say that Peter is in the office but orders a Margarita pizza for home bymistake The order has been placed and the restaurant starts to prepare it He checkshis emails a few minutes later and realizes hersquos used the wrong address He clickson the tracking link from the email and chooses lsquoChange Addressrsquo on the trackingpage He selects the work address and submits the changes The change is acceptedrdquoexplains Patricia

ldquoWhat do you mean by lsquoa few minutes laterrsquordquo asks Dishita

ldquoThe order has just been received so the pizza isnrsquot ready yetrdquo says Patricia

ldquoAh OK So the pizza might be in the oven but[gaspar ldquoandrdquordquo itrsquos not ready fordelivery ] checks Tracey

ldquoYes thatrsquos rightrdquo replies Patricia

While she is explaining the details they all look at the printed UI wireframes for thenew ldquoupdate addressrdquo page to help follow the example easily Tracey captures theimportant steps on a green card

Order is in preparation

bull Peter orders pizza for home addressbull Order processing started but pizza is not ready yetbull Chooses ldquoChange Addressrdquobull Selects work addressbull Submits change

28httpsenwikipediaorgwikiPersona_(user_experience)


bull rArr change accepted

They are all following Tracey as she captures these steps so that they can verify ifthe details have been captured properly

ldquoIs it lsquonot readyrsquo or lsquoin preparationrsquo that we have to watch forrdquo asks Ian ldquoWe useone in the example title and the other in the second step of the examplerdquo

ldquoThose two states mean essentially the same thingrdquo answers Dave ldquoIf the pizza is inpreparation then itrsquos obviously not readyrdquo

ldquoWe just learnt about state diagrams in our UML module at university Is thatsomething we could use hererdquo asks Ian

Dishita grabs a pen and stands at the whiteboard ldquoWe donrsquot need a full UML statediagram but I think an overview of the states would be useful as well as some of theeventsrdquo It takes a few minutes to come up with a state diagram similar to the onebelow

Figure 6 ndash State diagram of pizza process

ldquoThen why donrsquot we let them change the address up until the delivery person picksup the pizzardquo asks Tracey They all look at Patricia

ldquoThatrsquos a good point Tracey Actually the important turning point is when thedelivery person picks up the order This is when they check the delivery addressand plan the routerdquo concludes Patricia

ldquoOK Irsquoll fix the example cardrdquo says Tracey and changes the card to look like this

Order waiting for pickup

bull Peter orders pizza for home addressbull Pizza prepared and waiting for pickup


bull Chooses ldquoChange Addressrdquobull Selects work addressbull Submits changebull rArr change accepted

ldquoIs everybody happy with thisrdquo Everyone nods so she places the card below thestory card on the desk ldquoWhat rule is this example illustratingrdquo

ldquolsquoAllow address change if not picked up yetrsquordquo replies Patricia and she picks a bluecard writes this rule on it and places it above the green card


Figure 7 ndash First rule in the example map

ldquoWhat kind of other examples can we imagine for this rule Is there a counter-examplerdquo Tracey helps to move the meeting forward

ldquoSure If the order has been already picked up we should respond with a big fat errormessagerdquo Dave replies promptly and smiles ldquoEasyhelliprdquo


Everyone tries to imagine the situationhellip somehow it feels wrong Dishita finallycomes up with an example

ldquoLetrsquos look at our other persona Tim He is a first time buyer so he has to type inthe delivery address What if he makes a small mistake I once mixed up the housenumber in one of my orders and only realized it when I got hungry and checked thenotification mailrdquo

ldquoBut we canrsquot just let them change the address to a completely different location oncethe pizza is already at the doorstep of the original delivery addresshelliprdquo says Patricia

They start a discussion about possible options but the discussion gets stuck ldquoThereare lots of ways we could handle a late change of delivery address but none of themare simple Do we really need to do this nowrdquo asks Dave

ldquoIt looks like we canrsquot solve this now Letrsquos make a red card for it and check thestatistics to see how often this happens and how much extra cost is caused by thissort of mistakerdquo Tracey suggests

They all agree so she takes a red card and summarizes the problem They usethe red cards to track questions or other discussion points that they cannot solveimmediately They place the red cards on the desk so that everyone can see themThis way they can avoid endless discussions about the topic

ldquoCan we come up with a temporary workaround for the problemrdquo asks Tracey onceshe has finished writing down the question

ldquoMaybe we could change the error message to advise the users to call the operatorrdquosuggests Ian

ldquoVery good Letrsquos capture that quickly before we forgetrdquo replies Patricia and theycapture another example and place it under the previous one

Order picked up already

bull Tim orders pizza for home addressbull Pizza prepared and picked up by the delivery personbull Tim chooses ldquoChange Addressrdquobull rArr error message advising Tim to call the operatorbull rArr include phone number in the message


Figure 8 ndash A counter example and a question

They all look at the examples to see how the system will behave in the differentsituations

ldquoTherersquos another onerdquo cries out Dave ldquoWhat if the pizza was picked up while Timwas typing in the new address in the address change screenrdquo

The team realize that this illustrates the need for state verification both when theaddress change screen is opened and also when the change is submitted This means


that even though itrsquos an edge case itrsquos important enough to capture it as a thirdexample of the rule

Order picked up during address change process

bull Tim orders pizza for home addressbull Order is waiting for pickupbull Tim starts changing addressbull Order picked upbull Tim submits changebull rArr change rejected

They cannot come up with any further relevant example so they move on

ldquoIs this what you call lsquoeasyrsquo Daverdquo asks Patricia

ldquoWellhellip at least wersquove learned a lot about the address change processrdquo acknowledgesDave

The team then discuss other business rules like only valid address is acceptedestimated time of arrival is updated or new address should be within restaurantrsquosdelivery range They come up with examples for all these rules and lay them on thedesk

The workshop finishes in about half an hour Tracey takes a photograph of theexample map (Figure 9) and everyone goes back to their desk


Figure 9 ndash The final example map


24 ndash Example mapping in a nutshell

The Example Mapping technique was discoveredinvented by Matt Wynne who reg-ularly facilitates requirement workshops for his customers At one of his workshopshe had a pack of 4-colored index cards with him He used the green cards to captureexamples and grouped them by rules which he wrote on blue cards He discoveredthat arranging these cards as a map helps guide the discussion and gives a good visualoverview of the requirements

Example Mapping is a low-tech method for making conversations about require-ments short and productive as Matt describes in his post Introducing ExampleMapping29

When participating in an Example Mapping workshop we capture different artifactson differently colored index cards or post-it notes

bull Examples are captured on green cards ndash illustrate concrete behaviour of thesystem

bull Rules are written on blue cards ndash these are logical groupings of the examplesusually focusing on a particular condition Many teams call these acceptancecriteria (AC) business rules or simply requirements

bull Questions or assumptions are captured on red cards ndash any topic that wouldblock the discussion Since these are visible to everyone we can avoid re-discussing these (usually frustrating) topics again and again

bull User stories are captured on yellow cards ndashwe usually start discussing a singleuser story but as we are digging into the details we often decide to split thestory into smaller stories and postpone some of them

Sebrsquos story Business rules requirementsacceptance criteriaWhen my teams start discussing a user story what they typically want tounderstand is the scope of the story and how difficult it might be to implement



Examples really help us understand how the story is supposed to behave but wewant them in related groups

These groupings have been called different things by different teams businessrules acceptance criteria requirements Each of the terms comes with its ownbaggage and often hampers communication on the team Instead wersquove startedjust calling them rules - theyrsquore abstract statements that describe a single aspectof behaviour

An added bonus is that when it comes to splitting a story we can often split themsimply by moving some rules (and their associated examples) to a new story

We place the story card on the top row and arrange the rules in a row underneathThe examples belonging to a particular rule are placed below the rule card they relateto We put the red cards to the side of the example map At the end of the discussionthe desk should look like this Figure 9

Gasparrsquos story Rejoining a discussionWe all have been in meetings where a notification on our phone or some otherinterruption distracts our focus Once you fall out of an animated discussion itis very hard to get back into it These kinds of problems can be minimized byestablishing a better meeting culture but they cannot be avoided completely Sowersquod better accept that this might happen and create an infrastructure that helpsthe people get back into the discussion as quickly as possible Having a visual map(or a mindmap) that is visible to everyone makes it easier to see the big pictureand check the details at the same time

The example cards will be used later whenwe come to write our scenarios It does notmatter what format you use to write examples as long as you capture all the detailsthat seemed important in the discussion For example even if you use Cucumberyou should not use GivenWhenThen to write your examples

When we have captured an example we give it a title so that we can refer to it


easily One simple way of coming up with a title is to copy the way that episodes ofthe Friends sitcom were named ldquoThe One Where Rachel Finds Outrdquo The words youput after the ldquoThe One Where helliprdquo happen to be very good titles for our examplesldquoThe One Where the Order has been Picked Up Alreadyldquo

Therersquos no strict order you should collect the examples and the rules in If thestory is simple or well prepared it will probably arrive with an initial set of rules(or acceptance criteria) In this case it makes sense to go through these rules andunderstand their details by creating examples that illustrate each of them

In other situations where the story is more vague it might make sense to come upwith some examples that describe the typical behaviours that will be expected Thenidentify the rules that govern them

No matter how you do it it is practical to nominate a facilitator who keeps themeeting going The facilitator takes care that the discussion is captured on the cardsand that everyone agrees with the form they have been written down The facilitatoris not a special role anyone from the team can do it We recommend you rotate thisrole across all team members

With example mapping you can discuss detailed requirements in a surprisingly shorttime In many cases the details of a user story can be discussed in 20-30 minutesWersquove found this style of workshop can work for teams no matter what flavor ofagile theyrsquore using as we discuss in Chapter 4 Who does what and when Becausethe workshops are short we can run them several times a week

Once the map has been created it is important not to lose this information Someteams take photos and share it with team members Others pin the cards on apinboard in the team room or save it as a mind map

It is easy to learn example mapping Just get the team to read Mattrsquos article and run acouple of practice meetings Yoursquoll also find example mapping workshops being runat meetups or agile conferences

Contents

Preface 1Who this book is for 2Why you should listen to us 3Acknowledgements 3How this book series is organised 4What is not in this book 4Online resources 5

Chapter 1 ndash What is BDD 611 ndash The missing link 612 ndash How does BDD work 913 ndash What about testing 1314 ndash A language that is understood by everyone 1515 ndash Living documentation 1616 ndash What is BDD then 1717 ndash What we just learned 19

Chapter 2 ndash Structured conversation 2121 ndash Where is my pizza 2122 ndash A useful meeting 2123 ndash Collecting examples 2324 ndash Example mapping in a nutshell 3225 ndash How to establish structured conversations 3526 ndash What we just learned 39

Chapter 3 ndash What is an example 4031 ndash How hard is concrete 40

CONTENTS









Preface 2



It doesnrsquot

Honest







Preface 3










Acknowledgements



Preface 4









Preface 5

Online resources

httpbddbookscom














As a client





































































































CONTENTS









Preface 2



It doesnrsquot

Honest







Preface 3










Acknowledgements



Preface 4









Preface 5

Online resources

httpbddbookscom














As a client










































































































Preface 2



It doesnrsquot

Honest







Preface 3










Acknowledgements



Preface 4









Preface 5

Online resources

httpbddbookscom














As a client





































































































Preface 3










Acknowledgements



Preface 4









Preface 5

Online resources

httpbddbookscom














As a client





































































































Preface 4









Preface 5

Online resources

httpbddbookscom














As a client





































































































Preface 5

Online resources

httpbddbookscom














As a client

















































































































As a client





































































































TheBDDBooks-Discoverybddbooks.com/samples/discovery-sample.pdfPreface 3 Whyyoushouldlistentous...

Documents

Transcript of TheBDDBooks-Discoverybddbooks.com/samples/discovery-sample.pdfPreface 3 Whyyoushouldlistentous...