Upload
walter-riley
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Copyright © 2012 Accenture All rights reserved. 1
Living Requirements using Behavior Driven DevelopmentMay 8, 2015
http://www.linkedin.com/in/martybradley
Copyright© 2014 Accenture All rights reserved. 2
• Behavior-Driven Development (BDD)– What is it?– What are the benefits?– Who participates?
• Rhythm of BDD– How does it fit in the agile process?
• Gherkin language to create living requirements– How do we define system behavior?
• BDD Live Demo
Outline
Copyright© 2014 Accenture All rights reserved. 3
• Behavior-Driven Development (BDD) is a disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior, also known as, acceptance criteria for the feature that is about to implemented
Behavior-Driven DevelopmentWhat is BDD?
Copyright© 2014 Accenture All rights reserved. 4
• Behavior-Driven Development (BDD) is a disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior, also known as, acceptance criteria for the feature that is about to implemented
Behavior-Driven DevelopmentWhat is BDD?
A.K.A.• Acceptance Test Driven Development• Specification by Example• Story Testing• Functional Testing
Copyright© 2014 Accenture All rights reserved. 5
Behavior-Driven Development
SHARED UNDERSTANDING
The biggest challenge in software development is to understand what the customer REALLY needs, in detail.
Behavior-Driven Development (BDD) encourages creating a shared understanding and collaboration by writing simple, scenario-based, single-source, living specifications that business people and IT people can read, easily understand, and quickly agree to that provides clear traceability.
We use a special text syntax called Gherkin to build scenarios…
GIVEN <condition>
WHEN <action>
THEN <result>
AUTOMATED TESTING
The most difficult part of DONEness is to ensure that your story has been fully tested so that it satisfies everything the Product Owner asked for and works when integrated with the rest of the product.
Using a tool called Cucumber, the previously written specifications can actually be turned into executable tests.
Thus, the language of our shared understanding becomes the language of our tests as well.
LIVING SPECIFICATION
Shared Understanding Made into Automated Tests
Copyright© 2014 Accenture All rights reserved. 6
Behavior-Driven Development
SHARED UNDERSTANDING
The biggest challenge in software development is to understand what the customer REALLY needs, in detail.
Behavior-Driven Development (BDD) encourages creating a shared understanding and collaboration by writing simple, scenario-based, single-source, living specifications that business people and IT people can read, easily understand, and quickly agree to that provides clear traceability.
We use a special text syntax called Gherkin to build scenarios…
GIVEN <condition>
WHEN <action>
THEN <result>
AUTOMATED TESTING
The most difficult part of DONEness is to ensure that your story has been fully tested so that it satisfies everything the Product Owner asked for and works when integrated with the rest of the product.
Using a tool called Cucumber, the previously written specifications can actually be turned into executable tests.
Thus, the language of our shared understanding becomes the language of our tests as well.
LIVING SPECIFICATION
Shared Understanding Made into Automated Tests
It’s Alive!
It’s ALIVE!
Copyright © 2012 Accenture All rights reserved. 7
• Feature
• Background
• Scenario
• Given
• When
• Then
• And
• But
• *
• Scenario Outline
• Examples
The Building Blocks to Agile Scrum Software Development
Given (Context or Event)
When (User Action)
Then (Outcome)
Gherkin
Copyright © 2012 Accenture All rights reserved. 8
Consumed by Cucumber
• Originally Ruby
• Cucubmer-JVM (java)
• Specflow (.NET)
The Building Blocks to Agile Scrum Software Development
Given (Context or Event)
When (User Action)
Then (Outcome)
Gherkin
Copyright© 2014 Accenture All rights reserved. 9
• Like Test-Driven Development (TDD) but with Different Scope– Test from the “outside-in”– TDD fails when algorithm doesn’t exist (inside-out)– Executable specification fails because a feature doesn’t
exist– Helps teams build the right software product,
complementing technical practices that ensure that the product is built right
Behavior-Driven Development
Copyright© 2014 Accenture All rights reserved. 10
• Seems clear, but is it?– Customer should be prevented from entering invalid
credit card information
• Much more definitive– If a customer enters a credit card number that isn’t
exactly 16 digits long, when they try to submit the form, it should be redisplayed with an error message advising them of the correct number of digits.
An Example
The Cucumber Book, Matt Wynne & Aslak Hellesoy
Copyright© 2014 Accenture All rights reserved. 11
• System Behavior – The system behavior is defined by a group of
scenarios that let you quickly add slices of functionality to help learn about the feature and it’s affect throughout the system
• Safety Net– The behavioral tests act as a safety net that
allows us to make functional and structural improvements to the code more freely without introducing bugs
• First “User”– The tests act as the first “User” of the code. This
results in code that is more easily reusable
Rhythm of BDD
Copyright© 2014 Accenture All rights reserved. 12
• Usability– System functionality is more
deliberate– Developer is placed into the
paradigm of a user of the system– Fewer defects
• Live Documentation– Living specifications– Tests describe the behavior of the
system
Benefits of BDD
Copyright© 2014 Accenture All rights reserved. 13
• Higher Code Quality– Testable code tends to follow better design
patterns• Modularized• Flexible• Understandable
– Testable code tends to have fewer lines
• Confidence– Tests cover smaller, incremental slices of the
system making it easier to pivot or grow a feature
– Tests act as a safety net covering existing functionality
Benefits of BDD
Copyright© 2014 Accenture All rights reserved. 14
• Faster Delivery– Tests allow new features to be added more easily without
breaking existing ones– Misunderstanding of requirements appear earlier in the
development cycle and are more quickly eliminated – less time debugging.
Benefits of BDD
Copyright© 2014 Accenture All rights reserved. 15
• Gherkin defines example Scenarios in a Given-When-Then format to create structure around the behaviors so that they can be automated
• Gherkin gives us a lightweight structure for documenting examples of the behavior our stakeholders want, in a way that it can be easily understood both by the stakeholders and by Cucumber
• Gherkin only has a few keywords allowing the team to build a domain specific language (DSL) for common use in the system and in conversations to promote a shared understanding
• Gherkin uses user defined tags to organize scenarios – @fast, @overnight, @web
Behavior-Driven DevelopmentLiving Specifications with the Gherkin Language
Copyright© 2014 Accenture All rights reserved. 16
Feature discussion with PO
Me Likey Huh?
OUTSIDE-IN INSIDE-OUT
A Basic Example using Gherkin: Check inbox
Scenario: Check inbox
Given a User "Dave" with password "password”
And a User "Sue" with password "secret"
And an email to "Dave" from "Sue"
When I sign in as "Dave" with password "password"
Then I should see 1 email from "Sue" in my inbox
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy
This scenario is good but has a lot of detail that makes it hard to read
A Basic Example using Gherkin: Check inbox
Scenario: Check inbox
Given a User "Dave"
And a User "Sue"
And an email to "Dave" from "Sue"
When I sign in as "Dave"
Then I should see 1 email from "Sue" in my inbox
Let’s get rid of the incidental details, the password in this case.
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy
A Basic Example using Gherkin: Check inbox
Scenario: Check inbox
Given I have received an email from "Sue"
When I sign in
Then I should see 1 email from "Sue" in my inbox
Let’s remove even more noise. This is very readable and easy to maintain
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy
That’s exactly what I meant!! What a great scenario.
I’m a great Product Owner!
David Gijsbers, Eliassen Group
Copyright© 2014 Accenture All rights reserved. 21
• Iteration 1: PO creates user story and bulleted acceptance criteria
• Iteration 2: 3 Amigos groom the story adding Given…When…Then scenarios
• Iteration 3: Developer & tester work the story using cucumber to generate the automation framework. They use the red-green-refactor cycle to design, develop, and test the feature
Note: Other artifacts can and should be attached to the user story such as, design documents, emails, or anything else that helps clarify the intent of the user story
Lifecycle of a User Story
Copyright© 2014 Accenture All rights reserved. 22
Marty Bradley
www.bradasphere.com
www.linkedin.com/in/martybradley
Behavior-Driven Development
A disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior
Copyright© 2014 Accenture All rights reserved. 23
• Cucumber-JVM is a native Java implementation of Cucumber
• Specflow is a .NET implementation of Cucumber
• https://cukes.info/ - Cucumber main
• https://cucumber.pro/ - Online collaboration version
• http://bradasphere.com/ - My blog containing some BDD videos
Some Tools and Helpful Links