Key lessons from the course on specification by example called From user stories to acceptance tests lead by Gojko Adzic in Oslo, 1/2012. What SbE is, what are its key goals, how to introduce it, selected techniques including Effect Mapping and Specification Workshop.

1. Morten Berg and Jakub Holy present:
From user stories to
acceptance tests
What we learned about Specification by
example
Iterate :: 1/2012

2. Quick fly-through

3. The Key Concerns of SbE
"Doing the right thing vs. doing the thing right."
Deliver true business value
Build shared understanding
(Evolve living documentation)

4. Shared understanding
in business terms
Shared understanding + business terms and
relations
(also less rework)
Aligned business, SW, test models
Small change in business => small in SW, test
Much, much better maintainability, evolvability
Build the right thing

5. Specify
The Key Patterns of SbE collaboratively
Business Scope
derive
goal (UC, US)
ilustrate
1. Derive scope from business goal
2. Specify collaboratively
3. Ilustrate using examples
4. Refine the specification Key
5. Automate validation w/o changing specification
6. Validate frequently examples
7. Evolve into a documentation system
automate w/o changing
Often,
Living Executable
documentation specification
evolve
http://specificationbyexample.com/key_ideas.html

6. Goal: Shared understanding
0. Clarify the goal
1. Build the shared understanding
○ Collaborative specification...
○ ... with examples
2. Keep it
○ Automate validation
3. Profit from it
○ Evolve into living documentation
"The devil is in the details"

7. Example specification with examples
Title: Free book delivery
Objective: VIP users who order more books get
free shipping in Norway.
Examples:
Customer Books Country Free shipping?
VIP 5 Norway Y
VIP 4 Norway N
VIP 10 Danmark N
Regular 10 Norway N

8. Sidenote: Automization
Customer Books Country Free shipping?
class FreeBookDeliveryTest {
void setCustomer(..) {..}
void setBooks(..) {..}
void setCountry(..) {..}
boolean isFreeShipping() {..}
}

9. Showtime: Some real-world
specifications with example

10. What makes a good specification
with examples?
Good
● Good google-able title
● Clear objective - how to read the examples?
● Uses business language, unified terms
● Couple of key, focused examples, complete
Bad
● Script ("click here, find css class X, ...)
● Too detailed, too verbose, duplication
● Many examples (bad understanding, bad
representation, more concepts mixed)

11. Show the poster!

12. Introducing SbE & Its Applicability
9-15
mo
Strategy: What's the team's top pain? Can
something from SbE fix it? buzz-
words
Big
Examples: Bang
● Lot of rework devs - testers => better shared
understanding via Specification workshop
● Late feedback from testers => automate
Key: Introduce what you need, when you need
it, step by step. Shift culture first. It's easy!

13. Why to specify collaboratively?

14. can become
Examples Tests
ela
rify
bo
ve
rat
e
Requirements

15. Single source of truth
Devs: Truth in code
Testers: Truth in test cases
Business analyst: Truth in documents
Use a single source of truth, avoid translation!
=> Start with business analyst
Extend with examples from devs
Extend with examples from testers

17. Random highlights

18. How to Make Acceptance Tests
Maintainable
1. Aligned business, software, and test models
○ => small change in one is small in the other too
2. Test under the surface level, if possible
○ Service > Servlet > UI - decide by risk vs. cost
3. Isolate tests from implementation by layers of
test abstraction (What>Instrumentation>DSL)
See The Holy Java: How to Create Maintainable
Acceptance Tests (http://wp.me/pTHiC-tl)

19. Why Are We Doing This?
The Effect Maps Technique
Simple mind-mapping technique that incredibly
facilitates agile product design, planning,
prioritisation, and scoping.
demo
Levels:
1. Why - the measurable business goal
2. Who can help/hinder achievel of the goal?
3. How can they do it?
4. What are the SW features or business
activities that support it?

20. Techniques: Spec Workshop and
Diverge & Merge
Specification Workshop (½ day → 2w sprint)
● All: business + devs + testers
○ Business: What, why
○ Devs: What's technically possible/troublesome
○ Testers: How to test (break) this? Corner cases
● Surface hidden complexities, discover assumptions
● Build shared understanding (=> feedback exercise)
Diverge & Merge
● Groups of 3-5 work in parallel 10-20 min, then merge
results
● More divergent => richer & better ideas
● Prevent paralysation by confining troublesome people

21. Acceptance Test Automation Tools
● FitNesse - wiki-based
○ Cons: Long learning, encourages copy&paste
○ Pros: Wiki, mature
● Concordion - new, HTML+JUnit
○ Pros: Contrary to FitNesse disables copying, quick to
learn, integrated anywhere via JUnit, free-form
○ Cons: No live editing, no copying => not for 104 tests
● Cucumber - new, websites, Ruby, ecosystem
○ Pros: Simple text format (RegExp), easy2learn, web
○ Cons: Only test execution - other tools for the rest
● Robot Framework - tabular, keyword-driven
○ Pros: Great for testers w/o devs, libraries (SQL,..)
● Commercial - GreenPepper (Confluence), ...

22. The end is coming, run for your life!

23. Other Key Lessons
● When the time is short ... do communicate!
● The key benefit of SbE aside of improved
communication is living documentation;
regression tests are only a minor by-product
● (and many others :-))

24. Quiz
What have we learned today?

25. Resources
Gojko Adzic: Specification by
example, 2011
- condensed experience of 50 highly
successful teams
Eric Evans: Domain Driven Design,
2003
Gojko Adzic: Agile product
management using Effect Maps
(paper)