Successfully Implementing BDD in

an Agile World
 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

Agenda

Shift Left

The World of BDD

The BDD Process: People. Process, Tools

Question & Answer

@Bria_Grangard
 4

Shift Left Overview

@Bria_Grangard
Proprietary & Confidential
5

Software Has Traditionally Been Linear and Siloed

1 2 3 4
Business Developers QA Operations

Plan Develop Test Monitor

Design Document Deploy

@Bria_Grangard
 6

The promise of the new software delivery cycle

Waterfall
Design Build Test Implement
Agile
DevOps

Week 1 Week 2 Week 3 Week 4

@Bria_Grangard
 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

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

@Bria_Grangard
 9

Why the hype around Shift Left?

Testing Early,
Testing Often = Speed Quality Cost

Shorter cycles Fewer defects Cheaper to fix

@Bria_Grangard
 10
Traditional Software Development Lifecycle
Avg Cost of Defect $100 $250 $1500

Plan Design Develop Test Deploy Maintain

Cost to fix a defect ($)

Current Bug Discovery

Design Develop Test Operations

IBM Systems Sciences Institute @Bria_Grangard

 11
Shifting Everything Left
Plan
Develop

Test
Cost to fix a defect ($) Maintain

Current Bug Discovery

Shift Left Discovery

Design Develop Test Operations

IBM Systems Sciences Institute @Bria_Grangard

 12

Software
Development
is Hard
 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

Agile
Service
Virtualization Machine
BDD Learning

AI
TDD

DevOps
Shift Left
Automation
@Bria_Grangard
 15

How can teams Shift Left?

• Agile / DevOps Practices

• Virtualization
• API Testing
• Microservices
• CI/CD Processes
• BDD Workflows

@Bria_Grangard
 16

Sometimes… Agile can fall short

• Transient User Stories

• Ad-hoc Acceptance Criteria
• Limited Discovery
• No Overarching Tests
 17

How can teams shift Left?

• Agile / DevOps Practices

• Virtualization
• API Testing
• Microservices
• CI/CD Processes
• BDD Workflows

@Bria_Grangard
 18

BDD Overview

@Bria_Grangard
 19

@Bria_Grangard
 20

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

What is BDD?
The 3 Amigos

• Discovery, Formulation, and Automation

• Create a shared understanding based
Business
on examples
• Use the examples to drive development
• Create and share living documentation

Tester Developer

@Bria_Grangard
 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

BDD in Practice

Discovery Formulation Automation

@Bria_Grangard
 24

A quick aside… BDD vs. TDD

• 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

@Bria_Grangard
 25

Making the Move to BDD

Opportunities and Challenges

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

@Bria_Grangard
 26

In order to succeed you need to take a holistic approach

People Processes Tools

@Bria_Grangard
 27

Let’s start with people…

… it’s all about collaboration

@Bria_Grangard
 28

Roles

@Bria_Grangard
 Using a common Language 29

BDD Scenario

Business Development Test

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

@Bria_Grangard
 30

Process

@Bria_Grangard
 31

The BDD Process

@Bria_Grangard
 32

Deliberate Discovery

Goal: Try and learn as much as possible before

writing any code

Have conversations about user stories and

acceptance criteria using concrete examples

@Bria_Grangard
 33

Who should be involved in Deliberate Discovery?

• Product Owners
• Business Analysts
• Domain Experts
• Users
• Developers
• UX Designers
• Testers

@Bria_Grangard
 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

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

Record the Results

• Use Gherkin Syntax

• Create Executable
Specification without
code

@Bria_Grangard
 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

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

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

Step 2: Be Declarative When Writing Scenarios

• The Declarative Style of Writing—An Example

• Given I am logged in Why is this Declarative?

• When I add an item to the cart
• It doesn’t matter how someone did the
• And I click on the cart loginà username, password, touchID
• Then I should see the item I • What does matter: someone logged in
added

Declarative Example for HipTest & Slack

Given I have activated slack in the settings of my HipTest project

When I query /hiptest TestRunID from slack
Then I should see the breakdown of tests by statuses for testRunID
@Bria_Grangard
 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

Continuous Integration

• 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.

@Bria_Grangard
 43

Typical CI Pipeline

• 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

Proprietary & Confidential

 44

Benefits of Continuous Integration

Reduced Risk More Confidence Greater Visibility

-Identify and fix -Reduced risk = -Everyone can see the

defects immediately increase in project state--> better
confidence feedback

@Bria_Grangard
 45

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.

https://hiptest.com/blog/living-documentation/why-living-documentation-is-important-in-bdd/ @Bria_Grangard
 46

Living Documentation

• 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

@Bria_Grangard
 47

Benefits of Living Documentation

Faster Updates Improved Support Better Workflow

@Bria_Grangard
 48

Tools

@Bria_Grangard
 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

BDD Misconceptions

1. BDD is an automation testing framework

2. BDD takes a long time
3. BDD introduces unnecessary steps
4. BDD is only for developers

@Bria_Grangard
 51

Key BDD Takeaways

The Steps
1. Create a feature
• In order to [benefit] What to Keep in Mind
• As a [role] 1. Focus on the benefits of the feature
• I want [feature[ 2. Be declarative when writing test
2. Write a scenario scenarios
• Given 3. Automate when it makes sense
• When 4. Create a shared business terminology
• Then 5. Refactor where you can
3. Automate, if you’d like
6. Keep one single source of truth
• Build a scalable test automation framework
• Implement your feature
• Repeat

@Bria_Grangard
 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

We need to
avoid
building the
wrong
swing.

@Bria_Grangard
Appendix
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
Additional Tips

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

*Photo taken from Laurent Py, Hiptest