O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
University
of
Washington

Agile
Developer
Cer6ficate

                 Spring
Quarter

Advanced
Topics
in
Agile
So>ware
Dev...
User
Stories

       Story 14
        As a customer I want to check my order
       status online so that I can know when ...
Why
User
Stories?

•  Agile
Principle:

   –  “The
most
efficient
and
effec6ve
method
of
conveying

      informa6on
to
and
w...
What
is
a
User
Story?*

•    CARD

      –  Token
represen6ng
the
requirement.
It's
used
in
planning.
Notes
are

         ...
A
User
Story
Template
(CARD)

•  Describes
the
value
of
func6onality
from
a
user’s

   perspec6ve

          User Story Te...
The
INVEST
Model

      I
–
N
–
V
–
E
–
S
–
T

      •  
I
= 
Independent
‐
dependencies
reduce
agility

      •  N
= 
Neg...
Types
of
User
Stories

•  Epic
–
a
user
story
that
has
not
been
decomposed

   to
meet
INVEST
model
because
it
is
lower
pr...
Interconnec6ons
of
a
User
Story

                                            EsHmates




                           User ...
Exercise:
User
Story
Wri6ng



          Write
User
Stories
for
the
JiVer
web

                      applica6on.




ID
8....
Acceptance
Tests

•  Tell
us
whether
the
system
does
what
the

   customer
expects

•  Enable
Developers
to
know
they’ve
s...
Confirma6on
Through
Acceptance

              Criteria

•  Product
Owner
makes
first
pass
at
Acceptance
Criteria
before

   ...
Comparing
Acceptance
Criteria
to

           Defini6on
of
Done

DefiniHon
of
Done:
Helps
us
build
   Acceptance
Criteria:
He...
User
Story
“Smells”

•  Split
along
process
lines

   –  Design,
code,
test,
document

•  Split
across
architecture
lines
...
*Requirement
to
User
Story
–
A
Case
Study


•  Our
star6ng
requirement:

                                Story 1
         ...
*Requirement
to
User
Story
–
A
Case
Study


•  Maybe
break
it
along
process
lines?:

Story 1.1
                           ...
*Requirement
to
User
Story
–
A
Case
Study

 •  Maybe
break
it
along
architecture
lines?:

Story 1.1
                      ...
*Requirement
to
User
Story
–
A
Case
Study

•  Maybe
break
it
along
procedural
lines?:

Story 1.1
                         ...
*Requirement
to
User
Story
–
A
Case
Study

•  Aha,
self‐contained
increments
of
value…

Story 1.1
                        ...
More
Guidelines
for
Spliqng
Stories

•    Data
boundaries

•    Opera6onal
boundaries

•    Excep6ons

•    Error
handling...
Avoid
spliqng
stories
too
soon

•  Don’t
split
stories
too
soon

   –  Results
in
huge
inventory
on
Product
Backlog
(waste...
The
need
for
FIT

FIT:
Framework
for
Integrated
Tests

•  Created
by
Ward
Cunningham

•  Allows
customers,
testers,
and
pr...
FIT
or
FitNesse?

  •  FIT:
core
framework
for
tes6ng

         –  Command‐line
tool:
easily
scriptable

         –  Tests...
What
does
FIT
test?

•  Whatever
you
want…

  –  Business
rules

  –  Integra6on
points

  –  Business
services

  –  Work...
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.)
informa...
Fit
Workflow*

•  Customer,
working
with
delivery
team,
refines

   examples
into
tables

•  Use
business‐friendly
tools,
su...
Fit
Workflow*

•  Delivery
team
suggest
addi6onal
areas
to

   cover






                                *Source: http://...
Fit
Workflow*

•  Delivery
team
format
tables
for
use
with
Fit





                                  *Source: http://fit.c...
Fit
Workflow*

•  Delivery
team
creates
Fit
“fixtures”
(small

   piece
of
code
that
translates
test
tables
into

   execu6o...
Fit
Workflow*

•  Execute
Fit
document
against
so>ware

•  At
first
some
tests
may
be
failing
(red)





                   ...
Fit
Workflow*

         •  Delivery
team

            collaborates
with

            customer
to

            incrementally...
Fit
Workflow*

•  Document
is
kept
for
regression
tes6ng

•  Document
is
included
in
automated
build
to

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


•  ...
ColumnFixture

•    ColumnFixture
maps
columns
to
fixture
elements

•    Great
for
tes6ng
calcula6ons

•    Abstract
‐
does...
RowFixture

•  RowFixture
compares
rows
in
test
data
to
results

   from
system
under
test


•  Returned
values
compared
t...
Ac6onFixture

•  Ac6onFixture
interprets
rows
as
sequence
of
commands
performed
in

   order


•  First
column
contains
co...
Ac6onFixture
example

•  Searching
for
music…


                               eg.music.Realtime

enter              selec...
Bringing
it
all
together

•  Use
sequences
of
tables

•  Build/Operate/Check
PaVern
(

   hVp://fitnesse.org/
)

  –  One
o...
FitLibrary
Addi6onal
Fixtures

•  Common
Fit
usage
paVerns
provided
by

   framework

•  Allows
more
sophis6cated
tests

 ...
Organizing
FIT
tests

•  Maintain
suite
of
regression
tests
from
past

   itera6ons
that
always
pass

•  Run
“regression”
...
Executable
Requirements

•    Unambiguous
defini6on
of
requirements

•    Executable
documenta6on

•    Repeatable
and
spec...
Other
Agile
Tes6ng
Tools

•  Open
Source
Web
UI
Tes6ng
tools

   –    StoryTestIQ

   –    WATiR

   –    Selenium

   –  ...
What
about
tradi6onal
tes6ng
tools?

•  Why
don’t
we
use
SilkTest,
TestDirector,
QuickTest

   Pro,
etc.
for
Agile
tes6ng?...
Próximos SlideShares
Carregando em…5
×

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

1.448 visualizações

Publicada em

Publicada em: Tecnologia
  • ⇒⇒⇒WRITE-MY-PAPER.net ⇐⇐⇐ has really great writers to help you get the grades you need, they are fast and do great research. Support will always contact you if there is any confusion with the requirements of your paper so they can make sure you are getting exactly what you need.
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/9uLeB ◀ ◀ ◀ ◀
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • If we are speaking about saving time and money this site ⇒ www.WritePaper.info ⇐ is going to be the best option!! I personally used lots of times and remain highly satisfied.
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Yes you are right. There are many research paper writing services available now. But almost services are fake and illegal. Only a genuine service will treat their customer with quality research papers. ⇒ www.HelpWriting.net ⇐
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • The professtional essay writer are having more knowledege about the writing papers. The professional essay writer are providing the best essay writing services papers to the students. The writeersity writing company had to providing the more writing papers for the professtionalist. The papers should be very quality and possible to acedemic success. ⇒ www.HelpWriting.net ⇐ Good luck!
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

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


×