Business Driven Development is a development methodology based on communication between the business customers, the developers, and the testers. BDD encompasses many of the same practices as Specification by Example, Acceptance Test Driven Development (ATDD), Example-Driven Development (EDD), and Story Test-Driven Development (SDD). All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language

1. Business Driven Development
Benoy John
Twin Cities Code Camp
#tccc20
April 16th 2016

2. About me
• Benoy John
• Senior Software Consultant with QCI
• 16 years of software development, architecture and design experience
• Experienced agile development coach on pragmatic development practices and processes
• Certified Scrum Master
• Togaf 9 Certified
• Passionate about TDD,BDD and DDD

3. Agenda
• Why BDD?
• What is Business Driven Development?
• How to incorporate it into your process?
• Tools and Techniques
This talk is not about testing?

4. Why? What's the problem we are trying to solve?
Sometimes our best is simply not enough…
We have to do what is required.
~ Sir Winston Churchil

5. Goals
• Make sure you are building the right system?
• Reduce the unknowns as much as possible
• Make sure you understand the requirement before even implementing
• Share understanding between the customer/product owner and the development team
(Developer, Tester, Business Analyst)
• Learn the domain so as to provide value
• Make sure Quality is built in and not after the fact
• Make sure system is built with a flexible design.
• Make sure the system is easy to understand and maintain for the developers
• Make sure you have a predictable and executable documentation
• Make sure you are providing value to the customer and meet your organization goals

6. TraditionalProblem
Requirements
Use Cases
Analysis
Design
Modelling
UML
Layers
Tools
Solution
Coding

7. Agile

8. Desirements to Requirements
• Its very hard to get the requirements right?
• Customers usually know what they want not what they need
• They come to know of what they need only when they start using the software
• When building software too much emphasis on the solution domain
• Requirements have implication on design
• More code leads to bad design
• Hard to maintain
• Hard to extend
• Effects usability

9. BDD in a nutshell
• Short Definition
• “Behavior-driven development is about implementing an
application by describing its behavior from the perspective of its
stakeholders” – Dan North

10. BDD is based on
• User stories
• eXtreme Programming (XP)
• Test Driven Development
• Acceptance Driven Test Planning
• Continuous Integration (Automation)
• Domain-Driven Design

11. Multiple-Stakeholder
• Multiple stakeholders should define an application’s behavior
• Each stakeholder represents one or more business domains
• Each domain uses a particular jargon or domain language

12. The team writes the story
• Stake holders describe features and outcomes in the 1st draft
• All work together to complete the story
• Express interactions between domain objects as well defined and verifiable
behaviors
• Blend terms from multiple domains to create a ubiquitous language used by
the team to write the story.
• Leverage expertise within the team
• QA identifies testable contexts. Dev estimates the scope
• The 3 Amigos

13. The BDD/Acceptance Test Driven Development (ATDD) Cycle

14. Brian Marick’s Testing Quadrants
Functional Tests
User Story Tests
Prototypes
Simulations
Exploratory Testing
Usability Testing
User Acceptance
Testing
Alpha/Beta
Developer Tests
Unit Test
Component Tests
Performance & Load
Testing
Security
Tests
CritiqueProduct
Tools
ManualManual
Automated
Supportingtheteam
Business Facing
Technology Facing
Quality after the
fact
Quality Built-In
Automated
& Manual

15. Testing Pyramid
GUI
Acceptance
Tests
Unit Tests
UI Scripting
At least one per requirement
At least one per class or module

16. Application layering

17. TDD at each layer

18. Behavior tests cross layers
• Are full integration tests
• At UI level
• Or just below the skin
• Are readable by humans and machines
• Evolve with requirements
• Ideally, stand in place of requirement
documents

19. Behavior tests cross layers
• Are full integration tests
• At UI level
• Or just below the skin
• Are readable by humans and machines
• Evolve with requirements
• Ideally, stand in place of requirement
documents

20. How do we express the desirements
Title (Brief description of the story)
User story represents a place holder for a conversation
• As a <Persona/Role>
• I want <Feature/Behaviour>
• So that <Business Benefit>
Acceptance Criteria
Scenario:Title
• Given <Context>
• When <Action>
• Then <Result>
• And <Another outcome>
Describe as a user story
Use Ubiquitous language
Must be testable
Should fit in a sprint
Describes outcome of events
The event describes the feature
Not always simple
Minimize domain mixing

21. Scenarios work at many levels
UI Behavior
Business Domain Concepts
Input Validation
Services
Class Behavior
Repositories
Customer
Developer
Given Customer returns product
Given a button in clicked
Given customer enters date of birth future date
Given customer credit card has been charged
Given customer name is null
Given customer record exist in database

22. Example : Refunds
As a <Persona/Role>
I want <Feature/Behavior>
So that <Business Benefit>
As a store owner
I want to process the refund and capture that information
So that I can refund money back to the customer for a purchase return

23. Example
Scenario: Customer returns an purchased item
Given Customer has bought a item
And the item cost $500
When we refund the item
Then Customer should be refunded $500

24. Write conditions like a story
Scenario: Customer returns a purchased item
Given Fred has bought a Ipad
And the Ipad cost $500
When we refund the Ipad
Then Fred should be refunded $500

25. Developer : How do we know about the purchase
Scenario: Customer returns an Ipad and has purchase receipt
Given Fred has bought a Ipad
And the Ipad cost $500
And he has the purchase receipt
When we refund the Ipad
Then Fred should be refunded $500

26. Developer: Any conditions for return?
Scenario: Customer returns an unused and undamaged Ipad and has purchase receipt
Given Fred has bought a Ipad
And the Ipad cost $500
And he has the purchase receipt
And it is in an unused state and not damaged
When we refund the Ipad
Then Fred should be refunded $500

27. Business Analyst: Oh and he has to return within 30 days
Scenario: Customer returns an unused and undamaged Ipad within
30 days and has purchase receipt
Given Fred has bought a Ipad
And the Ipad cost $500
And he has the purchase receipt
And it is in an unused state and not damaged
And the Ipad is returned within 30 days
When we refund the Ipad
Then Fred should be refunded $500

28. Tester: What if it is loyal customer?
Scenario: A loyal Customer returns an unused and undamaged Ipad
within 60 days and has purchase receipt
Given Fred has bought a Ipad
And Fred is a loyal customer
And the Ipad cost $500
And he has the purchase receipt
And it is in an unused state and not damaged
And the Ipad is returned within 60 days
When we refund the Ipad
Then Fred should be refunded $500

29. Developer: for a credit card payment what do we do?
Scenario: A loyal Customer returns an unused and undamaged Ipad within
60 days and has purchase receipt charged through a credit card
Given Fred has bought a Ipad
And Fred is a loyal customer
And the Ipad cost $500
And Fred used a credit card to purchase the Ipad
And he has the purchase receipt
And it is in an unused state and not damaged
And the Ipad is returned within 60 days
When we refund the Ipad
Then Fred should be refunded $500 to his credit card

30. Tester: What if the customer bought item at a discount?
Scenario: Items should be refunded at the price at which they were sold
Given Fred has bought a Ipad
And Fred is a loyal customer
And the Ipad cost $500
And Fred got a discount of $100
And Fred used a credit card to purchase the Ipad
And he has the purchase receipt
And it is in an unused state and not damaged
And the Ipad is returned within 60 days
When we refund the Ipad
Then Fred should be refunded $400 to his credit card

31. Business Analyst: And we need to update the
inventory system as well once refund is processed
Scenario: Items returned should update the inventory
Given Fred has bought a Ipad
And Fred is a loyal customer
And the Ipad cost $500
And Fred got a discount of $100
And Fred used a credit card to purchase the Ipad
And he has the purchase receipt
And it is in an unused state and not damaged
And the Ipad is returned within 60 days
When we refund the Ipad
Then Fred should be refunded $400 to his credit card
Then Inventory system should be updated with the return item

32. Another story
Scenario: Items returned should update the inventory
Given an Ipad has been returned to the store
When the return has been processed successfully
Then the inventory system should be updated with the returned item

33. Requirements from Desirements
• Executable Specifications prove that software works
• Documents cant prove software work
• Advantages of Executable specification
• Meaningful to all parties
• Demonstrates that requirement is met without ambiguity
• Drive out a testable design
• Simple

34. ATDD Cycle of development

35. ATDD Cycle of development

36. Tools for writing Business scenarios
• SpecFlow
• Fitnesse
• Notepad
• Many other commercial tools available

37. What is Cucumber/Gherkin?
• Cucumber is a tool that executes plain-text functional descriptions as
automated tests.
• The language that Cucumber understands is called Gherkin.
• Business readable domain specific language
• Represents tests in natural language, not code
• Keywords (Feature, Scenario)
• A model for software requirements
• Gherkin documents are stored in regular text files with a .feature file
extension
• 40 + languages
• Purposes
• Feature Documentation
• Automated Test Harness
Acceptance Criteria
Description of Story

38. SpecFlow
• Open source tool for “bridging the communication gap between
domain experts and developers”
• Non Technical people can write acceptance tests for a system
• Enables acceptance test to be automated and executed against
the system
• www.specflow.org

39. SpecFlow Structure
V
Feature File
ScenarioScenario Scenario
Step
Test Code
Testing Framework
VisualStudio
Step Step Step Step

40. The BDD Process
• Assign 10% (or appropriate) of time in the current sprint to groom stories for the next sprint
• In Grooming we flush out the details of the story with examples
• Identify what the feature is about
• Identify scenarios for the feature
• If the scope of the story based on scenarios changes the story is further Brocken down
• Identify if all the scenarios cover what makes the story done.
• The story is marked as groomed and ready to be pulled at planning
• In planning the story is pulled in and tasked
• During sprint the teams collaborate over the scenarios and start implementing each scenario one at a
time, either in feature/TDD.
• Developer runs all existing tests and promotes code.
• Testers use the scenarios to create test scripts and execute test cases when scenario is done.
• At the end of the sprint the product owner verifies if all the scenarios are covered that the business
cares and call the story done or not done
• Everybody is happy and go for a Team lunch

46. TDD/BDD
• TDD is about writing the CODE RIGHT (classes, components)
• BDD/ATDD is about writing the RIGHT CODE (Functionality)
• Drive out ambiguity and clarify expectations
• Acceptance tests define scope
• Make progress visible
• Leverage, Efficiency and Executable specifications

47. Benefits of BDD for the PO/Business Analyst
• Developers will have a better understanding of the specifications that you write
• You will be sure that developers and testers understand the specification
correctly
• You will be sure that they do not skip parts of the specification
• You can track development progress easily
• You can easily identify conflicts in business rules and requirements caused by
later change requests
• You will save time on acceptance and smoke testing

48. Benefits of BDD for the developer
• Most functional gaps and inconsistencies in the requirements and specifications
will be flushed out before the development starts
• You will be sure that business analysts actually understand special cases that you
want to discuss with them
• You will have automated tests as targets to help you focus the development
• It will be easier to share, hand over and take over code
• You’ll have a safety net for refactoring
• Makes your code cleaner

49. Benefits of BDD for the Tester
• You can influence the development process and stop developers from making the same
mistakes over and over
• You will have a much better understanding of the domain
• You’ll delegate a lot of dull work to developers, who will collaborate with you on automating the
verifications
• You can build in quality from the start by raising concerns about possible problems before the
development starts
• You’ll be able to focus less on regression
• You will be able to build better relationships with developers and business people and have
better collaboration
• You’ll spend less time doing dull work, and more time exploring “real” bugs and testing non-
functional aspects (e.g. performance, usability, etc)

50. Summary of what is BDD?
• Validate that the right system is built
• Business/User/Customer point of view
• Non Technical format
• Pass or Fail affair
• Document what the system should do
• Becomes living documentation when automated
• Usually executes through a vertical slice of the system
• Share team understanding if collaboratively built
• Defines Done

51. Final Thoughts
• Focus on the conversation and collaboration
• Involve domain experts and customer in collaboration
• Sharing test results is key to discussion
• There are many supporting tools to help
• Use tools appropriately for value and not as best practice
• Ensure test results
• Are always available
• Make sense to your customer

52. Tips on implementing BDD
• Its about collaboration – regression tests fall out at the other end. They
are by-products of those activities. Testing isn’t the activity itself.
• You need ubiquitous language
• Cucumber /Fitnnesse etc. are collaboration tool s that aims to bring a
common understanding to software teams – across roles.
• We still need testers. Testing is not only about checking, it is also about
exploring
• Automation is development – needs development skills
• Team owns the scenario (Business/Dev/Tester)
• Put tests where there is more risk
• Don’t argue over what's the diff between ATDD,SDD,TDD,BDD etc

53. BDD is about collaboration
• Having conversations
• is more important than capturing conversations
• is more important than automating conversations

54. BDD is not for everyone and certainly not for all
projects
1) You will be working on a complex project that will be invested in over time
2) An iterative development process
3) Access to stakeholders and end users with a strong feedback loop
4) Solid design principles required for refactoring (code and BDD tests)
5) Sharp design sense
6) A focused, motivated and experienced team
You need disciplined developers who are willing to work with domain experts and
understand the business rather than worry how they can wedge in the latest
angular framework/tools into a project

55. Questions

56. Contact Me
• benoy.john@gmail.com
• Twitter: @benoyjohnv
• http://valayathil.blogspot.com/