Slides from the London Agile Testing Meetup of November 25 2014: John Ferguson Smart is a specialist in BDD, automated testing and software life cycle development optimization. John is a well-known speaker at many international conferences and events and an accomplished author (John's new book BDD in Action was published last month). John presents a talk discussing how to write solid, reliable and maintainable automated web tests using the best-of-breed open source technologies like Selenium WebDriver, Serenity, JBehave and Cucumber.

1. Demo BDD in Action
John Ferguson Smart
Wakaleo Consulting

2. Miyamoto
Musashi
Japan
1584
–
1645

3. Consultant
Tr a i n e r
Mentor
Author
Speaker
Coder
John Fer guson Smar t

4. What
is
BDD
A
typical
BDD
workflow
What
tools
should
I
use?
Effec@ve
BDD
automa@on
BDD
Gotchas

5. So what is this BDD thing?
Using examples
a shared understanding
software that matters

6. Building the right software
Hunting out value Automated Acceptance
BDD
Criteria
API and code design
Collaboration
Living Documentation
Building the software right

7. The business owner
tells the business
analyst what he wants
1
2 The business
analyst writes a
requirements
document
3 The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
BDD in a nutshell
A traditional development process

8. The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
The business analyst,
the developer and the
tester elaborate the
requirements together.
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-language
format
"scenarios"
•Specifica@ons
are
elaborated
collabora@vely
•Specifica@ons
use
a
common
language
•Executable
specifica@ons
provide
fast
feedback

9. Benefits of BDD
BDD
BDD
in
the
real
world
-­‐
an
example

10. BDD Gotchas
1
2
3
An@-­‐paKern
1
The
business
analyst
writes
the
scenarios
4
and
then
gives
them
to
the
other
team
members.

11. 1
2
3
BDD Gotchas
An@-­‐paKern
2
4
The
tester
writes
the
scenarios
at
the
end
to
implement
an
automated
test
suite.

12. 1
2
3
4
5
BDD Gotchas
An@-­‐paKern
3
The
“Three
Amigos”
sessions
don’t
result
in
usable
scenarios,
so
the
developer
invents
them
a=erwards.

13. 1
2
3
4
5
BDD Gotchas
An@-­‐paKern
4
The
scenarios
are
too
UI-­‐centric
or
detail-­‐focused,
and
neglect
to
express
the
core
business
value.

14. BDD for high-level
requirements

17. Frequent Flyer Application
Goal: Encourage travellers to fly with Flying High airlines more often by allowing them to
cumulate Frequent Flyer points that they can spend on cheaper flights.
Goals
Earning points
from flights
Capabili9es
Earning points
from spending
with partners
Viewing points
earned
Spending points
on bookings
Viewing current points balance Features
View points needed to achieve
the next status level
Calculating points needed for
a given destination

18. Calculating points needed for a given destination
As a traveller
I want to know how many points I need to go to a given destination
So that I can plan my next trip with Flying High Airlines
Feature
Acceptance Criteria
-Need 2 points per km
-Members can calculate points needed on their account home page
Acceptance
Criteria
Automated
Acceptance
Criteria

19. Automated
Acceptance
Criteria
Automated
Acceptance
Tests

20. Automated
Acceptance
Tests
Applica9on
Code
Low
level
specifica9ons

21. A typical BDD workflow
“But
what
are
the
deliverables?
Meaningful
feedback
on
what
requirements
have
(and
have
not)
been
delivered

22. An incremental approach
“But
what
are
the
deliverables?
Descrip9on
of
each
feature
with
an
example
of
how
it
behaves

23. An incremental approach
“But
what
are
the
deliverables?
…complete
with
illustra9ons

24. An incremental approach
“But
what
are
the
deliverables?
How
was
each
feature
tested?

25. An incremental approach
“But
what
are
the
deliverables?
Documenta9on
about
what
you
plan
to
deliver
in
each
release

26. An incremental approach
“But
what
are
the
deliverables?
Useful
low-­‐level
technical
documenta9on
with
liRle
overhead

27. An incremental approach
“But
what
are
the
deliverables?
…and
targeted
automated
regression
tests

28. BDD for detailed coding

29. Business
Goal
Business
Goal
Business
Goal
“building the software right”
FFeFeaeatatuturureresess FFeEeaxatatumurrepesless
Low level
speLcoifiwc aletvioenl s
speLcoifiwc alteivoenls
specifications
Executable
specifications
We
can
automate
these
examples
in
the
form
of
“executable
specifica@ons”

30. Business
Goal
Business
Goal
Business
Goal
“building the software right”
FFeFeaeatatuturureresess FFeEeaxatatumurrepesless
Low level
speLcoifiwc aletvioenl s
speLcoifiwc alteivoenls
specifications
Executable
specifications
spock
RSpec
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
We
use
low-­‐level
BDD
or
TDD
tools
to
define
the
behavior
of
components,
classes
etc.

31. “building the software right”
Acceptance
criteria
tell
us
what
we
need
to
build…

32. What
would
we
like
the
API
to
look
like?
“building the software right”

33. “building the software right”
Then
write
low-­‐level
specifica@ons
for
the
code

34. “building the software right”
These
low
level
specifica@ons
become
technical
documenta@on
for
your
APIs

35. What tool should I use?

36. Collaboration before Automation
“Having
the
conversaDon
is
more
important
than
recording
the
conversaDon
is
more
important
than
automaDng
the
conversaDon”
-­‐
Liz
Keogh

37. Know your audience

38. DeThmanko You