University of Washington
Agile Developer Cer6ficate
Spring Quarter
Advanced Topics in Agile So>ware Development
Class #1: User Stories and Acceptance Tes6ng

User Stories
Story 14
As a customer I want to check my order
status online so that I can know when to
expect my package
A small piece of
business value
that can be
delivered in an
itera6on

Why User Stories?
• Agile Principle:
– “The most efficient and effec6ve method of conveying
informa6on to and within a development team is face‐to‐face
conversa6on”
• User Stories are insufficient to implement
without a conversa6on between the customer
and delivery team
• Describe ver6cal slices of func6onality
• Words need context to interpret; requirements
are interpreted out of context in many cases

What is a User Story?*
• CARD
– Token represen6ng the requirement. It's used in planning. Notes are
wriVen on it, reflec6ng priority and cost
• CONVERSATION
– The requirement itself is communicated from customer to
programmers through conversa6on (The conversa6on is largely verbal,
but is o>en supplemented with documents)
• CONFIRMATION
– The confirma6on provided by the acceptance test is what makes
possible the simple approach of card and conversa6on
– When the conversa6on about a card gets down to the details of the
acceptance test, the customer and programmer seVle the final details
of what needs to be done
* “Essen6al XP: Card, Conversa6on, Confirma6on” – Ron Jeffries
hVp://www.xprogramming.com/xpmag/EXPCardConversa6onConfirma6on.htm

A User Story Template (CARD)
• Describes the value of func6onality from a user’s
perspec6ve
User Story Template
As a <<user role>>
I want to <<do something>>
so that <<value/benefit>>
• User Role – a user of the product
• Do Something – feature user needs
• Value/Benefit – why feature is important

The INVEST Model
I – N – V – E – S – T
• I = Independent ‐ dependencies reduce agility
• N = Nego6able ‐ nego6a6on breeds collabora6on
• V = Valuable ‐ valuable to the Product Owner,
client, customer and user
• E = Es6mable ‐ stories are planning tools
• S = Sized Appropriately ‐ can be predictably
completed and delivered
• T = Testable ‐ story (acceptance) tests define
when we are “done”
Source: adapted from Bill Wake, xp123.com (h<p://xp123.com/xplor/xp0308/index.shtml)

Types of User Stories
• Epic – a user story that has not been decomposed
to meet INVEST model because it is lower priority
• Theme – a collec6on of related user stories
• An Epic is a Theme when split into smaller User
Stories

Interconnec6ons of a User Story
EsHmates
User Story
Value • Card
• Conversa6on User PerspecHve
• Confirma6on
And Focus
Domain Model, Incremental
System Metaphor, Delivery
Glossary of Terms The Right Define Done
ConversaHon

Exercise: User Story Wri6ng
Write User Stories for the JiVer web
applica6on.
ID 8.5

Acceptance Tests
• Tell us whether the system does what the
customer expects
• Enable Developers to know they’ve sa6sfied
requirements
• Helps us build the “right” so>ware
• Are also called customer tests or func6onal tests
• Can be automated so these can be
verified by anyone at any 6me
• “Running, Tested Features”*
* Adapted from “A Metric Leading to Agility” – Ron Jeffries
hVp://www.xprogramming.com/xpmag/jatRtsMetric.htm

Confirma6on Through Acceptance
Criteria
• Product Owner makes first pass at Acceptance Criteria before
Sprint Planning Mee6ng
• During Sprint Planning, Acceptance Criteria are discussed
• Final Acceptance Criteria for each User Story is a nego6a6on
between Delivery Team and Product Owner
• Should be short, easy to understand statements
Story 14
Acceptance Criteria
As a customer, I want to check my • View status as “wai6ng for pickup”,
“en route” or “delivered”
order status online so that I can
• Date of each step in route
know when to expect my package • Es6mated 6me of delivery

Comparing Acceptance Criteria to
Defini6on of Done
DefiniHon of Done: Helps us build Acceptance Criteria: Helps us build
the thing right (deliverables) the right thing (funcHonality)
Acceptance Criteria
• View status as “wai6ng for pickup”,
“en route” or “delivered”
• Date of each step in route
• Es6mated 6me of delivery

User Story “Smells”
• Split along process lines
– Design, code, test, document
• Split across architecture lines
– Database, Business Tier, UI
• Split along procedural lines
– Do this, then this, and finally
this
• Hard to understand fully
• Customer value is not clear

*Requirement to User Story – A Case Study
• Our star6ng requirement:
Story 1
Anyone can register by paying
immediately with PayPal
* Modified from original ar6cle by J.R. Rainsberger ‐ hVp://www.jbrains.info/weblog/browse/9

*Requirement to User Story – A Case Study
• Maybe break it along process lines?:
Story 1.1
Story 1.2
Design: Anyone can register by Code: Anyone can register by
paying immediately with PayPal paying immediately with PayPal
Story 1.3
Story 1.4
Unit Test: Anyone can register Func6onal Test: Anyone can
by paying immediately with register by paying immediately
PayPal with PayPal
* Modified from original ar6cle by J.R. Rainsberger ‐ hVp://www.jbrains.info/weblog/browse/9

*Requirement to User Story – A Case Study
• Maybe break it along architecture lines?:
Story 1.1
Story 1.2
UI: Anyone can register by Business Logic: Anyone can
paying immediately with PayPal register by paying immediately
with PayPal
Story 1.3
Story 1.4
Database: Anyone can register QA: Anyone can register by
by paying immediately with paying immediately with PayPal
PayPal
* Modified from original ar6cle by J.R. Rainsberger ‐ hVp://www.jbrains.info/weblog/browse/9

*Requirement to User Story – A Case Study
• Maybe break it along procedural lines?:
Story 1.1
Story 1.2
Collect registra6on informa6on Integrate with PayPal
Story 1.3
Story 1.4
Email registrant a>er payment Email organizer a>er payment
* Modified from original ar6cle by J.R. Rainsberger ‐ hVp://www.jbrains.info/weblog/browse/9

*Requirement to User Story – A Case Study
• Aha, self‐contained increments of value…
Story 1.1
Story 1.2
As a Registrant I want to As an Organizer I want to
register with my email so that I collect more informa6on from
can be no6fied electronically Registrant so that I can contact
them later
Story 1.3
Story 1.4
As a Registrant I want to be As an Organizer I want to be
no6fied of my processed no6fied of a registra6on so that
registra6on so that I know it is I can fulfill it
complete
* Modified from original ar6cle by J.R. Rainsberger ‐ hVp://www.jbrains.info/weblog/browse/9

More Guidelines for Spliqng Stories
• Data boundaries
• Opera6onal boundaries
• Excep6ons
• Error handling
• Removing cross‐cuqng concerns
• Priority

Avoid spliqng stories too soon
• Don’t split stories too soon
– Results in huge inventory on Product Backlog (waste)
– Iner6a sets in and clogs system
– Many details will likely be thrown out, resul6ng in
“sunk costs”
• Progressively elaborate stories based on
– Priority
– Risk
• Effec6vely spliqng stories is a joint effort
– Product Owner, Stakeholders
– Team

The need for FIT
FIT: Framework for Integrated Tests
• Created by Ward Cunningham
• Allows customers, testers, and programmers to learn what their so>ware
should do and what it does do.
• Automa6cally compares customers' expecta6ons to actual results
• Simple table format
• Easy for everyone to understand and maintain tests
• Powerful framework to test almost anything the business cares about
• Book: “FIT for Developing So>ware” (Mugridge, Cunningham)
hVp://www.amazon.com/Fit‐Developing‐So>ware‐Framework‐Integrated/dp/0321269349/
http://fit.c2.com

FIT or FitNesse?
• FIT: core framework for tes6ng
– Command‐line tool: easily scriptable
– Tests are Word or Excel documents saved as HTML
• FitNesse: Web‐based frontend for FIT
– Easily accessible to anyone
– Tests are Wiki pages
– Helps organize tests into suites
Source: Alex Pukinskis – “Flawless Iterations” – Agile 2005

What does FIT test?
• Whatever you want…
– Business rules
– Integra6on points
– Business services
– Workflows
– UI steps

A simple example of a FIT test
*Source: http://fit.c2.com/

Fit Workflow*
• Starts with whiteboard conversa6on
• Customer (SME, business person, product
manager, etc.) informally describe new feature
• Programmers and testers ask ques6ons
*Source: http://fit.c2.com/

Fit Workflow*
• Customer, working with delivery team, refines
examples into tables
• Use business‐friendly tools, such as Microso>
Excel and Word, to capture test tables
*Source: http://fit.c2.com/

Fit Workflow*
• Delivery team suggest addi6onal areas to
cover
*Source: http://fit.c2.com/

Fit Workflow*
• Delivery team format tables for use with Fit
*Source: http://fit.c2.com/

Fit Workflow*
• Delivery team creates Fit “fixtures” (small
piece of code that translates test tables into
execu6on tests against the so>ware)
*Source: http://fit.c2.com/

Fit Workflow*
• Execute Fit document against so>ware
• At first some tests may be failing (red)
*Source: http://fit.c2.com/

Fit Workflow*
• Delivery team
collaborates with
customer to
incrementally
enhance test
tables
• Delivery team
implements
so>ware to meet
test execu6on
(green)
*Source: http://fit.c2.com/

Fit Workflow*
• Document is kept for regression tes6ng
• Document is included in automated build to
ensure everything keeps working
• As ques6ons arise about func6onality an
example is added and Fit reports the answer
*Source: http://fit.c2.com/

Exercise:
Acceptance Tests
Create ini6al acceptance tests using
Fit going through en6re workflow.

How does FIT work?
Source: Alex Pukinskis – “Flawless Iterations” – Agile 2005

How deep/wide to
test with Fit?
• Best used for “business rules”
• Just under UI layer
• Can test UI workflow but briVle (UI changes occur more o>en)
• Test service interfaces (SOA, J2EE, …)
• Define how system should handle situa6ons
• Acceptance tests should test integrated system

ColumnFixture
• ColumnFixture maps columns to fixture elements
• Great for tes6ng calcula6ons
• Abstract ‐ doesn’t define how business rule is used
• Generally the least briVle tables
eg.Calculator
key x() flash()
100 100 false
enter 100 false
0 0 false
/ 0 true *Source: http://fit.c2.com/
clx 0 false

RowFixture
• RowFixture compares rows in test data to results
from system under test
• Returned values compared to those in table
• Algorithm matches rows with system results
based on one or more keys
Times
task total time total billing
background 8:00 0.00
stqe 6:00 0.00
usda 0:00 0.00 *Source: http://fit.c2.com/
conference 10:00 1500.00

Ac6onFixture
• Ac6onFixture interprets rows as sequence of commands performed in
order
• First column contains command
• Subsequent columns contains values interpreted by command
• Generic Ac6onFixture commands are:
– start aClass ‐ directed to instance of aClass, similar to naviga6ng to a par6cular
GUI screen
– enter aMethod anArgument ‐ invoke aMethod with anArgument, similar to
entering values into GUI fields
– press aMethod ‐ invoke aMethod with no arguments, similar to pressing GUI
buVon
– check aMethod aValue ‐‐ invoke aMethod with no arguments, compare
returned value with aValue, similar to reading values from GUI screen

Ac6onFixture example
• Searching for music…
eg.music.Realtime
enter select 2 pick an album
press same album find more like it
check status searching
await search complete
check status ready
check selected songs 2
*Source: http://fit.c2.com/

Bringing it all together
• Use sequences of tables
• Build/Operate/Check PaVern (
hVp://fitnesse.org/ )
– One or more tables to build test data
(ColumnFixture)
– Use table to operate on data
– Use ColumnFixture or RowFixture to verify the
results
• Clean up data created

FitLibrary Addi6onal Fixtures
• Common Fit usage paVerns provided by
framework
• Allows more sophis6cated tests
– DoFixture ‐ tes6ng ac6ons on domain objects
– SetupFixture ‐ repe66ve data entry at start of test
– CalculateFixture ‐alterna6ve to ColumnFixture
– ArrayFixture ‐ ordered lists handled automa6cally
– SubsetFixture ‐ test specific elements of a list
• Can operate directly on system components
without wri6ng custom fixtures

Organizing FIT tests
• Maintain suite of regression tests from past
itera6ons that always pass
• Run “regression” tests with build.
• Maintain a suite of “in progress” tests for the
current itera6on
– Begin the itera6on with all tests failing
– End the itera6on with most tests passing
• At the end of the itera6on, move newly passing
tests into regression suite
– Beware the Fitnesse “Refactor/Move” command

Executable Requirements
• Unambiguous defini6on of requirements
• Executable documenta6on
• Repeatable and specific
• The second‐most detailed specifica6on of the
customer’s request

Other Agile Tes6ng Tools
• Open Source Web UI Tes6ng tools
– StoryTestIQ
– WATiR
– Selenium
– Canoo Web Test
• Go the “last mile” to verify things fit together
• Tests wriVen and maintained incrementally
• Tend to be more briVle

What about tradi6onal tes6ng tools?
• Why don’t we use SilkTest, TestDirector, QuickTest
Pro, etc. for Agile tes6ng?
– Expensive
– Automated tools are record‐and‐playback; briVle
– Ties our tests to the UI implementa6on
– Manual tools (TestDirector) take too long to run.
– Work fine as an interim strategy (especially if you
already have the licenses)
– Consider adding FIT as a component of your tes6ng