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
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
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
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>
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.
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/