/
Living Requirements using Behavior Living Requirements using Behavior

Living Requirements using Behavior - PowerPoint Presentation

avantspac
avantspac . @avantspac
Follow
342 views
Uploaded On 2020-08-28

Living Requirements using Behavior - PPT Presentation

Driven Development May 8 2015 httpwwwlinkedincominmartybradley BehaviorDriven Development BDD What is it What are the benefits Who participates Rhythm of BDD How does it fit in the agile process ID: 810202

driven behavior cucumber bdd behavior driven bdd cucumber user system development sue gherkin dave check code software email product

Share:

Link:

Embed:

Download Presentation from below link

Download The PPT/PDF document "Living Requirements using Behavior" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Living Requirements using Behavior

Driven Development

May 8, 2015http://www.linkedin.com/in/martybradley

Slide2

Behavior-Driven Development (BDD

)What is it?What are the benefits?Who participates?Rhythm of BDDHow does it fit in the agile process?Gherkin language to create living requirements

How do we define system behavior?BDD Live DemoOutline

Slide3

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?

Slide4

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 DevelopmentSpecification by ExampleStory TestingFunctional Testing

Slide5

Behavior-Driven Development

Living Specification

Shared Understanding Made into Automated Tests

Slide6

Behavior-Driven Development

Living Specification

Shared Understanding Made into Automated Tests

It’s Alive!

It’s ALIVE!

Slide7

Feature

BackgroundScenarioGivenWhenThenAndBut*Scenario OutlineExamples

The Building Blocks to Agile Scrum Software DevelopmentGherkin

Slide8

Consumed by Cucumber

Originally RubyCucubmer-JVM (java)Specflow (.NET)

The Building Blocks to Agile Scrum Software DevelopmentGherkin

Slide9

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 existHelps teams build the right software product, complementing technical practices that ensure that the product is built right

Behavior-Driven Development

Slide10

Seems clear, but is it?

Customer should be prevented from entering invalid credit card informationMuch more definitiveIf 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

Slide11

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 systemSafety NetThe behavioral tests act as a safety net that allows us to make

functional and structural improvements to the code more freely without introducing bugsFirst “User”The tests act as the first “User” of the code. This results in code that is more easily reusableRhythm of BDD

Slide12

Usability

System functionality is more deliberateDeveloper is placed into the paradigm of a user of the systemFewer defects

Live DocumentationLiving specificationsTests describe the behavior of the systemBenefits of BDD

Slide13

Higher Code

QualityTestable code tends to follow better design patternsModularizedFlexibleUnderstandableTestable code tends to have fewer lines

ConfidenceTests cover smaller, incremental slices of the system making it easier to pivot or grow a featureTests act as a safety net covering existing functionalityBenefits of BDD

Slide14

Faster

DeliveryTests allow new features to be added more easily without breaking existing onesMisunderstanding of requirements appear earlier in the development cycle and are more quickly eliminated – less

time debugging.Benefits of BDD

Slide15

Gherkin

defines example Scenarios in a Given-When-Then format to create structure around the behaviors so that they can be automatedGherkin 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 CucumberGherkin 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

Slide16

Feature discussion with PO

Me

LikeyHuh?OUTSIDE-IN INSIDE-OUT

Slide17

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 inboxExample from The Cucumber Book, Matt Wynne & Aslak Hellesoy

This scenario is good but has a lot of detail that makes it hard to read

Slide18

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 inboxLet’s get rid of the incidental details, the password in this case.Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy

Slide19

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 inboxLet’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!

Slide20

David

Gijsbers

, Eliassen Group

Slide21

Iteration 1:

PO creates user story and bulleted acceptance criteriaIteration 2: 3 Amigos groom the story adding Given…When…Then scenariosIteration 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 featureNote: 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

Slide22

Marty Bradley

www.bradasphere.comwww.linkedin.com/in/martybradley

Behavior-Driven DevelopmentA disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior

Slide23

Cucumber-JVM is a native Java implementation of Cucumber

Specflow is a .NET implementation of Cucumberhttps://cukes.info/ - Cucumber mainhttps://cucumber.pro/ - Online collaboration versionhttp://bradasphere.com

/ - My blog containing some BDD videosSome Tools and Helpful Links