Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Behaviour driven development aka bdd

208 views

Published on

A Presentation on BDD Principles.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Behaviour driven development aka bdd

  1. 1. BEHAVIOUR DRIVEN DEVELOPMENT AKA BDD SOFTWARE THAT MATTERS
  2. 2. BDD WHY ? WHEN ? HOW ?
  3. 3. WHO BRING BDD ? He is a technology and organizational consultant who helps business leaders, managers and software teams deliver quickly, successfully and sustainably. Dan’s background in software delivery, Lean operations, coaching and organizational change.
  4. 4. DISCONNECTS IN LAUNCHING OF A PROJECT the business being truly able to define the desired outcomes the developer’s understanding of what needs to be built, and the business’ understanding of the technical challenges their requirements may present.
  5. 5. BDD HELPS TO CONNECT THEM the business being truly able to define the desired outcomes the developer’s understanding of what needs to be built, and the business’ understanding of the technical challenges their requirements may present.
  6. 6. WHAT ?  BDD is a process designed to aid the management and the delivery of software development projects by improving communication between engineers and business professionals. In so doing, BDD ensures all development projects remain focused on delivering what the business actually needs while meeting all requirements of the user.
  7. 7. KEY BENEFITS All development work can be traced back directly to business objectives. Software development meets user need. Satisfied users = good business. Efficient prioritisation - business-critical features are delivered first. All parties have a shared understanding of the project and can be involved in the communication. A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression. Resulting software design that matches existing and supports upcoming business needs. Improved quality code reducing costs of maintenance and minimizing project risk.
  8. 8. BDD APPROACHES Practice of using examples written in ubiquitous language to illustrate behaviors (how users will interact with the product). Practice of using those examples as the basis of automated tests. As well as checking functionality for the user, this ensures the system works as defined by the business throughout the project lifetime.
  9. 9. CO-ORDINATES OF BDD 19.0760° N, 72.8777° E
  10. 10. CO-ORDINATES OF BDD Starting with a Goal Impact Mapping Value and Complexity Analysis Planning In Examples Usage Centred Design Ubiquitous Language 3 Amigos Development Through Examples The BDD Loops
  11. 11. STARTING WITH A GOAL Every Behaviour Change should help the Business to achieve its goals Projects should delivered in sets of Capabilities aka Working Features. Understand exactly what you want the software to achieve from a business perspective.
  12. 12. S.M.A.R.T GOAL Specific Measura ble Attainabl e Relevant Time- bound
  13. 13. S.M.A.R.T GOAL “We are going to generate more revenue by making more sales” “We are planning to achieve a 15% increase in revenue through our online channels in 6 months” Not S.M.A.R.T S.M.A.R.T Having a SMART goal not only helps to focus the project, but allows the impact of the to be measured.
  14. 14. IMPACT MAPPING Now we have sets our goal its time for Impact
  15. 15. IMPACT MAPPING  Don’t add features to applications just for sake of more features.  Its not always a case that to achieve a goal you have to add a new feature.  It is important to understand that not all of these features need the same level of attention, care, or even development practice, and it can be easy to spread the development team’s attention too thinly across an entire backlog.
  16. 16. IMPACT MAPPING  Impact Mapping is a technique that helps you to outline all the alternative ways to reach your decided goal by analyzing users’ behavior. We assume that software cannot achieve business goals on its own. The only way software can get us closer to the goal is by supporting particular human behaviors.
  17. 17. LEVELS OF IMPACT MAP One or More Ways To Support or Prevent These Impacts One or More Impacts One or More Actors Business Goal
  18. 18. LEVELS OF IMPACT MAP Customer or Team that could help or hinder the project from achieving the goal. Actors
  19. 19. LEVELS OF IMPACT MAP Each actor could have multiple ways to help or hinder achieving the goal, we call these impacts.. Impacts
  20. 20. LEVELS OF IMPACT MAP What the project or delivery team can do in order to support or prevent particular impacts from happening. Support or Prevent Impacts
  21. 21. VALUE AND COMPLEXITY ANALYSIS Value analysis helps us to quickly identify low-cost, high-value features in the backlog. Complexity analysis helps us to choose the right development and collaboration approach to the project as a whole, as well as each individual feature.
  22. 22. PLANNING IN EXAMPLES Imagine we have been given a task to add an ‘include VAT and delivery cost to the total price of the customer basket’ feature to an existing ecommerce project with following set of business rules: VAT is 20% Delivery cost for small basket (less than $20) is $3 Delivery cost for medium basket (more than $20) is $2
  23. 23. PLANNING IN EXAMPLES Big ?  Rules do not specify whether to add VAT before delivery cost to the basket total or after.  How should you handle a situation where the basket delivery cost is exactly $20?  What happens if there are multiple products in the basket?
  24. 24. PLANNING IN EXAMPLES  Given a product is priced at $15, when I add it to the basket, then the total basket price should be $21  Given a product is priced at $25, when I add it to the basket, then the total basket price should be $32  Given a product is priced at $20, when I add it to the basket, then the total basket price should be $26
  25. 25. UBIQUITOUS LANGUAGE  Almost impossible, to form a two-way communication between groups of people that operate in different business spheres.  They can stumble upon situations where both sides use the same language and even words, but imply a different meaning.
  26. 26. UBIQUITOUS LANGUAGE Share
  27. 27. UBIQUITOUS LANGUAGE  BDD attempts to eliminate the cost of translation by reducing the size of feedback loops and using the example-based conversation about each feature before they are built.  But just asking for examples is not enough, because different sides will use different language to produce examples, eventually causing discrepancies.  The solution for this problem is the concept the BDD community borrowed from DDD (Domain Driven Design): ubiquitous language.
  28. 28. INTRODUCING THE 3 AMIGOS One of the core ideas behind BDD is that no single person has the full answer to the problem.
  29. 29. INTRODUCING THE 3 AMIGOS 3 Amigos Business Roles Developer Tester
  30. 30. INTRODUCING THE 3 AMIGOS Business Roles – Product Owner or Analyst • Business value and risk evaluation domain. • Their insight and input is extremely important if you want to
  31. 31. INTRODUCING THE 3 AMIGOS Developers • In the most part, remain in the so-called ‘solution’ space. • Input will give you an invaluable context into how much detail the
  32. 32. INTRODUCING THE 3 AMIGOS Testers • Usually represent the ‘problem’ space. • They see flaws happening in the system even before development commences. • Plays crucial role while analysing negative impact in application. • Identifies blanks in requirements.
  33. 33. 3 AMIGOS  The core premise of BDD is not to replace these different expertise, but to move them all in one room and have a meaningful discussion about each feature before development starts. This process is called the Three Amigos or an Example Workshop and must be conducted before the team or a developer commits to deliver the feature in question.
  34. 34. DEVELOPMENT THROUGH EXAMPLES Feed an example to an automation tool (such as Behat, Cucumber or SpecFlow). • Feature Files Will transform it into the automated specification. • Step Definitions Can then use this automated specification to drive the application development. • Developm nt
  35. 35. GHERKIN FORMAT & SYNTAX  Gherkin files are plain-text and have the extension .feature  Keywords:  Feature • And  Background • But  Scenario • *  Given • Scenario Outline  When  Then
  36. 36. FEATURE  The feature keyword is used to group a set of tests (scenarios)  The text on the same line as the keyword is considered the name of the feature  All text between the initial line and a line that starts with Scenario, Background, or Scenario Outline is considered part of a feature’s description.  It is conventional to name a .feature file by taking the name of the feature, converting to lowercase and replacing spaces with underlines  feedback_when_entering_invalid_credit_card_details.feature
  37. 37. COMING UP WITH FEATURES: THINK OF YOUR USERS  In order to identify features in your system, you can use what the authors describe as a “feature injection template”  In order to <meet some goal> as a <type of user> I want <a feature>  This is good advice  The functional requirements of a system are determined by asking the question  for each type of user  what goals are they trying to achieve?  what tasks must they perform to achieve those goals?  how does our system support those tasks?
  38. 38. SCENARIOS  Scenarios follow a pattern  Configure the system  Have it perform a specific action  Verify that the new state of the system is what we expected  We start with a context, describe an action, and check the outcome
  39. 39. SCENARIOS  Gherkin provides three keywords to describe contexts, actions, and outcomes  Given: establish context  When: perform action  Then: check outcome  Example  Scenario: Withdraw money from account  Given I have $100 in my account  When I request $20  Then $20 should be dispensed
  40. 40. SCENARIOS  Additional steps to the context, action, and outcome sections using the keywords and and but  They allow you to specify scenarios in more detail  Scenario: Attempt withdrawal using stolen card  Given I have $100 in my account  But my card is invalid  When I request $50  Then my card should not be returned  And I should be told to contact the bank  These keywords help increase the expressiveness of the scenario
  41. 41. SCENARIOS  In creating scenarios, a key design goal (indeed requirement) is that they must be stateless; as the book says  “Each scenario must make sense and be able to be executed independently of any other scenario”  You can’t have the success condition of one scenario depend on the fact that some other scenario executed before it  Each scenario creates its particular context, executes one thing, and tests the result
  42. 42. SCENARIOS  Having stateless scenarios provides multiple benefits  Tests are simpler and easier to understand  You can run just a subset of your scenarios and you don’t have to worry about your test set breaking  Depending on your system, you might be able to run tests in parallel reducing the amount of time it takes to execute all of your tests
  43. 43. SCENARIOS  Having stateless scenarios provides multiple benefits  Tests are simpler and easier to understand  You can run just a subset of your scenarios and you don’t have to worry about your test set breaking  Depending on your system, you might be able to run tests in parallel reducing the amount of time it takes to execute all of your tests
  44. 44. To Be Continued . . .

×