BDD In Action

Summary

TBD

Top 3 Things I Learned

  1. Impact Mapping.  Visually breaking business goals (why) down into the stakeholders (who), capabilities (how), and features (what)
  2. TBD
  3. TBD
Introductory Notes

QUOTE: (from book cover): You can’t write good software if you don’t understand what it’s supposed to do.

IDEA (from Forward by Dan Norton). BDD was developed to address these weaknesses in software development:

  1. Programmers don’t want to write tests
  2. Testers don’t want to write programs
  3. Business stakeholders don’t see value in anything that isn’t production code

CONCEPT: (from Forward by Dan Norton)

  • More documentation isn’t better, better documentation is better
  • More software isn’t better, better software is better

CONCEPT: (from introduction).  BDD can do these things for you

  • Discover requirements
  • Define high-level requirement
  • Implementing the app features
  • Writing executable specifications

CONCEPT: (from introduction): We want Product Owners to

  • Effective ways of discovering requirements in collaboration with users
  • Communicate with development teams
  • Help teams build more valuable software

CONCEPT: (from Part 1 preface): Why BDD

  • Discover Requirements
  • Automating high-level acceptance criteria
  • Building and verifying design and implementation
  • Produce accurate and up-to-date technical and functional documentation

Notes: Chapter 1: Building software that makes a difference

SUMMARY: A very broad chapter with some very good illustrations and examples about the concepts discussed in the chapter.  The chapter begins with a high-level view of BDD.  How BDD can focus the effort to ensure the system that is developed aligns with the business purpose.  The basic format of BDD, principles and practices make up the most of the chapter.  The chapter ends with a brief discussion on the pros/cons of BDD.

CONCEPT: BDD is about

  • Building s/w that works well
  • Easy to change s/w
  • Easy to maintain s/w
  • Build s/w well
  • Build s/w that is worth building

IDEA: Old ways to create software

  • Take too long to deliver
  • More time fixing bugs over new features
  • Hard to deliver new features quickly
  • Longer for new development to get up to speed
  • Code is hard to understand
  • Harder and harder to add new features without breaking existing code
  • Documentation is out of date
  • Lengthy manual development process

IDEA: New ways to create software

  • Near zero defect rate
  • Easier to adapt
  • Add features at a more consistent pace
  • Plan more precisely

CONCEPT: To build a meaningful test

  • Naming unit test with full sentences
  • Begin with the word “should”

CONCEPT: BDD Writing Goals

  • Specification
  • Focus on behavior
  • Easy to maintain
  • Intent is clear

TERM: BDD: A ubiquitous language that business analysts use to define requirements unambiguously and that could also be easily transformed into automated acceptance test.

CONCEPT: Executable Specification is

  • Illustrates
  • Verifies
  • Close to natural language
  • Becomes a single source of truth
  • Becomes reference documentation

TERM: Outside-in: Start with the acceptance criteria and work down

CONCEPT: Flow Diagram

  • STEP  | DESCRIPTION | TOOL/TECHNIQUE
  • Business Goal | Process starts here | N/A
  • Features | Decomposition of business goal | User Stories
  • Examples | Clarify assumptions and prepare acceptance criteria | N/A
  • Executable Specification | Business requirements | Cucumber, JBehave, specflow
  • Low Level Specification | Very readable unit tests | JUnit, NUnit, spock, RSpec

CONCEPT: Benefits of BDD

  • Reduce features not aligned with the business
  • Reduce implementations not of value to the business
  • Reduce costs
  • Easier and safer to change
  • Faster releases

CONCEPT: Disadvantages of BDD

  • Dependent on significant business engagement and collaboration
  • Works best in an Agile or iterative approach
  • Doesn’t work well in silos
  • Poorly written tests can increase maintenance costs
Notes: Chapter 2: BDD-the whirlwind tour

SUMMARY: This chapter does a top to bottom example from Business Goals through automated unit tests and implementation using BDD principles at each level.  The chapter begins by introducing the time-table application that will be used in the chapter. A very short (paragraph) section on determining business value then into the requirements analysis.  A lengthy and detailed walkthrough of implementing the details and discovering more requirements, which is the bulk of the chapter.  The chapter ends with a brief discussion on the impact on maintenance.

IDEA: One of the key goals of BDD is to ensure that everyone has a clear understanding of what a project is trying to deliver, and of the underlying business objectives of the project.

CONCEPT: Capture primary business goals in a sentence.

CONCEPT: Requirement format in story writing

  • As a <stakeholder> [Who benefits]
  • I want <something>  [What does the feature do]
  • So that <I achieve some business goal> [What business value]

NOTE: Alternative is to start with “In order to <achieve business goal>  As a <stakeholder> I want <something>

CONCEPT: Stories are a dynamic, iterative process designed to facilitate communication and a shared understanding

CONCEPT: BDD Format

  • Given <a context>
  • When <something happened>
  • Then <you expect some outcome>

TOOLS: BDD tools: JBehave, Cucumber, SpecFlow, and Behat

TECHNIQUE: Format of a project

  • pom.xml – Maven build file
  • src/main/java – Application code
  • src/test/java – Test code
  • src/test/java/com/bddinaction/chapter2/jbehave/AcceptanceTestSuite.java – Main Test runner
  • src/test/resources/stories – JBehave stories
  • src/test/resources//stories/commuters – functional group
  • src/test/resources/stories/communters/narrative.txt – title and short description of the functional group
  • src/test/java/com/bddinaction/chapter2/jbehave/steps – location of @Given, @When, @Then classes (step classes)

BEST PRACTICES:

  • Organize stories by functional groups
  • Include a narrative.txt in each functional group to describe the group
  • narrative.txt format:
    • One line title
    • Short, free-form description of this high-level functionality
  • Use the @Pending annotation after the @Given, @When, @Then initially until implemented.
  • Start coding with @Then

TERM: Executable specification: scenario turned into executable statements and a living document

CONCEPT: Work outside in from the @Then annotation.  Start with the outcome you need to obtain and work backwards

CONCEPT: Use JBehave for automated acceptance criteria and Spock for low-level unit testing.

CONCEPT: Measuring progress through @Pending, feature to be implemented and passing shows progress – automated, living documentation

CONCEPT: Executable specification also make it easier to maintain

Notes: Chapter 3: Understanding the business goals. Feature Injection and related techniques

SUMMARY: This chapter focuses on the first steps in determining what you should build based on business value.  The chapter introduces Impact Modeling and Feature Injection and a Purpose Based Alignment Model.  It starts with Feature Injection explaining “Hunt the Value”, “Inject the features”, and “Spot the Examples”.  The next part of the chapter goes into vision and business goals (using Moore’s elevator symbol and SMART goals).   Several pages are devoted to Impact Mapping with Why, Who, How, What.  It ends with the Purpose-Based Alignment Model.

IDEA: BDD places great emphasis on building software that matters and defines several processes for turning client requirements into something that developers can use to code against and that accurately reflects the core values of the software the client wants.

IDEA: The aim of Feature Injection is to flesh out the minimum set of features.

CONCEPT: Parts of Feature Injection

  • Hunt the value
  • Inject the features
  • Spot the examples

CONCEPT: How this all fits together

Vision –> Goals –> Capabilities –> Features –> Stories –> Acceptance Criteria –> Examples –> Code

BEST PRACTICES: For feature injection

  • Capabilities don’t imply a particular implementation
  • Features are pieces of deliverable software functionality
  • Examples illustrate how a feature works

CONCEPT: Moore’s Elevator Statement

  • FOR <target customer>
  • WHO <needs something>
  • THE <product name> is a <product category>
  • THAT <key benefit, compelling reason to buy>
  • UNLIKE <primary competitive alternative>
  • OUR PRODUCT <statement of primary differentiation>

CONCEPT: SMART Goals

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time-bound

CONCEPT: Government Motivators

  • Improving service
  • Reducing costs
  • Avoiding future costs

IDEA: Problem with waterfall is that the process deliberately hinders any change through change control processes.  Results in a very large set of requirements full of everything the stakeholder can possibly think of, with many features being included because they might come in handy.

IDEA: Any software project is an exercise in ongoing learning.

QUOTE: Don’t tell people how to do things, tell them what to do and let them surprise you with their results.  – George S. Patton

TERM: “Popping the why stack”.  Similar to the 5 whys

CONCEPT: Impact Map

  • Why? –  Business goals
  • Who? – Stakeholders
  • How? – Capabilities
  • What? – Features

NOTE: Impact maps are living documents that must be updated.

REFERENCE: http://impactmapping.org

BOOK: Adzic, Gojko. Impact Mapping: Making a Big Impact with Software Products and Projects. Woking, Surrey, United Kingdom: Provoking Thoughts, 2012. Print.

CONCEPT: Purpose Based Alignment Model

  • Dimensions
    • Dimension: Mission Critical
    • Dimension: Market Differential
  • 4 quadrants
    • NE: Differentiating
    • NW: Partner
    • SE: Parity
    • SW: Minimal Impact
Notes: Chapter 4: Defining and illustrating features

SUMMARY: The third chapter focused on business goals and how to define them.  This chapter moves onto the next step in the process, dealing with features.  The chapter starts with a long discussion on terms.  The chapter then moves onto discussing the characteristics of a feature in great detail.  The next sub-part talks about illustrating features with examples.  The next sub-part is on a concept called “Real Options” followed by “Deliberate Discovery”.  The chapter ends with a great illustration of the process.

TERM: Various terms are defined:

  • Feature: A piece of software that helps users achieve some business goals
  • User Story: A way of breaking down the feature
  • Concrete Examples: used to develop a shared understanding, clarifies ambiguities and uncertainty in requirements
  • Managing uncertainties: Use Real Options
  • Deliberate Discovery: a method to reduce project risk

CONCEPT: BDD overall goals

  • Deliver tangible, visible value to the business at regular intervals
  • Get regular feedback

CONCEPT: Subtle point with the format of how they write features, there is a difference between a persona and a stakeholder.  Keeps the focus on the business goal / value.

CONCEPT: A user story is not actually a requirement but more of a promise to have a conversation with the stakeholders about a requirement.

CONCEPT: Acceptance criteria clarify the scope and boundaries of the story or feature.  They help remove ambiguities, clarify assumptions, and build up the team’s common understanding of the story or feature.

CONCEPT: David Kolb’s Experimental Learning theories applied to BDD

  • Experience – You start off by looking at real-world examples
  • Reflection – You think about concrete experience
  • Conceptualize – New mental model
  • Test – You test this model by looking for new examples to confirm or invalidate your examples

CONCEPT: Real Options – Putting off decisions until the last responsible moment.  An option gives you the possibility, but not the obligation.

CONCEPT: Real Options – key to design

  • Options have value
  • Options expire
  • Never commit early unless you know why
  • Options have a price

TERM: YAGNI – You Ain’t Gonna Need it

EXAMPLE: Applying Real Options to Scalability

  • You can ignore scalability and hope you never need it.  If you don’t you haven’t wasted effort.  If you do, then refactoring will be expensive
  • You can assume scalability.  If you never needed it, you have wasted effort, but if you do need it no additional work
  • You can buy an option for scalability, invest a little time up front and if you need it, the refactoring will be less expensive.

IDEA: Never commit early unless you know why

TERM: Deliberate Discovery: The flip side of Real Options.  Starts with the assumption that there are things you don’t know.  If you actively try to increase your knowledge in an area, you can both reduce risk of uncertainty and make decisions faster.  As soon as you have enough information to commit to a particular solution, you can choose to exercise the option or not.

IDEA: Wherever possible, identify the stories that involve the most uncertainty and tackle those first.

CONCEPT: Instead of having everybody in a planning session, use the three amigos technique: one developer, one tester, and one business analyst to discuss the requirements

CONCEPT: From example to working code

  1. Work on one example at a time
  2. Have a conversation about the example
  3. Write an automated scenario
  4. The automated scenario should fail
  5. Implement the scenario
    1. Pass
    2. Refactor
    3. Fail
  6. You are done with the scenario when the automated scenario passes
  7. Move on to the next scenario
  8. You have finished the story when all the examples are automated and pass.

 

Notes: Chapter 5: From examples to executable specifications

Notes: Chapter 6: Automating the scenarios

Notes: Chapter 7: From executable specifications to rock-solid automated acceptance tests.

Notes: Chapter 8: Automating acceptance criteria for the UI layer

Notes: Chapter 9: Automating acceptance criteria for non-UI requirements

Notes: Chapter 10: BDD and unit-testing

Notes: Chapter 11: Living Documentation: reporting and project management

Notes: Chapter 12: BDD in the build process

Advertisement