Presentation by Kevin Dunne on "Making the Move to Behavior Driven Development" at STARWEST

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

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

3. Current Problems in
Software Dev & Test

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

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

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

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

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. Introducing Test-First
Methodologies

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

11. 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”)

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

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

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

15. 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/

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

17. 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/

18. Benefits of Test-First
Approaches

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

20. 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!

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

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

23. 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:

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

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

26. State of Test-First in
Industry

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

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

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

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

31. How Teams are Doing
BDD

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

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

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

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

36. Q&A

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