Upgrade to Pro — share decks privately, control downloads, hide ads and more …

BDD is not about Testing

BDD is not about Testing

BDD started as a way to teach TDD to programmers who kept getting hung up on the idea they were writing tests. Fast-forward a decade or so and it seems BDD scenario automation tools have invaded the world of acceptance testing like Japanese knotweed. All around I see teams harming themselves writing awkward, verbose tests using slow, cumbersome tools like Cucumber and SpecFlow, and acting as though BDD is some kind of testing approach.

Part of the problem is that once you have an automated BDD scenario and you've written the software to satisfy it, it can look seductively like a test. From there it is a short step to thinking of these scenario automation tools as testing software, and the rest is frustrating, repetitive history.

This long-overdue talk explores the relationship between BDD scenarios and acceptance tests, and suggests some strategies for avoiding the pain of BDD-as-test automation.

Daniel Terhorst-North

November 10, 2016
Tweet

More Decks by Daniel Terhorst-North

Other Decks in Programming

Transcript

  1. Motivation Testers feeling “left behind” by Agile Testers writing hundreds

    of “BDDs” Hiring for “automation testers”
  2. Motivation Testers feeling “left behind” by Agile Testers writing hundreds

    of “BDDs” Hiring for “automation testers” Generally poor training around “agile testing”
  3. Motivation Testers feeling “left behind” by Agile Testers writing hundreds

    of “BDDs” Hiring for “automation testers” Generally poor training around “agile testing” Testers unsettled about the role of SET/SDET
  4. tl;dr 1. Programmers don’t understand testing 2. Agile doesn’t understand

    testing 3. BDD is appealing to testers 4. BDD is not about testing
  5. Why do we have testing? Mandated by the SDLC Programmers

    see testing as an irritation Project managers see testing as a source of risk
  6. Why do we have testing? Mandated by the SDLC Programmers

    see testing as an irritation Project managers see testing as a source of risk Testing is always the thing that gets squeezed
  7. Why do we have testing? Mandated by the SDLC Programmers

    see testing as an irritation Project managers see testing as a source of risk Testing is always the thing that gets squeezed Non-differentiating, non-critical
  8. The goal of testing… “to find information”? “to communicate”? to

    enable us to “reasonably believe that the probability is low that the product still has important undiscovered problems”?
  9. –Kent Beck "I get paid for code that works, not

    for tests, so my philosophy is to test as little as possible to reach a given level of confidence." http://stackoverflow.com/a/153565/632259
  10. A good tester has 3 superpowers… to increase confidence for

    stakeholders through evidence Empathy Ingenuity
  11. A good tester has 3 superpowers… to increase confidence for

    stakeholders through evidence Empathy Balance Ingenuity
  12. Agile doesn’t understand testing Agile methods were invented by programmers

    Testing is implied but never explicit The tester role is missing or poorly defined
  13. BDD is appealing to testers… We acknowledge multiple stakeholders We

    discuss acceptance criteria from the outset Everything happens from the perspective of the stakeholders!
  14. BDD is appealing to testers… We acknowledge multiple stakeholders We

    discuss acceptance criteria from the outset Everything happens from the perspective of the stakeholders! We increase confidence for stakeholders through evidence
  15. BDD is appealing to testers… We acknowledge multiple stakeholders We

    discuss acceptance criteria from the outset Everything happens from the perspective of the stakeholders! We increase confidence for stakeholders through evidence It’s not surprising BDD often starts with testers
  16. The lifecycle of a scenario Starts as enabling constraint to

    guide the design Then: checks* the solution
  17. The lifecycle of a scenario Starts as enabling constraint to

    guide the design Then: checks* the solution May be useful as documentation
  18. The lifecycle of a scenario Starts as enabling constraint to

    guide the design Then: checks* the solution May be useful as documentation May form the basis of automated tests
  19. The lifecycle of a scenario Starts as enabling constraint to

    guide the design Then: checks* the solution May be useful as documentation May form the basis of automated tests *check: (vt) inspect, investigate, examine, verify
  20. Scenario as the basis of tests What general case is

    this an example of? How could I gain confidence in the general case?
  21. Scenario as the basis of tests What general case is

    this an example of? How could I gain confidence in the general case? Which stakeholder does this serve? What else do they need?
  22. Scenario as the basis of tests What general case is

    this an example of? How could I gain confidence in the general case? Which stakeholder does this serve? What else do they need? Which stakeholders have we not yet served?
  23. Scenario as the basis of tests What general case is

    this an example of? How could I gain confidence in the general case? Which stakeholder does this serve? What else do they need? Which stakeholders have we not yet served? Scenarios are necessary but not sufficient for testing
  24. What does a good automated test look like? Intention-revealing name

    Intention-revealing errors Consistent language
  25. What does a good automated test look like? Intention-revealing name

    Intention-revealing errors Consistent language The intent, the whole intent and nothing but the intent
  26. What does a good automated test look like? Intention-revealing name

    Intention-revealing errors Consistent language The intent, the whole intent and nothing but the intent Fast! “Close to the action”
  27. What does a typical gherkin scenario look like? Intention-revealing name

    Intention-revealing errors Consistent language The intent, the whole intent and nothing but the intent Fast! “Close to the action”
  28. What does a typical gherkin scenario look like? Intention-revealing name

    Intention-revealing errors Consistent language The intent, the whole intent and nothing but the intent Fast! “Close to the action”
  29. What does a typical gherkin scenario look like? Intention-revealing name

    Intention-revealing errors Consistent language The intent, the whole intent and nothing but the intent Fast! “Close to the action”
  30. What does a typical gherkin scenario look like? Intention-revealing name

    Intention-revealing errors Consistent language The intent, the whole intent and nothing but the intent Fast! “Close to the action” ??
  31. What does a typical gherkin scenario look like? Intention-revealing name

    Intention-revealing errors Consistent language The intent, the whole intent and nothing but the intent Fast! “Close to the action” ?? ??
  32. BDD is not about testing, however… Testing is complementary to

    BDD Testing is the sufficient to BDD’s necessary
  33. BDD is not about testing, however… Testing is complementary to

    BDD Testing is the sufficient to BDD’s necessary Test thinking is critical to successful delivery
  34. BDD is not about testing, however… Testing is complementary to

    BDD Testing is the sufficient to BDD’s necessary Test thinking is critical to successful delivery Testability starts with design
  35. BDD is not about testing, however… Testing is complementary to

    BDD Testing is the sufficient to BDD’s necessary Test thinking is critical to successful delivery Testability starts with design software that matters, for “people whose lives you touch”