KEMBAR78
How to Deliver the Right Software (Specification by example) | PPTX
How to Deliver
the Right
Software
Asier Barrenetxea
What is the single
greatest cause of
software failure?
Requirements!
Requirements
 are wrong.
 are badly written.
 are incomplete.
 The programmers and the specifiers understand the
requirements differently.
Classical approach:
testing at the end
Requirements Development Testing
Hand over of requirements
Each source telling a
different story
 Tests ≃ Requirements
 How system really works ≃ Requirements
 Documentation get stale
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
Spec by example
to the rescue
Bring testing to the front
Requirements
+
Testing
Development
Verification
(automated)
Use examples
 Easy to understand
 Plain English
 Unambiguous
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.
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
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?
Automate examples
 Map examples to executable tests.
 Use tools as Specflow, Cucumber, Fitness..
 Do not modify examples when automating.
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
Implement examples
 Developers will have to code just what was specified.
 Make the tests green -> Done.
Single source of truth
 Examples = Requirements.
 Examples = Automated tests.
 Examples = What the system does.
Living documentation
 Run examples with every change to the system.
 Documentation never gets out-dated.
 All tests green -> system is doing what examples say.
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>
Gherkin syntax
 Given -> arrange
 When -> action
 Then -> assert
What makes a good example
 Focused on a single thing.
 Self explanatory.
 Uses the domain language.
 SMART
 Specific
 Measurable
 Achievable
 Relevant
 Time-bound.
Do not automate EVERYTHING
 There would always be some manual testing.
 Usability testing.
 Exploratory testing.
 Be aware.
Examples of examples
Conversation brings new
scenarios to the table
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
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/
Questions?

How to Deliver the Right Software (Specification by example)

  • 1.
    How to Deliver theRight Software Asier Barrenetxea
  • 2.
    What is thesingle 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 atthe end Requirements Development Testing
  • 5.
    Hand over ofrequirements
  • 6.
    Each source tellinga different story  Tests ≃ Requirements  How system really works ≃ Requirements  Documentation get stale
  • 7.
    Late feedback  Businessmisunderstands get arisen late on the process  When developer implementing requirements.  When qa testing it.  When software gets into production.  Big WASTE
  • 8.
  • 9.
    Bring testing tothe front Requirements + Testing Development Verification (automated)
  • 10.
    Use examples  Easyto understand  Plain English  Unambiguous
  • 11.
    Write examples collaboratively  Businesspeople, 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  Inconsistenciesand 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  Forharder 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  Mapexamples to executable tests.  Use tools as Specflow, Cucumber, Fitness..  Do not modify examples when automating.
  • 15.
    Automate examles  BrittleUI 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  Developerswill have to code just what was specified.  Make the tests green -> Done.
  • 17.
    Single source oftruth  Examples = Requirements.  Examples = Automated tests.  Examples = What the system does.
  • 18.
    Living documentation  Runexamples with every change to the system.  Documentation never gets out-dated.  All tests green -> system is doing what examples say.
  • 19.
    User stories  Relateexamples 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 agood example  Focused on a single thing.  Self explanatory.  Uses the domain language.  SMART  Specific  Measurable  Achievable  Relevant  Time-bound.
  • 22.
    Do not automateEVERYTHING  There would always be some manual testing.  Usability testing.  Exploratory testing.  Be aware.
  • 23.
  • 25.
  • 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.