UW ADC - Course 3 - Class 1 - User Stories And Acceptance Testing

1,118 views
988 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,118
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
56
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

UW ADC - Course 3 - Class 1 - User Stories And Acceptance Testing

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

  2. 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. 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. 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


  5. 5. 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

  6. 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)

  7. 7. 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

  8. 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

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

  10. 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. 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. 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. 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

  14. 14. *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


  15. 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. 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


  17. 17. *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


  18. 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. 19. More
Guidelines
for
Spliqng
Stories
 •  Data
boundaries
 •  Opera6onal
boundaries
 •  Excep6ons
 •  Error
handling
 •  Removing
cross‐cuqng
concerns
 •  Priority

  20. 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

  21. 21. 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
  22. 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
  23. 23. What
does
FIT
test?
 •  Whatever
you
want…
 –  Business
rules
 –  Integra6on
points
 –  Business
services
 –  Workflows
 –  UI
steps

  24. 24. A
simple
example
of
a
FIT
test
 *Source: http://fit.c2.com/
  25. 25. 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/
  26. 26. 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/
  27. 27. Fit
Workflow*
 •  Delivery
team
suggest
addi6onal
areas
to
 cover

 *Source: http://fit.c2.com/
  28. 28. Fit
Workflow*
 •  Delivery
team
format
tables
for
use
with
Fit
 *Source: http://fit.c2.com/
  29. 29. 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/
  30. 30. Fit
Workflow*
 •  Execute
Fit
document
against
so>ware
 •  At
first
some
tests
may
be
failing
(red)
 *Source: http://fit.c2.com/
  31. 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/
  32. 32. 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/
  33. 33. Exercise:
 Acceptance
Tests
 Create
ini6al
acceptance
tests
using
 Fit
going
through
en6re
workflow.

  34. 34. How
does
FIT
work?
 Source: Alex Pukinskis – “Flawless Iterations” – Agile 2005
  35. 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. 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. 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. 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. 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/
  40. 40. 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

  41. 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. 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. 43. Executable
Requirements
 •  Unambiguous
defini6on
of
requirements
 •  Executable
documenta6on
 •  Repeatable
and
specific
 •  The
second‐most
detailed
specifica6on
of
the
 customer’s
request


  44. 44. 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

  45. 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


×