ATDD And BDD The Great Beat Down…or…Debate

ATDD and BDD
The Great “Beat Down” …
or “Debate”
Bob Galen
bob@rgalen.com
Mary Thorn
marythorn@gmail.com

Copyright © 2016 RGCG, LLC 2
Introduction
Bob Galen
 Independent Agile Coach (CEC) at RGCG, LLC
 Principle Agile Evangelist at Velocity Partners
 Somewhere ‘north’ of 30 years overall experience 
 Wide variety of technical stacks and business domains
 Developer first, then Project Management / Leadership, then
Testing
 Senior/Executive software development leadership for 20+ years
 Practicing formal agility since 2000
 XP, Lean, Scrum, and Kanban experience
 From Cary, North Carolina
Bias Disclaimer:
Agile is THE BEST Methodology
for Software Development…
However, NOT a Silver Bullet!

Introduction
Mary Thorn
 Mary Thorn is the Director of Quality at Ipreo in Raleigh,
NC
 Mary has a broad testing background that spans
automation, data warehouses, and web-based systems
in a wide variety of technologies and testing techniques.
 During her more than seventeen years of experience in
healthcare, HR, agriculture, and SaaS-based products,
 Mary has held manager and contributor level positions
in software development organizations.
 She has a strong interest in agile testing methodologies
and direct experience leading and coaching agile teams
through Scrum adoption & beyond.
 Mary is also the Chief Storyteller in the book “The
Three Pillars of Agile Quality & Testing”.

Copyright © 2016 RGCG, LLC
Bob: The Stories
4

User Story
Construct
As a <role>
I want <system behavior>
So that I realize <some business value>
**And can see that it does <example>
5

User Stories
 3 Parts of a story, 3-C’s
by Ron Jeffries
 Card
 Conversation
 Confirmation
 Cards are intentionally vague
or incomplete in order to
foster conversation and an
emergent solution
 Confirmation (Acceptance
Tests) are the specific things
required to consider the story
‘done’ or acceptable to our
customer
High 15
As traveler I want to
get directions between
two points, so I can
get to my destination
• Verify I can enter addresses in all 50 states
• Verify directions can cross state boundaries
• Verify that directions are with +/- 5% mileage of MapQuest
• Verify that addresses can be swapped for return
• Verify that invalid addresses are handled w/error message
6

Product Owner Role:
Card : Conversation : Confirmation
 Front of card – describes the
Story characteristics – flexible
format
 1-2 sentences; short and
succinct
 I’ve seen limits of 5 words per
Story
 Could be task-oriented, a
milestone, simple work,
virtually anything the team
needs to do
 Don’t get too hung up on
‘phrasing’
As a dog owner, I want to sign-up
for a kennel reservation over
Christmas so that I get a
confirmed spot
As the Google Map interface,
setup a mechanism for frequent
Travelers to save and share their
maps, so that they save time
7

Product Owner Role:
 Product Owner must participate in defining ‘doneness’ criteria for card(s)
 Completed with heavy tester input and buy-in from all team members
 Unlike Cards, confirmations are normally quite specific
 Confirmations document what must be demonstrated to complete the story
 Confirmations are synonymous with Acceptance Tests
 Should try to automate them, perhaps using FitNesse or Cucumber?
Verify individual as a registered pet owner
Verify that preferred members get 15% discount on basic service
Verify that preferred members get 25% discount on extended services
and reservation priority over other members
Verify that past Christmas customers get reservation priority
Verify that declines get email with discount coupon for future services
8

Product Owner Role:
 Product Owner must be available
for the emergent solution
conversations
 Critical point of influence in the
design / construction phase
 Conversations as a team are the
most important component of the
‘3Cs’
 Should also consider actual
customers or other customer
proxies in the process as
appropriate
Should we present
all the user
selections as radio
button groups?
Lets story board that and see
what it looks like!
Great idea! I can work
on the acceptance test
criteria in parallel!
9

Acceptance Tests
 Story: Customer
withdraws cash
 As a customer,
 I want to withdraw cash
from an ATM,
 so that I don’t have to wait
in line at the bank.
Do the acceptance test spur
questions or conversations?
Examples?
 Acceptance Tests:
 Verify that customer
authentication works
 Verify that the customer is
limited to 3 transactions in an
ATM session
 Verify that sufficient balance is
in place to support the
transaction
 Verify that overall transaction
workflow take no longer than 5
minutes
 Verify that the transaction is
immediately viewable in the
customers online access
10

Testing Does Not…
 Come from the Acceptance Criteria, they are
 Business facing
 Value focused
 Priority focused
 They help:
 The developers with design, coding, functional & non-functional
requirements
 The testers with test case development, risk-based testing
prioritization
 They are NOT the primary or only tests!!!

Stories come from…
 Product Owner (individual)
 Story Writing workshop(s) with team
 Backlog Refinement (Grooming)

3-Amigos
 Coined by George Dinwiddie
 http://rgalen.com/agile-training-news/2014/4/13/3-amigos-in-agile-teams
 Swarming around the User Story by:
 Developer(s)
 Tester(s)
 Product Owner
 Conversation device – reminder for collaboration
amongst relevant team members
13

3-Amigos
 Often takes the form of a:
 Feature team
 Story owner team
 Surrounding the life-cycle of a story from:
 Story inception
 Epic writing
 Via Backlog Refinement:
 Iterative - Feature/Theme decomposition (estimation-driven)
 Iterative - Story emergence – Ready?

Remember -- The Triad
Collaboration
Customer
Developer Tester
Ken Pugh has written a book
on ATDD and uses the
“Triad” to amplify this
collaborative pairing between
roles…Product Owner is
central to that!
Collaboration
FIRST…
Automation
SECOND…

The KEY to ATDD is…
 It drives:
 Conversation, Collaboration, and Communication
Around the story, around what to test, and around the
working code.
 Automation or executable acceptance tests are a second
level concern!!!
 Now, Mary it’s your turn…

Mary: The Automation

In a nutshell, automated
acceptance tests are executable
examples that define the
system's specifications.
What are Automated Acceptance Tests?

Acceptance Tests are:
 Formal examples that define requirements.
 Executable.
 Self-explanatory and readable by all team members.
 Tests of business rules.
 A living specification of system behavior.

Acceptance Tests do NOT
 Test pieces of code in isolation. They are not a substitute for unit
and integration tests.
 Verify the entire system.
 Verify all permutations of a piece of functionality.
 Use mock objects except to remove a dependency on an external
3rd party.

Benefits:
 Higher quality b/c everyone shares the same understanding of the
requirements and builds it right the first time.
 Tests become the system's regression suite.
 Create an objective verification of “done-ness” for a story. A story is
done when all tests pass.
 Create transparency into progress on a story.
 Manual testers are part of the automation process.
 Allows for more exploratory testing b/c happy path is automated

Simple Example
Acceptance Criteria: Transactions are rounded to the
nearest cent.
Original Value Rounded Value
$0.021
$0.025
$0.029
$0.02
$0.02
$0.02

Simple Example
Why was there confusion?
The goal was missing...
Goal: Create a currency conversion system.
The Concrete Example clarified what was meant by the
acceptance criteria.
Refined Acceptance Criteria: Transactions are always
rounded down to the nearest cent.

Simple Example
 This simple example is a REAL EXAMPLE in a system
that was well-tested and approved by all parties.
 Attacker was able to steal > $15,000 starting with a
single cent using this process...
 $0.01 → 0.0051 € rounded to 0.01 €
 0.01 € → $0.0196 rounded to $0.02
 A seemingly minor ambiguity in the requirements was
very expensive.

Take Away’s
 Concrete examples drive understanding and
consensus.
 To create good representative examples, everyone
must understand the goal of the story.
 For technical people to properly understand the goal,
they must understand the business domain.

What does Cucumber have to
do with this?
Everything!!!
Ahhh…
The Automation

Cucumber
• Cucumber lets software development teams describe
how software should behave in plain text. The text is
written in a business-readable domain-specific
language and serves as documentation of
requirements, automated regression tests and
development-aid - all rolled into one format.
• Cucumber works with Ruby, Java, .NET, Flex or web
applications written in any language. It has been
translated to over 40 spoken languages.

Components:
• Cucumber (Framework)
• HTMLUnit (Browser Emulator)
• Selinium/Watir (Browser Emulator API)
• Features (Tests written in sentence format)
• Step Definitions (Backend code to support Features)
Automated Testing - Cucumber Framework

Automated Testing -Linking it all together
Command line –
Rake TAGS -
@abc
Cucumber
Framework - Tags
Feature File -
Sentence
Step Definition File –
Matching Sentence
Terminal
Result Output-
Browser Emulator Selinium/Watir –
Execute Command

Cucumber Feature Files
Keywords:
• Tests have reserved words that begin each line:
Given, When, Then, And, But.
• Use Given to state a precondition
• Use When & And when taking an action
• Use Then when asserting a validation
Scenario Outline: Verify Transactions are rounded to the nearest
cent.
Given I am on the order screen
When I make a transaction of 9.025
And save the transaction
Then the value should equal 9.02

Cucumber Example
@Cucumberpresentation
Feature: User would like to have a successful presentation
Tests the following acceptance criteria:
1. Verify the attendees are awake
2. Verify the attendees are happy with the presentation
@Attendeeawake
Scenario: Verify the attendees are awake
Given that I am an attendee
When I have drunk caffeine
Then I will be able to listen to the presenter
@Attendeeishappy
Scenario: Verify Attendees are happy
Given I am the presenter
When I talk slow
And my content is interesting
Then the attendees will be happy

 It drives:
 Executable Specifications, which drive conversation, but ALSO
code coverage, definitive examples, and Pass/Fail automation.
 Automation is the FIRST level concern!!!
Now, onto the Debate…

 Mary, what about the Story in the User Story?
 Bob, what about the promise of Product Owners writing
executable requirements?
 Bob, or the value of executable requirements?
 Mary, have you seen BDD miss the conversations?

Wrap-up
Final questions or discussion from attendees…
What do YOU think???
Thank you!
3434

Contact Info
Bob Galen
Principal Consultant,
RGalen Consulting Group, L.L.C.
Experience-driven agile focused training,
coaching & consulting
Cell: (919) 272-0719
bob@rgalen.com www.rgalen.com
bgalen@velocitypartners.net www.velocitypartners.net
Blogs
Project Times - http://www.projecttimes.com/robert-galen/
BA Times - http://www.batimes.com/robert-galen/
Podcast on all things ‘agile’ - http://www.meta-cast.com/
35Copyright © 2016 RGCG, LLC 35

ATDD And BDD The Great Beat Down…or…Debate

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (11)

Semelhante a ATDD And BDD The Great Beat Down…or…Debate

Semelhante a ATDD And BDD The Great Beat Down…or…Debate (20)

Mais de TEST Huddle

Mais de TEST Huddle (20)

Último

Último (20)

ATDD And BDD The Great Beat Down…or…Debate