The document discusses ubiquitous testing, which refers to testing being integrated throughout the entire development process and involving the entire team. It advocates that testability should be a key attribute in system architecture, acceptance tests should be automated, and the team should define tests before writing production code. This approach aims to avoid issues like testing lagging behind development or having only upfront requirements.

1. UbiquitousTesting
Testing is too important
to leave to the end
Alistair McKinnell
ValuableCode
@amckinnell
Yehoram Shenar
Guidewire
@yehoram

3. How to recognize agile
software development?
1. Frequent delivery
2. Organize around teams

4. 1. Frequent delivery
“Have you delivered running, tested, and
usable code at least twice to your user
community in the last six months?”
Alistair Cockburn

5. 1. Frequent delivery
18 months
9 - 3 months
4 months
continuous
delivery

6. 2. Organize around teams
“Team = Software”
Jim and Michele McCarthy

7. Projects

8. Teams

9. Sweet spot for agile
software development
1. Frequent delivery
2. Organize around teams

10. Failure Modes
Ubiquitous
Testing
Testing
Fact & Myth?

14. Testing lags behind
1
2
3
4

15. Up front requirements
1
2
3
4

16. So why is any of this a problem?

18. Present, appearing, or found everywhere
Ubiquitous
adjective

19. Testing is everyone’s concern
Testing happens all the time
UbiquitousTesting

20. UbiquitousTesting
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

21. UbiquitousTesting
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

22. UbiquitousTesting
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

23. UbiquitousTesting
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

24. UbiquitousTesting
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

25. Testing happens all the time
UbiquitousTesting
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code
Testing is everyone’s concern

26. Testing lags behind

27. Testing lags behind
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

28. Testing lags behind
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

29. Testing lags behind
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

30. Testing lags behind
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

31. Testing lags behind
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

32. Up front requirements

33. Up front requirements
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

34. Up front requirements
Testability is an
essential attribute of
system architecture
The whole team plans and
estimates the work
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

35. Up front requirements
Testability is an
essential attribute of
system architecture
Acceptance tests are
automated
The whole team defines the
tests before starting to write
the production code

36. The whole team defines the
tests before starting to write
the production code
The whole team defines the
specifications before
starting to write
the production code
Up front requirements
Testability is an
essential attribute of
system architecture
Acceptance tests are
automated

37. Acceptance tests are
automated
Executable specifications
are validated frequently
The whole team defines the
specifications before
starting to write
the production code
Up front requirements
Testability is an
essential attribute of
system architecture

38. Executable specifications
are validated frequently
The whole team defines the
specifications before
starting to write
the production code
Testability is an
essential attribute of
system architecture
Automated validation of
specifications is an
essential attribute of
system architecture
Up front requirements

39. Automated validation of
specifications is an
essential attribute of
system architecture
Up front requirements
The whole team plans and
estimates the work
Executable specifications
are validated frequently
The whole team defines the
specifications before
starting to write
the production code

40. Automated validation of
specifications is an
essential attribute of
system architecture
Up front requirements
The whole team plans and
estimates the work
Executable specifications
are validated frequently
The whole team defines the
specifications before
starting to write
the production code

41. Automated validation of
specifications is an
essential attribute of
system architecture
Up front requirements
The whole team plans and
estimates the work
Executable specifications
are validated frequently
The whole team defines the
specifications before
starting to write
the production code

42. Automated validation of
specifications is an
essential attribute of
system architecture
Up front requirements
The whole team plans and
estimates the work
Executable specifications
are validated frequently
The whole team defines the
specifications before
starting to write
the production code

43. Up front requirements
Automated validation of
specifications is an
essential attribute of
system architecture
Executable specifications
are validated frequently
The whole team defines the
specifications before
starting to write
the production code
The whole team plans and
estimates the work

45. Delivery Safety Zone
18 months
4 months
continuous
delivery

46. Shorter Feedback Cycles

47. First row is sometimes called Water-Scrum-Fall
while the fourth row shows a Wateration
1
2
3
4
Testing laggingRequirements Up Front
Phased Delivery

48. 1
2
3
4
Testing laggingRequirements Up Front
What would this row look like?
Phased Delivery
5
Ubiquitous Testing

49. The whole team plans and
estimates the work
The whole team defines the
specifications before
starting to write
the production code
WholeTeam
Run a pilot specification workshop
Create specifications for a single story in a sprint
Create specifications for more of your stories

50. Automated validation of
specifications is an
essential attribute of
system architecture
Executable specifications
are validated frequently
Technical Excellence
Start usingTDD to create unit tests
Automate specifications for one story as a pilot
Start automating some of your stories each sprint

51. Getting Going
start here

52. Books for Getting Going

53. Tools for Getting Going
fitnesse.org
jbehave.org
cukes.info

55. Books
Gojko Adzic, Specification by Example (Manning, 2011)
Alistair Cockburn, Crystal Clear (Addison-Wesley, 2005)
Jim and Michele McCarthy, Software forYour Head
(Addison-Wesley, 2001)

56. Books
Kent Beck, Test-Driven Development: By Example
(Addison-Wesley, 2002)
Markus Gärtner, ATDD by Example
(Addison-Wesley, 2012)
Ken Pugh, Lean-Agile Acceptance Test-Driven
Development (Addison-Wesley, 2010)

57. Books
Nat Pryce and Steve Freeman, Growing Object-Oriented
Software, Guided by Tests (Addison-Wesley, 2009)
Gerard Meszaros, xUnit Test Patterns: Refactoring Test
Code (Addison-Wesley, 2007)
Michael Feathers, Working Effectively with Legacy Code
(Prentice Hall 2004)

58. Books
Rick Mugridge and Ward Cunningham, Fit for
Developing Software (Prentice Hall 2005)
Matt Wynne and Aslak Hellesøy, The Cucumber Book
(The Pragmatic Bookshelf, 2012)

59. Photo Credits
http://www.flickr.com/photos/arlette/3260468/
http://www.flickr.com/photos/14869313@N00/301057804/
http://www.flickr.com/photos/16634670@N00/3214815323/
http://www.flickr.com/photos/43291304@N08/4103102579/
http://www.flickr.com/photos/potentialpast/7222455588/
http://www.flickr.com/photos/leeadlaf/3571935758/