Presentation by Bria Grangard at STPCon 2019

1. Successfully Implementing BDD in
an Agile World

2. 2
Who am I?
• SmartBear Software
• Automated UI functional testing tools, test management
solutions, BDD platforms
• Podcast Co-Host
• The Good, The Bad, and the Buggy
• Education
• Dartmouth: AB in Engineering, BE in Biomedical
Engineering, MEM with a healthcare focus
• What do I love to do?
• Run, dance, play board games (Settlers of Catan anyone?)
• Stay in Touch!
• @Bria_Grangard
@Bria_Grangard

3. 3
The World of BDD
Shift Left
The BDD Process: People. Process, Tools
Question & Answer
Agenda
@Bria_Grangard

4. 4
Shift Left Overview
@Bria_Grangard

5. Software Has Traditionally Been Linear and Siloed
Proprietary & Confidential
5
Plan
Design
Develop
Document Deploy
MonitorTest
Developers QA OperationsBusiness
1 2 3 4
@Bria_Grangard

6. 6
WaterfallAgile
Design Build Test Implement
DevOps
Week1 Week2 Week3 Week4
@Bria_Grangard
The promise of the new software delivery cycle

7. 7
In the 1950’s, testing
happened by the same
people that wrote the code,
and it happened throughout
the project. There were no
dedicated testers at the
time.
The idea of testing earlier
isn’t new, but the term, Shift
Left has reignited its
importance.
@Bria_Grangard

8. 88
@Bria_Grangard
Shift Left:
/SHift/ + /left/
an approach to software development
where quality is considered and testing is
performed earlier in the lifecycle
• Testers are involved early
• BAs/PMs write requirements in the form of tests
• Developers write tests

9. 9
Why the hype around Shift Left?
Testing Early,
Testing Often
Speed Quality Cost
Cheaper to fixFewer defects
=
Shorter cycles
@Bria_Grangard

10. 10
Traditional Software Development Lifecycle
IBM Systems Sciences Institute
Design Develop Test Operations
Current Bug Discovery
Costtofixadefect($)
Avg Cost of Defect $100 $250 $1500
Design Develop Test DeployPlan Maintain
@Bria_Grangard

11. 11
Current Bug Discovery
Shifting Everything Left
IBM Systems Sciences Institute
Costtofixadefect($)
Design Develop Test Operations
Shift Left Discovery
Plan
Develop
Test
Maintain
@Bria_Grangard

12. 12
Software
Development
is Hard

13. 13
Shifting Left is Really Happening
• Developers create more testable code (less flaky tests)
• Bridge the gap between Dev, QA, and Product
• Code in sprints, now we can test in the same sprint too
• Maintain a single code base – Application and test (unit, API, UI)
• Enable true CI/CD
• Think about quality in every step
@Bria_Grangard

14. 14
BDD
AI
Machine
Learning
DevOps
Shift Left
Agile
Automation
TDD
Service
Virtualization
@Bria_Grangard

15. 15
How can teams Shift Left?
• Agile / DevOps Practices
• Virtualization
• API Testing
• Microservices
• CI/CD Processes
• BDD Workflows
@Bria_Grangard

16. 16
Sometimes… Agile can fall short
• Transient User Stories
• Ad-hoc Acceptance Criteria
• Limited Discovery
• No Overarching Tests

17. 17
How can teams shift Left?
• Agile / DevOps Practices
• Virtualization
• API Testing
• Microservices
• CI/CD Processes
• BDD Workflows
@Bria_Grangard

18. 18
BDD Overview
@Bria_Grangard

19. 19
@Bria_Grangard

20. 2020
Behavior Driven Development (BDD):
Is a software development process where teams
create simple steps on how an application should
behave from a user’s perspective.
@Bria_Grangard

21. 2121
What is BDD?
DeveloperTester
Business
• Discovery, Formulation, and Automation
• Create a shared understanding based
on examples
• Use the examples to drive development
• Create and share living documentation
The 3 Amigos
@Bria_Grangard

22. 22
What are the problems BDD helps
address?
1. Business needs are not well understood by
the people who want the software
2. Business needs are not well understood by
people who deliver and test the software
3. The software is low quality with lots of bugs
4. The cost of changes over time increases
rapidly
@Bria_Grangard

23. 23
Discovery Formulation Automation
BDD in Practice
@Bria_Grangard

24. 2424
A quick aside… BDD vs. TDD
@Bria_Grangard
• What you’re testing
• BDD: Test from the end-user’s standpoint
• TDD: Focus on testing smaller pieces of functionality in isolation
• How you’re testing
• BDD: Emphasis on team collaboration (product, devs, QA)
• TDD: A single person can complete in isolation (dev often)
• How they work together
• Need a good TDD base for success with BDD
• TDDà ensures code quality
• BDDà ensure use-cases work

25. 25
Making the Move to BDD
Benefits:
1. Better communication and
collaboration
2. Deliver value more frequently
3. Find and fix defects early and
often
4. Minimize waste
5. Avoid development of features
nobody wants
Opportunities and Challenges
Challenges:
1. Misalignment between various
stakeholders on your team
(product, dev, QA)
2. Producing products that don’t
address your user’s needs
3. No universal language between
departments
4. Pressure to release faster without
sacrificing quality
@Bria_Grangard

26. 26
In order to succeed you need to take a holistic approach
People Processes Tools
@Bria_Grangard

27. 2727
Let’s start with people…
… it’s all about collaboration
@Bria_Grangard

28. 28
Roles
@Bria_Grangard

29. 29Using a common Language
BDD Scenario
Business Development Test
• Defines requirements in spoken-word
scenarios
• Obtains feedback in clear, example
heavy, and easy to understand language
• Making the Scenario “pass” or “work”
guides development efforts and provides
focus
• Scenario is easily translated directly into
automated tests
• Given / When / Then structure provides
simple ways to ask for clarification
• Scenarios contain Test definitions
(Action, expected result)
• Structure allows for easy reporting and
traceability
@Bria_Grangard

30. 3030
Process
@Bria_Grangard

31. 31
The BDD Process
@Bria_Grangard

32. 32
Deliberate Discovery
@Bria_Grangard
Have conversations about user stories and
acceptance criteria using concrete examples
Goal: Try and learn as much as possible before
writing any code

33. 33
Who should be involved in Deliberate Discovery?
• Product Owners
• Business Analysts
• Domain Experts
• Users
• Developers
• UX Designers
• Testers
@Bria_Grangard

34. 34
Running a Discovery Workshop
From Matt Wynne:
• Three Amigos Meetings
• Keep them short! (25 minutes/user story)
• Use Example Mapping
• User Story—user stories that were developed in deliberate discovery process
• Rules—acceptance criteria for the user story containing agreed-upon
constraints
• Examples—concrete examples covering each rule (may have more than one per
rule)
• Questions—unknowns that arise when exploring rules, examples, or
assumptions made to move forward
@Bria_Grangard

35. 35
Example Mapping—
Session
• Set-Up:
• Use a pack of four-color index cards
• Remove distractions
• Running a Session:
1. Write the story in yellow
2. Write acceptance criteria, or “rule”
in blue
3. Write concrete examples on green
4. Capture questions on red
5. Vote to see if the user story is
ready for development
@Bria_Grangard

36. 36
Record the Results
@Bria_Grangard
• Use Gherkin Syntax
• Create Executable
Specification without
code

37. 37
Step 1: Focus on the Value First
• What are the benefits of your feature?
• First step: start with answering “why”
• Why should we develop this feature?
• Why will this feature help my user?
• A feature should have a description that provides context to a need being met
• In order to [get a benefit]
• As a [role]
• I want [a feature]
•Example: HipTest & Slack
• Everyone on team needs a notification?
• Only HipTest users should be able to get notified
@Bria_Grangard

38. 38
Step 1: Focus on the Value First
• What are the benefits of your feature?
• First step: start with answering “why”
• Why should we develop this feature?
• Why will this feature help my user?
• A feature should have a description that provides context to a need being met
• In order to [get a benefit]
• As a [role]
• I want [a feature]
•Example: HipTest & Slack
• Everyone on team needs a notification?
• Only HipTest users should be able to get notified
@Bria_Grangard

39. 39
Step 2: Be Declarative When Writing Scenarios
• Focus on the what?
• Two styles of writing your test scenario
• Imperative
• Long scenarios with low-level steps describing how to navigate the user interface
• Declarative
• Gherkin syntax
• Given is your setup
• When is your action
• Then is your assertion
• Text describes the what not the how
@Bria_Grangard

40. 40
Step 2: Be Declarative When Writing Scenarios
• The Declarative Style of Writing—An Example
• Given I am logged in
• When I add an item to the cart
• And I click on the cart
• Then I should see the item I
added
WhyisthisDeclarative?
• Itdoesn’tmatterhowsomeonedidthe
loginàusername,password,touchID
• Whatdoesmatter:someoneloggedin
DeclarativeExampleforHipTest&Slack
GivenIhaveactivatedslackinthesettingsofmyHipTestproject
WhenIquery/hiptestTestRunIDfromslack
ThenIshouldseethebreakdownoftestsbystatusesfortestRunID
@Bria_Grangard

41. 41
Step 3: Automate (if you’d like) Your BDD Scenarios
• Build a test automation framework
• Focus on building a framework that will scale
• Your first execution will fail--> the feature is not yet implemented
• Implement your feature
• Run the automated BDD scenarios to show the feature is completed
• Repeat
@Bria_Grangard

42. 42
Continuous Integration
@Bria_Grangard
• Making small changes to a single code repository that
multiple developers may be working on…. and integrating
those changes often
• Help avoid breakage rather than merging all your changes at once
• Benefits:
• Quicker identification of bugs
• Faster feedback loop
• Quicker deployments for customers
• Tools: Jenkins, CircleCI, TravisCI, Bamboo, etc.

43. 43
Typical CI Pipeline
Proprietary & Confidential
• Code and tests are committed to the repository
• Software is built using CI
• Service runs automated tests on the build
• Build fails à team is notified
• Build succeeds à software automatically deployed
* Can use a staging server if prefer to do final QA by hand
* Can have a CI server that test new GIT branches against the master branch

44. 44
Reduced Risk
-Identify and fix
defects immediately
More Confidence
-Reduced risk =
increase in
confidence
Greater Visibility
-Everyone can see the
project state--> better
feedback
Benefits of Continuous Integration
@Bria_Grangard

45. 4545
Living documentation is an up-to-date record of a feature that
defines test scenarios through a common language.
This way all team members can have current and accurate
information of the application in production—as well as an
archive of past test runs.
@Bria_Grangardhttps://hiptest.com/blog/living-documentation/why-living-documentation-is-important-in-bdd/

46. 46
Living Documentation
@Bria_Grangard
• Your tests already serve as documentation
• ”Living” because it’s up-to-date when tests are automated through CI/CD
pipeline
• An important part of the feedback loop
• Instrumental in keeping stakeholders, developers, and users on the same page
• Readable by both business and technical team members
• Shows exactly what the application is supposed to do… and proves
that it can do it

47. 47
Benefits of Living Documentation
@Bria_Grangard
Faster Updates Improved Support Better Workflow

48. 4848
Tools
@Bria_Grangard

49. 49
Resources & Tools
• Introducing BDD: https://dannorth.net/introducing-bdd/
• Step-by-Step BDD process: https://hiptest.com/behavior-driven-development/
• BDD hub: https://automationpanda.com/bdd/
• Discover Workshops: https://docs.cucumber.io/guides/bdd-tutorial/
• BDD & CI: https://www.agilealliance.org/glossary/bdd/
• Living Documentation: https://hiptest.com/blog/living-documentation/why-living-documentation-
is-important-in-bdd/

50. 50
BDD Misconceptions
@Bria_Grangard
1. BDD is an automation testing framework
2. BDD takes a long time
3. BDD introduces unnecessary steps
4. BDD is only for developers

51. 51
Key BDD Takeaways
TheSteps
1. Createafeature
• Inorderto[benefit]
• Asa[role]
• Iwant[feature[
2. Writeascenario
• Given
• When
• Then
3. Automate,ifyou’dlike
• Buildascalabletestautomationframework
• Implementyourfeature
• Repeat
What to Keep in Mind
1. Focus on the benefits of the feature
2. Be declarative when writing test
scenarios
3. Automate when it makes sense
4. Create a shared business terminology
5. Refactor where you can
6. Keep one single source of truth
@Bria_Grangard

52. 52
Final Words of Wisdom
Tips & tricks to ensure the health of your code
• Create shared business terminology across all scenarios
• Keep your terminology consistent when writing scenarios
• “I log in” vs. “I sign in” à do they have the exact same intent even though they’re written differently?
• This way… it becomes a common language shared by all team members
• Autocompletion tools can be helpful for reusing existing steps and terminology rather than
creating new steps and duplications
• Have the right refactoring capabilities to manage the impacts of changes on your test scenarios
• Steps with high reuse are often requiring changes/updates
• Find a tool, or method, to go about refactoring changesà example includes updates to
environments you’re going to be running your tests on
• Keep one single repository of manual and automated test scripts
@Bria_Grangard

53. 5353
We need to
avoid
building the
wrong
swing.
@Bria_Grangard

54. Appendix

55. Behavior-Driven Development:
(BDD)
a software development process where teams
create simple steps on how an application
should behave from a user’s perspective
Starting with the end in mind.
• TDD focuses on the developer’s view on how an software should work
• BDD focuses on the users’ view on how the application should behave
@Bria_Grangard

56. Additional Tips
Tips & tricks to ensure the health of your code
• Createsharedbusinessterminologyacrossallscenarios
• Keepyourterminologyconsistentwhenwritingscenarios
• “Ilogin”vs.“Isignin”àdotheyhavetheexactsameintenteventhoughthey’rewrittendifferently?
• Thisway…itbecomesacommonlanguagesharedbyallteammembers
• Autocompletiontoolscanbehelpfulforreusingexistingstepsandterminologyratherthancreatingnewsteps
andduplications
• Havetherightrefactoringcapabilitiestomanagetheimpactsofchangesonyourtestscenarios
• Stepswithhighreuseareoftenrequiringchanges/updates
• Findatool,ormethod,togoaboutrefactoringchangesàexampleincludesupdatestoenvironmentsyou’re
goingtoberunningyourtestson
• Keeponesinglerepositoryofmanualandautomatedtestscripts
*Photo taken from Laurent Py, Hiptest