Talk about Specification by Example. What's the problems it tries to tackle and how to solve them. I gave this talk at findmypast.com on a "lunch and learn" weekly meeting for the company. This is a new version of my previous presentation about "Specification by example" http://www.slideshare.net/AsierBarrenetxea1/specification-by-example-33594438

1. How to Deliver
the Right
Software
Asier Barrenetxea

2. What is the single
greatest cause of
software failure?
Requirements!

3. Requirements
 are wrong.
 are badly written.
 are incomplete.
 The programmers and the specifiers understand the
requirements differently.

4. Classical approach:
testing at the end
Requirements Development Testing

5. Hand over of requirements

6. Each source telling a
different story
 Tests ≃ Requirements
 How system really works ≃ Requirements
 Documentation get stale

7. Late feedback
 Business misunderstands get arisen late on the process
 When developer implementing requirements.
 When qa testing it.
 When software gets into production.
 Big WASTE

8. Spec by example
to the rescue

9. Bring testing to the front
Requirements
+
Testing
Development
Verification
(automated)

10. Use examples
 Easy to understand
 Plain English
 Unambiguous

11. Write examples
collaboratively
 Business people, developers and testers in the same
room.
 Transfer the knowledge.
 Learn about the domain.
 Ubiquitous language.
 Early feedback of misunderstandings.
 In 30 min meeting can find out things that it would take a
whole iteration or even more.
 everybody understands the same thing.

12. Write examples
collaboratively
 Inconsistencies and gaps are easy to spot when you
write down the rules.
 Find out incorrect assumptions.
 Find out real business value.
 Everybody gets this feeling of ownership.
 Different approaches:
 Three amigos
 One developer with a stakeholder/domain expert
 Whole team with stakeholders
 Specification workshop

13. Specification workshop
 For harder to specificy stories.
 Meeting with 10+ people. POs, BAs, devs, QAs..
 Bring people from other teams if necessary.
 Create 3 teams and write examples in one board each.
 Compare. Look for inconsistencies. Why do we have
them?

14. Automate examples
 Map examples to executable tests.
 Use tools as Specflow, Cucumber, Fitness..
 Do not modify examples when automating.

15. Automate examles
 Brittle UI tests?
 Do not couple your examples to the UI.
 Page Objects https://code.google.com/p/selenium/wiki/PageObjects
 Tests don’t have to go always through the UI!
 Test pyramid. http://martinfowler.com/bliki/TestPyramid.html

16. Implement examples
 Developers will have to code just what was specified.
 Make the tests green -> Done.

17. Single source of truth
 Examples = Requirements.
 Examples = Automated tests.
 Examples = What the system does.

18. Living documentation
 Run examples with every change to the system.
 Documentation never gets out-dated.
 All tests green -> system is doing what examples say.

19. User stories
 Relate examples with user story.
 Gives context.
 Focus on business goal.
As a <role>
I want <software feature>
In order to <goal/desire>
I order to <goal/desire>
as a <role>
so that <software feature>

20. Gherkin syntax
 Given -> arrange
 When -> action
 Then -> assert

21. What makes a good example
 Focused on a single thing.
 Self explanatory.
 Uses the domain language.
 SMART
 Specific
 Measurable
 Achievable
 Relevant
 Time-bound.

22. Do not automate EVERYTHING
 There would always be some manual testing.
 Usability testing.
 Exploratory testing.
 Be aware.

23. Examples of examples

25. Conversation brings new
scenarios to the table

26. Communication > Automation
 The important thing is to communicate
 Automation and tools are nice, but don’t get your main
focus on them
 “Individuals and interactions over processes and tools”
- Agile Manifesto
 “I want to bridge the gap between business people and
technical people”
- Kent Beck about XP

27. More Info + resources
Book. Specification by Example: How Successful
Teams Deliver the Right Software , Gojko Adzic
http://www.amazon.co.uk/Specification-
Example-Successful-Deliver-
Software/dp/1617290084
Blog post. A.T. FAIL!, Robert C. Martin
http://blog.8thlight.com/uncle-
bob/2013/09/26/AT-FAIL.html
Specification by Example and Agile Acceptance
Testing, Gojko Adzic
http://www.slideshare.net/gojkoadzic/specific
ation-by-example-and-agile-acceptance-testing
My blog post.
http://asierba.net/2014/04/03/spec-by-
example/

28. Questions?