Business driven development
Download as PPTX, PDF2 likes600 views
This document presents a talk by Benoy John on Business Driven Development (BDD) at the Twin Cities Code Camp, detailing his experience and the importance of aligning software development with business needs. It emphasizes collaboration among stakeholders to clarify requirements through user stories and behavior-driven scenarios, ultimately aiming for better quality and understandability in software products. The document also outlines tools like Cucumber and SpecFlow to support BDD and highlights the benefits for business analysts, developers, and testers in fostering effective communication and documentation.
Business driven development
- 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
- 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/