Behavior-driven development (BDD) is a hot topic in the development community. Not only does a properly implemented BDD process help drive increased automation and quicker development cycles, it also facilitates better collaboration between departments and reduces siloed communication. An ideal partner of continuous integration/delivery, BDD can help solve many testing bottlenecks associated with DevOps. For all its benefits, BDD is underadopted. Only 10–25 percent of development organizations have implemented or are experimenting with a BDD process. Organizations are hesitant to transition to BDD from their current approach for many reasons, typically focusing on people, process, and technology changes. Kevin Dunne presents a successful framework for considering any potential roadblocks, evaluating your readiness for change, and making a seamless transition. Agile is an approach centered around continuous improvement, and Kevin provides plenty of takeaways for teams who are just learning about BDD, for teams who have undergone a stable transition—and for those teams that are somewhere in between.

1.
T2
Test
Techniques
10/6/16
9:45
Making
the
Move
to
Behavior-­‐Driven
Development
Presented
by:
Kevin
Dunne
QASymphony
Brought
to
you
by:
350
Corporate
Way,
Suite
400,
Orange
Park,
FL
32073
888-­‐-­‐-­‐268-­‐-­‐-­‐8770
·∙·∙
904-­‐-­‐-­‐278-­‐-­‐-­‐0524
-­‐
info@techwell.com
-­‐
http://www.starwest.techwell.com/

2.
Kevin
Dunne
As
the
VP
of
strategy
and
business
development
at
QASymphony,
Kevin
Dunne
ensures
their
continued
commitment
to
innovation
and
delivering
tools
to
create
better
software.
With
a
deep
interest
in
the
emerging
trends
in
software
development
and
testing,
he
is
dedicated
to
collaborating
with
thought
leaders
in
this
space.
Kevin
comes
to
QASymphony
from
Deloitte,
where
he
managed
testing
on
large
government
and
Fortune
500
engagements
delivering
ERP
implementations
and
custom
software
development.
As
one
of
QASymphony's
first
employees,
Kevin
has
seen
many
sides
of
the
companyÛÓfrom
sales
and
customer
support
to
marketing
and
product
management.

3. Making the Move to Behavior-
Driven Development
Kevin Dunne, VP of Business Development, QASymphony

4. AGENDA
• Understanding typical software development and testing challenges
• Introduce BDD methodologies
• Benefits of implementing test-first methodologies
• Review the state of test-first methodologies in industry
• Investigate keys for successful implementation BDD
• Q&A

5. Current Problems in
Software Dev & Test

6. Where We Came From
Traditional development cycles often model the Rational Unified Process:
Source: http://www.psa-software.com/_img/_knowledge_center/rup.jpg

7. The Broken Game of Telephone
Running the processes in parallel introduces the risk as the requirements get
handed off multiple times and customer expectations change with time:
Source: http://lh5.ggpht.com/_g0-GZzIBNms/SloJ3LOGy3I/AAAAAAAAAK0/FvyLacg_Q28/s800/conversations.pngg

8. Why QA Breaks Down in Agile
QA kept out of the loop
QA are unable to complete tests when
needed
Dev and QA working on different
cadences
Lack of visibibility or understanding into
when QA is “Done” with testing

9. The “Old Way” was the Best Way at the Time
We would have obviously chosen a more efficient process, but we were
constrained by many limitations, including:
Environment Creation Code Merges On-Premise Prevalence
Desktop Focus Lack of Collaboration Off-Shore Development

10. What’s Changed
Many of our prior limitations have been replaced, based on macro trends around
technology and industry:
Containers have simplified the process dramaticallyEnvironment Creation
Git has replaced Subversion as the industry standardCode Merges
Cloud adoption is at an all time high, increased securityOn-Premise Prevalence
Prevalence of Web, Mobile, Internet of thingsDesktop Focus
Increase in teamwork, chat and collaboration technologyLack of Collaboration
Shifts towards rural sourcing, onshoring of laborOff-Shore Development

11. Introducing Test-First
Methodologies

12. How the Process Has Adapted
Now that we have freed ourselves of past limitations, the process has been shifted
to one that aligns more with our needs:
Traditional Approach
Test-First Approach
Design Requirements Code Test Deploy
Design (Automated) Test Code Refactor Deploy

13. TDD vs. ATDD vs. BDD
Test-First methodologies were coined “Test Driven Development”. Less
technically focused versions called Acceptance Test Driven Development (ATDD)
and Behavior Driven Development (BDD) also emerged:
Test Driven Development
(TDD)
Behavior Driven Development (BDD)
Acceptance Test Driven Development
(ATDD)
Unit Test Driven Development
(“Technical TDD”)

14. What’s the Difference?
ATDD and BDD are similar in that they both try to make TDD more accessible to business users.
The major functional difference comes down to how the tests are structured:
"I think this definition leaves out a key piece, we are focusing on collaboration
and learning. Having worked on a project that was using 'ATDD', in 2005 I
think, we had the same goals then as BDD without the Given When Then
language.“
— Wes Williams

15. Pros and Cons
ATDD/BDD offer benefits over more Unit Focused/Technical TDD, but also has its
drawbacks:
Pros
• Increased understanding of tests from
business stakeholders
• Increased collaboration early in the cycle
• More focus on customer and business needs
• Higher involvement of business in
development and quality
Cons
• Addition of more tooling in the development/delivery
chain
• Greater time spent defining tests and specifications
• Demands stronger contributors in requirements, dev,
test
• Often increases the automation needs in an
organization

16. Typical BDD Planning Hierarchy
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Epic: ATM Software
Story : Withdraw Cash Story : Check Balance
Acceptance Test: Overdraft
Epic: Online Banking Portal

17. User Stories Define the Discrete Units of Work
The user story is the “What” or the high
level ask the business has for the
development team
User Stories often still exist with BDD, as
a framework for adding scenarios. Some
companies would change User Stories to
being called features.
Example:
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
Source: https://dannorth.net/introducing-bdd/

18. Non-BDD – Define with Acceptance Criteria
Acceptance criteria are used to define the
User Story in a detailed manner
While acceptance criteria are easy to write,
they are often vague or incomplete
Additionally, users typically need to write
acceptance tests to validate the criteria pass
Example:
- Cash dispensed in less than 10 seconds
- Cash dispensed matches amount requested
by customer
- American express cards not accepted
- Overdrafted accounts rejected for withdrawal

19. The BDD Way - Acceptance Tests
Verify the work: Acceptance tests evaluate
the acceptance criteria using the “Given-
When-Then” format.
Example:
Scenario: Overdrawn accounts cannot withdraw
money
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
Source: https://dannorth.net/introducing-bdd/

20. Acceptance Test Example
Example:
Given the customer has navigated to the
billing page
When the customer clicks on “Update Billing
Information” and clicks “Change Address,”
Then: the customer is presented with a form
to enter a new address.
Example based on Acceptance Criteria:

21. Benefits of Test-First
Approaches

22. How Can TDD Help Us?
Test Driven Development brings several major benefits to organization,
most notably:
1. Move Testing Up Front – prevents having to rush testing at the end of the cycle
2. Bake in Automation from Day 1 – protects against getting behind with test and automation
coverage
3. Build More Testable Software – requires developers to think about testability, and create
more robust software
4. Push to Customers When Ready – allows you to push software to customers just in time, as
it is developed

23. Move Testing Up Front
Moving Testing Up Front removes the risk of having to make compromises at the end of the cycle on quality
or on-time delivery:
Traditional Development Timeline
Ends on: Day 1 Day 3 Day 14 Day 20 Day 21
Design Requirements Code Test Deploy
There is risk in this process that any process, typically Code, will run over and either squeeze
development, or push release dates. TDD removes it!

24. Defect Costs Increase as Code Matures
0
20
40
60
80
100
120
Design Implementation Testing Maintenance
Phase/Stage of the S/W Development in Which the Defect is Found
Cost of Resolving Defect

25. Bake in Automation Up Front
In traditional development, automation is often built after the code is developed, which has significant
limitations:
Test development is more costly, since we cannot access the code to make it more testable (more details to
come)
Tests are slower and more brittle, with higher levels of maintenance, if we can only access the UI
Test coverage is incomplete, as we must chose strategically where to build out automation coverage
Moving to TDD flips the process and forces developers to write code to satisfy tests, increasing automation
coverage, speed, and reducing cost

26. Build for Testability
Source: http://zeroturnaround.com/wp-content/uploads/2015/12/PUZZLE-1-min.png
Moving towards BDD will force your
developers to build an application that
can be tested well at the Unit,
Integration, and UI levels:

27. UI Tests
Integration Tests
Unit Tests
Building a Complete Testing Strategy
Moving towards BDD will also demand a more complete testing strategy focused
on more than just UI testing:
UI Tests
Integration Tests
Unit Tests

28. Push Features When They Are Complete
TDD paired with continuous delivery will allow you to push features as they
become ready, if you’d like to:
Old Way
New Way
Code Feature A
Code Feature B
Code Feature C
Test Deploy
Wait
Wait
Code Feature A
Code Feature B
Code Feature C
Write
Tests
Deploy
Deploy
Deploy

29. State of Test-First in
Industry

30. State of Test First – Respondent Overview
Most respondents are yet to implement TDD, or just getting started

31. Learning the Ropes Online
Most people are learning about TDD online, due to lack of good in-person content!

32. Struggling for Developer Buy-In
The biggest stumbling block continues to be getting developers to write tests

33. Transition to Agile First, Then TDD
Most organizations move to TDD after mastering Scrum/Kanban Agile approach

34. How Teams are Doing
BDD

35. Scope •Define user
story
Define
Tests
•Write
Acceptance
Tests
Code
Features
Build •Build the
latest code
Run
Tests
•Execute
acceptance
tests
Tools Our Customers Are Using
IF PASSED:
Report results
back to User
Story
OR
Refactor
IF FAILED:
Change Code

36. Benefits to the Organization
Increased team collaboration and morale
Expanded test coverage
Reduced time to execute or maintain regression
Enhanced reusability of testing assets
Organization wide interest in quality

37. Implementation Models
There are different implementation models with different pros and cons:
Train the Trainer Phased Rollout Big Bang
Dev Dev Dev
QA PO Ops
SMTeam A
Dev Dev Dev
QA PO Ops
SMTeam A
Dev Dev Dev
QA PO Ops
SMTeam A
Dev Dev Dev
QA PO Ops
SMTeam A
Dev Dev Dev
QA PO Ops
SMTeam A
Dev Dev Dev
QA PO Ops
SMTeam A
Increased Risk, Increased Reward

38. Keys To Success
• Be patient, success will take time
• Do a real assessment of talent BEFORE you embark on a journey towards BDD
• Identify one or multiple champions with strong personalities and rapport
• Define success criteria using metrics that matter to you
• Start smaller where risks are minimized
• Don’t be afraid to ask for help and seek guidance online or from in person consultants

39. Q&A

40. THANK YOU
Kevin Dunne
kevindunne@qasymphony.com
www.qasymphony.com