Embed Size (px)
Citation preview
Business Driven DevelopmentBenoy John
Twin Cities Code Camp#tccc20
April 16th 2016
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
Agenda
• Why BDD?• What is Business Driven Development?• How to incorporate it into your process?• Tools and Techniques
This talk is not about testing?
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
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
Traditional Pr
oble
m
RequirementsUse CasesAnalysis
Desig
n
ModellingUMLLayersTools
Solu
tion
Coding
Agile
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
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
BDD is based on
• User stories• eXtreme Programming (XP)
• Test Driven Development• Acceptance Driven Test Planning• Continuous Integration (Automation)
• Domain-Driven Design
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
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
The BDD/Acceptance Test Driven Development (ATDD) Cycle
Brian Marick’s Testing Quadrants
Functional TestsUser Story Tests
PrototypesSimulations
Exploratory TestingUsability TestingUser Acceptance
TestingAlpha/Beta
Developer TestsUnit Test
Component Tests
Performance & Load TestingSecurity
Tests
Critique Product
Tools
ManualManual
Automated
Supp
ortin
g th
e te
am
Business Facing
Technology Facing
Quality after the fact
Quality Built-In
Automated&
Manual
Testing Pyramid
GUI
Acceptance Tests
Unit Tests
UI Scripting
At least one per requirement
At least one per class or module
Application layering
TDD at each layer
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
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
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 CriteriaScenario:Title• Given <Context>• When <Action>• Then <Result>• And <Another outcome>
Describe as a user storyUse Ubiquitous languageMust be testableShould fit in a sprintDescribes outcome of eventsThe event describes the featureNot always simpleMinimize domain mixing
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
Example : Refunds
As a <Persona/Role>I want <Feature/Behavior>So that <Business Benefit>
As a store ownerI want to process the refund and capture that informationSo that I can refund money back to the customer for a purchase return
Example
Scenario: Customer returns an purchased item
Given Customer has bought a itemAnd the item cost $500When we refund the itemThen Customer should be refunded $500
Write conditions like a story
Scenario: Customer returns a purchased item
Given Fred has bought a IpadAnd the Ipad cost $500When we refund the IpadThen Fred should be refunded $500
Developer : How do we know about the purchase
Scenario: Customer returns an Ipad and has purchase receipt
Given Fred has bought a IpadAnd the Ipad cost $500And he has the purchase receiptWhen we refund the IpadThen Fred should be refunded $500
Developer: Any conditions for return?
Scenario: Customer returns an unused and undamaged Ipad and has purchase receipt
Given Fred has bought a IpadAnd the Ipad cost $500And he has the purchase receiptAnd it is in an unused state and not damagedWhen we refund the IpadThen Fred should be refunded $500
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 IpadAnd the Ipad cost $500And he has the purchase receiptAnd it is in an unused state and not damagedAnd the Ipad is returned within 30 daysWhen we refund the IpadThen Fred should be refunded $500
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 IpadAnd Fred is a loyal customer And the Ipad cost $500And he has the purchase receiptAnd it is in an unused state and not damagedAnd the Ipad is returned within 60 daysWhen we refund the IpadThen Fred should be refunded $500
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 IpadAnd Fred is a loyal customer And the Ipad cost $500And Fred used a credit card to purchase the IpadAnd he has the purchase receiptAnd it is in an unused state and not damagedAnd the Ipad is returned within 60 daysWhen we refund the IpadThen Fred should be refunded $500 to his credit card
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 IpadAnd Fred is a loyal customer And the Ipad cost $500And Fred got a discount of $100And Fred used a credit card to purchase the IpadAnd he has the purchase receiptAnd it is in an unused state and not damagedAnd the Ipad is returned within 60 daysWhen we refund the IpadThen Fred should be refunded $400 to his credit card
Business Analyst: And we need to update the inventory system as well once refund is processed
Scenario: Items returned should update the inventoryGiven Fred has bought a IpadAnd Fred is a loyal customer And the Ipad cost $500And Fred got a discount of $100And Fred used a credit card to purchase the IpadAnd he has the purchase receiptAnd it is in an unused state and not damagedAnd the Ipad is returned within 60 daysWhen we refund the IpadThen Fred should be refunded $400 to his credit cardThen Inventory system should be updated with the return item
Another story
Scenario: Items returned should update the inventoryGiven an Ipad has been returned to the storeWhen the return has been processed successfullyThen the inventory system should be updated with the returned
item
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
ATDD Cycle of development
ATDD Cycle of development
Tools for writing Business scenarios
• SpecFlow• Fitnesse• Notepad• Many other commercial tools available
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
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
SpecFlow Structure
V
Feature File
Scenario
Scenario
Scenario
Step
Test Code
Testing Framework
Visu
al S
tudi
o
Step
Step
Step
Step
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
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
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
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
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)
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
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
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
BDD is about collaboration
• Having conversations
• is more important than capturing conversations
• is more important than automating conversations
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 time2) An iterative development process3) Access to stakeholders and end users with a strong feedback loop4) Solid design principles required for refactoring (code and BDD tests)5) Sharp design sense6) 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
Questions
