Embed Size (px)
Citation preview
Making the Move to Behavior-Driven DevelopmentKevin Dunne, VP of Business Development, QASymphony
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
Current Problems in Software Dev & Test
Where We Came From
Traditional development cycles often model the Rational Unified Process:
Source: http://www.psa-software.com/_img/_knowledge_center/rup.jpg
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
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
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
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
Introducing Test-First Methodologies
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
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”)
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
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
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
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/
Non-BDD – Define with Acceptance CriteriaAcceptance 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
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/
Benefits of Test-First Approaches
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 cycle2. Bake in Automation from Day 1 – protects against getting behind with test and
automation coverage3. Build More Testable Software – requires developers to think about testability,
and create more robust software4. Push to Customers When Ready – allows you to push software to customers
just in time, as it is developed
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!
Defect Costs Increase as Code Matures
Design Implementation Testing Maintenance0
20
40
60
80
100
120
Phase/Stage of the S/W Development in Which the Defect is Found
Cost of Resolving Defect
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 UITest 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
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:
UI Test
s
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 Test
s
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 ACode Feature B
Code Feature CTest Deploy
WaitWait
Code Feature ACode Feature B
Code Feature C
WriteTests
DeployDeploy
Deploy
State of Test-First in Industry
State of Test First – Respondent Overview
Most respondents are yet to implement TDD, or just getting started
Learning the Ropes Online
Most people are learning about TDD online, due to lack of good in-person content!
Struggling for Developer Buy-In
The biggest stumbling block continues to be getting developers to write tests
Transition to Agile First, Then TDD
Most organizations move to TDD after mastering Scrum/Kanban Agile approach
How Teams are Doing BDD
Scope •Define user story
Define Tests
•Write Acceptance Tests
Code Feature
s
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
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
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
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
Q&A
