Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Avoiding Anger-Driven Development using BDD

Avoiding Anger-Driven Development using Behavior-Driven Development (BDD)
by

Jim Cornelius @jimcornelius

on 17 September 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Avoiding Anger-Driven Development using BDD

So WHAT can we do?! Shape? Square Round Heart-shaped! So why ARE developers angry? When communication isn't clear, developers and teams spend huge volumes of time reworking features.

Teams create, track, and fix "requirement defects", that lessen our ability to deliver in 1 Sprint. UNINTENTIONAL lack there of... ....so is everyone else. if we see it at all... Developers aren't the ONLY ones who are frustrated... Anger-Driven Development: One way to enhance communication Behavior-Driven Development Kim Merbeth - Business Analyst It's ALL about perspective Jim Cornelius - Systems Architect Jason Montague - Engineering Manager
@teradee @jimcornelius Business Analysts
Quality Assurance
Project Managers
Business Partners
Managers
Developers Who has experience with:

Agile - Scrum, Kanban, Lean, XP
Test Automation (Unit, UI)
TDD / ATDD
User Stories, Scenarios
Domain Specific Languages (DSLs)
BDD The Audience The Presenters Anger-Driven Development BDD Agenda Everyone is.... Some Examples Ubiquitous Language User Story + Acceptance Criteria = Ubiquitous Langauge USER STORY: Scenario: <Descriptive Title 1> The Value Proposition USER STORIES SCENARIOS act as SCENARIOS AUTOMATED TESTS help describe ACCEPTANCE CRITERIA BUSINESS VALUE describe USER STORY: USER STORY: ACCEPTANCE CRITERIA: ACCEPTANCE CRITERIA: Scenario: <Descriptive Title 1> Scenario: Descriptive Title 1 Given <a context>
When <an event occurs>
Then <ensure the intended outcome>
Given <a context>
When <an event occurs>
Then <ensure the intended outcome>
Scenario: Customer tries to view account when not logged in Given the customer is not logged in
When the customer attempts to view the account balance page
Then the customer should see the login page Given <a context>
When <an event occurs>
Then <ensure the intended outcome>
Scenario: Descriptive Title 2 Scenario: Customer tries to view account when logged in Scenario: Descriptive Title 3 Given the customer is logged in
When the customer attempts to view the account balance page
Then the customer should see their account balance Given <a context>
When <an event occurs>
Then <ensure the intended outcome>
Acceptance Criteria Automation #1 #2 #3 Scenarios literally become your acceptance tests and are RUN AUTOMATICALLY against the system Start with the Stakeholders Focus on Business Value Tests are the requirements written in every day language Outside-In If we see them AT ALL... ACCEPTANCE CRITERIA: Given <a context>
When <an event occurs>
Then <ensure the intended outcome>
Scenario: <Descriptive Title 3> Scenario: <Descriptive Title 2> Given <a context>
When <an event occurs>
Then <ensure the intended outcome>
Given <a context>
When <an event occurs>
Then <ensure the intended outcome>
Business Value As a <role>
I want <some action to be taken>
So that <I derive some business value> Title: <Feature> Title: View Account Information As a customer with a bank account and a web login,
I need to be able to log in and view my account information
So that at any time I can know how much money I have in my account Title: <Feature> As a <role>
I want <some action to be taken>
So that <I derive some business value> Scenario: Allow customer to Choose a Round OR Square shape Scenario: Attempt to go to Step 2 without choosing a shape
Given <one or more contexts connected by AND>
When <an event occurs>
Then <ensure the intended outcome> Scenario: Allow customer to Choose a Heart shaped pizza on Valentine's Day Title: Choose a Pizza Shape Given the customer is logged in to the pizza builder application,
When the customer chooses to build a custom pizza,
Then the customer should be able to choose a square shaped pizza
Or the customer should be able to choose a round shaped pizza USER STORY: As a PizzaBuilder.com customer,
I want to be able to choose a Round or Square shape
So that I can build my own custom pizza Given the customer is logged in to the pizza builder application
And the customer has not chosen a shape,
When the customer chooses to continue to step 2 (choose your size),
Then the customer should be asked to choose a pizza shape Given the account has sufficient funds
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Scenario: Customer gets cash from the ATM Also Appropriate! Example 3 Example 4 We often don't SEE things things in the same way... Communication Developers Don't Know Where to start
What to test
What not to test
How much to test Contributing Factors That testing is about DESIGN GIVEN the customer is logged in to the PizzaBuilder.com application,
WHEN the customer chooses to build a custom pizza,
THEN the customer should be able to choose a Square shaped pizza
OR the customer should be able to choose a Round shaped pizza Examples Scenario: Attempt to go to Step 2 without choosing a shape Scenario: Successfully choose a Round OR Square shape GIVEN the customer is logged in to the PizzaBuilder.com application
AND the customer has NOT chosen a shape,
WHEN the customer chooses to continue to Step 2 (choose a size),
THEN the customer should be asked to choose a pizza shape Given <one or more contexts connected by AND>
When <an event occurs>
Then <ensure the intended outcome> Example 2 Example 1 User Interface Databases, system of record, etc. How Much Value are we Delivering? YAGNI The Language of your Domain Standish Group CHAOS Report Scenarios/GWT Tests
(FitNesse) System Under Test
(the Pizza Builder Application) GIVEN the customer has chosen the | round | shape chooseShape("round")
isShapeValid("round")
THEN the customer should be able to choose a ginormous size pizza isSizeValid("round", "ginormous")
... chooseSize("ginormous")
true true false false FitNesse Scenarios Fixture Code (the Glue) Scenario: Don't allow a Heart shaped pizza if not Valentine's Day Key Tenets of The language of your business or domain Acceptance Test-Driven Development = Developers know when they are done
Outside-In Development = Focus on business value Ubiquitous Language = User Stories + Acceptance Criteria
Implement Just Enough
to Satisfy Acceptance Criteria TDD Write Test Test Fails Write Code
so Test Passes Refactor Typical Feature Utilization
on Non-Agile Projects Valentines Day
Special Result Scenario: Allow customer to Choose a Heart shaped pizza on Valentine's Day
Given the customer is logged into the pizza builder application
And the date is valentines day,
When the customer chooses to build a custom pizza,
Then the customer should be able to choose a heart shaped pizza Given the customer is logged into the pizza builder application
And the date is not valentines day,
When the customer chooses to build a custom pizza,
Then the customer should not be able to choose a heart shaped pizza Scenario: Don't allow a Heart shaped pizza if not Valentine's Day
Result BDD Wells Fargo Advantage Funds
Practicing BDD 18 months Half of our teams use test automation in the form of automated unit tests Have you ever felt FRUSTRATED:

Knowing how to write "Agile" requirements?
Knowing when you're DONE?
Arguing over "what was built" vs "what was asked for"?
By gold plating?
Interpreting what a legacy system CURRENTLY does using requirement specs?
Getting features DONE within a Sprint?





Defined / Coded / Tested / Deployed Implemented Agile ~ 3 years ago and has since become the "standard" Varying degrees of Agile experience Superfluous features built creates overhead and technical debt that is rarely addressed.

Relationships degrade into contract negotiations over collaboration.

(This isn't the entire story) TDD vs ATDD vs BDD Automated Unit Tests Automated Acceptance Tests Manual Tests QAs BAs Developers The Testing Pyramid Collaboration Test Maturity Model Create Automated Unit Tests Create Automated Acceptance Tests Continuous Integration - Builds Execute Automated Unit Tests Continuous Integration - Builds Execute Automated Acceptance Tests Adopting BDD - Key Success Factors You need individuals in the QA, BA and a technical roles that are willing to champion the concept and become experts and coaches. Start small (one team, one project). Too big too fast will surely fail. It's ok if you don't automate every scenario. Several of the same practices for writing good code apply to writing good tests such as pairing and building reuseable components. The champions need to embrace collaboration and be team players. Start with the maturity model. You need continuous integration. Your tests must be running all the time. Build Automation
Full transcript