2. 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
3. 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
4. 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
6. 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)
8. 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
10. 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
11. 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
12. 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
13. 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
15. *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
16. *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
18. *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
19. More Guidelines for Spliqng Stories
• Data boundaries
• Opera6onal boundaries
• Excep6ons
• Error handling
• Removing cross‐cuqng concerns
• Priority
20. 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
22. 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
31. 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/
35. 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
36. 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
37. 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
38. 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
39. 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/
41. 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
42. 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
43. Executable Requirements
• Unambiguous defini6on of requirements
• Executable documenta6on
• Repeatable and specific
• The second‐most detailed specifica6on of the
customer’s request
45. 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
