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.

Scrum Bangalore 13th meet up 13 june 2015 - behaviour driven development - vinay krishna - at prowareness

2,867 views

Published on

Scrum Bangalore 13th meet up 13 june 2015 - behaviour driven development - vinay krishna - at prowareness

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Scrum Bangalore 13th meet up 13 june 2015 - behaviour driven development - vinay krishna - at prowareness

  1. 1. Behaviour Driven Development Only an effective way to collaborate among three amigos Testing is just a by-product Vinay Krishna vinaykris@gmail.com http://in.linkedin.com/in/vinaykrishna 6/10/2015 1
  2. 2. Introduction • Often software development results surprises at the end – The business being unable to define the desired outcomes – Ambiguity in the developer’s and tester’s understanding of what needs to be built – The business not able to understand the technical challenges or unable to look at tester’s view on the requirement 6/10/2015 2
  3. 3. Introduction • Three roles, three steps (document specification, write code; develop the app, write test plan; test the app) • Three specs and three different lifecycles – Mostly we maintain three different versions of system’s need and many times find conflict among them • Functional Specification document • Source Code • Test case and test plan document 6/10/2015 3
  4. 4. Introduction • Is it Bug? • Is it Feature? • No, it is Beature – Blame game 6/10/2015 4
  5. 5. Introduction • Why beature? – Misunderstanding at all level – Lack of effective communication – Difficulty in communication – Lots of assumptions 6/10/2015 5
  6. 6. Group Activity • To understand the importance of communication • To understand the challenge in communication 6/10/2015 6
  7. 7. Discuss • 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 • Can you use this information to deliver a working feature? 6/10/2015 7
  8. 8. Discuss • These 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? 6/10/2015 8
  9. 9. BAs Testers Developers 6/10/2015 9
  10. 10. What is BDD? 6/10/2015 10
  11. 11. What is BDD • Exploring the unknown • Sharing and understanding • Individuals and interactions over processes and tools 6/10/2015 11
  12. 12. Introduction • Behavior Driven Development – Describes what business wants the system to do by talking through example behavior. – Work from the outside-in to implement those behaviors using the examples to validate the development. 6/10/2015 12
  13. 13. Conversation Focused • BDD is – Conversation among Three amigos • PO/BAs • Developers • Testers – Example based – Value-Driven – Outside-in 6/10/2015 13
  14. 14. Ubiquitous Language • To make sure that the whole team understand what's wanted, the behavior is described in non-technical language. – Gherkin language (given, when, then) – Gherkin is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. – Simple syntax, few keywords • Feature • Background, Tag • Scenario, Scenario Outline • Given, When, Then – Localized to 35+ languages 6/10/2015 14
  15. 15. Feature • Every *.feature file conventionally consists of a single feature. • Lines starting with the keyword Feature: (or its localized equivalent) followed by three indented lines starts a feature. • A feature usually contains a list of scenarios. • You can write whatever you want up until the first scenario, which starts with Scenario: (or localized equivalent) on a new line. • You can use tags to group features and scenarios together, independent of your file and directory structure. 6/10/2015 15
  16. 16. Scenario • Every scenario starts with the Scenario: keyword, followed by an optional scenario title. • Each feature can have one or more scenarios. • Every scenario consists of a list of steps, which must start with one of the keywords – Given – When – Then – But or And 6/10/2015 16
  17. 17. Given • The purpose of the Given steps is – To put the system in a known state before the user (or external system) starts interacting with the system (in the When steps). • Avoid talking about user interaction in givens. • If you have worked with use cases, givens are your preconditions. • Example – To create records (model instances) or set up the database: Given there are no users on site Given the database is clean – Authenticate a user (an exception to the no-interaction recommendation. Things that “happened earlier” are ok): Given I am logged in as "Everzet" 6/10/2015 17
  18. 18. When • The purpose of When steps is to describe the key action the user performs • Examples: – Interact with a web page (Webrat/Watir/Selenium interaction etc should mostly go into When steps). – Interact with some other user interface element. – Developing a library? Kicking off some kind of action that has an observable effect somewhere else. When I register 6/10/2015 18
  19. 19. Then • The purpose of Then steps is to observe outcomes. • The observations should be related to the business value/benefit in your feature description. • The observations should inspect the output of the system (a report, user interface, message, command output) – and not something deeply buried inside it (that has no business value and is instead part of the implementation). 6/10/2015 19
  20. 20. And / But • If you have several Given, When or Then steps, you can use And or But steps, allowing your Scenario to read more fluently 6/10/2015 20
  21. 21. Step Data • Steps may have some text or a table of data attached to them. • Substitution of scenario outline values will be done in step data text or table data if the “<name>” texts appear within the step data text or table cells. • Text – Any text block following a step wrapped in “” lines will be associated with the step. • Table – You may associate a table of data with a step by simply entering it, indented, following the step. This can be useful for loading specific required data into a model. Given a set of specific users | name | department | | Barry | Beer Cans | | Pudey | Silly Walks | | Two-Lumps | Silly Walks | 6/10/2015 21
  22. 22. Example Feature: Withdraw money from ATM In order to avoid be in queue and save time Customers should be able to withdraw money from ATM all times Scenario: Account has sufficient fund Given Card is valid And Account has 10000 Rs balance When Customer enter 1000 Rs to withdraw Then Customer should get 1000 Rs AND Account should have 9000 remaining balance AND system should return the card 6/10/2015 22
  23. 23. • Think and identify more scenarios for same feature. • Discuss in your group each identified scenario and write it using gherkin language 6/10/2015 23
  24. 24. Summary • Working together to find better solutions • Use real-world examples to build a shared understanding of the domain • People understand requirements best using concrete examples. • Examples clear up ambiguity and misunderstandings. • Examples expose missing requirements. • Examples force everyone to think harder about a problem. 6/10/2015 24
  25. 25. BDD framework • Feature file • Step Definition (Glue code) • Actual implementation FeaturefilecontainingScenarios GlueCode(StepDefinitions) ActualImplementation(Application) ActualImplementation(Application) ActualImplementation(Application) ActualImplementation(Application) 6/10/2015 25
  26. 26. Re-visit VAT example 6/10/2015 26
  27. 27. Glue Code 6/10/2015 27
  28. 28. Best Practices • Shallow BDD – Automation doesn’t mean, it’s BDD. Communication is must – It’s like people who say they’re doing BDD, but they just use Cucumber/SpecFlow to automate scenarios without actually talking to anyone – That’s not Shallow BDD. That’s not BDD at all. – In fact, if they do that, they’ll probably run into trouble. Shallow BDD is when you just have conversations around scenarios. – The shallowest form of BDD consists of just having conversations around scenarios – not capturing them, not automating them, but just having the conversations. 6/10/2015 28
  29. 29. Best Practices • Avoid UI driven scenario – Not recommended Given I’m in user registration page And I filled FirstName “Vinay” And filled LastName “Krishna And filled City “Bangalore” …………………………………. …………………………………. And I choose to register as a developer When I click on Register Then I received successfully registered message – Recommended Given I am registering When I fill in my basic information Then I should be registered as a developer 6/10/2015 29
  30. 30. Best Practices • 5 why – Determining the root cause • Example – Problem Statement: Customers are unhappy because they are being shipped products that don’t meet their specifications. 1. Why are customers being shipped bad products? – Because manufacturing built the products to a specification that is different from what the customer and the sales person agreed to. 2. Why did manufacturing build the products to a different specification than that of sales? – Because the sales person expedites work on the shop floor by calling the head of manufacturing directly to begin work. An error happened when the specifications were being communicated or written down. 3. Why does the sales person call the head of manufacturing directly to start work instead of following the procedure established in the company? – Because the “start work” form requires the sales director’s approval before work can begin and slows the manufacturing process (or stops it when the director is out of the office). 4. Why does the form contain an approval for the sales director? – Because the sales director needs to be continually updated on sales for discussions with the CEO. • In this case only four Whys were required to find out that a non-value added signature authority is helping to cause a process breakdown. 6/10/2015 30
  31. 31. BDD Myths • BDD is automation of functional testing – Automation of scenarios are just a by-product. Remember Shallow BDD • Using cucumber or specflow is BDD – No, its just using a tool • BDD is replacement of functional testing – No, lets discuss 6/10/2015 31
  32. 32. 6/10/2015 32

×