How to deliver the right software (Specification by example)
0 likes68 views
The document discusses the importance of delivering accurate software specifications using the 'spec by example' approach, which emphasizes collaborative writing of examples among developers, testers, and business representatives. It highlights common problems with traditional requirement frameworks and advocates for early feedback through clear, concrete examples to prevent misunderstandings. Overall, the presentation focuses on enhancing communication and ensuring that software meets user needs, while addressing best practices and common pitfalls in the implementation of automated testing.
How to deliver the right software (Specification by example)
- 1. How to deliver the right software Spec by example Asier Barrenetxea
- 2. Agenda - Intro - The problem - The solution - Questions / discussion 2
- 4. I am recording 🎥 4
- 5. Feedback welcome 😊 ● Which feedback? ○ Communication skills ○ Content of the talk ● How to give me feedback? ○ at the end of the talk ○ after the talk in person ○ send me and email, chat.. ● Why feedback? ○ I am learning and I would like to improve ○ I believe I am in safe space 5
- 6. A bit of context about this talk ● A few years ago, I learned about BDD and ATDD and “practiced” it in a couple of places - I thought I was doing things right ● Later, I learned about spec by example (training by Gojko Adzic) ○ I was working in a place where we were doing BDD ○ I brought some of the ideas to that company ● After that, I have been to other places ○ people are doing BDD and ATDD ○ but I keep seeing the same mistakes ● Spec by example fixes many of these things ● Not many people know about spec by example! 6
- 8. What is the single greatest cause of software failure? 8
- 10. Software fails because requirements.. ● are wrong ● are badly written ● are incomplete ● The programmers and the specifiers understand the requirements differently 1 0
- 11. Classical approach: testing at the end 1 1 Requirements Development Testing
- 12. Hand-over of requirements 1 2 PO / BADev QA
- 13. Each source telling a different story ● Tests ≠ Requirements ● How system really works ≠ Requirements ● Documentation gets stale 1 3
- 14. Late feedback ● Business misunderstands get arisen late on the process ○ When developer implementing requirements. ○ When qa testing it. ○ When software gets into production. ● Huge WASTE 1 4
- 15. The solution 1 5
- 16. Spec by example to the rescue 1 6
- 17. Bring testing to the front 1 7 Requirements Development Testing
- 18. Bring testing to the front 1 8 Requirements + Testing Development Verification (automated)
- 19. Bring testing to the front 1 9 Examples Development Verification (automated)
- 20. Use examples ● Easy to understand ● Plain English ● Unambiguous ● Concrete instead of abstract
- 21. 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.
- 22. Write examples collaboratively ● When you write down the rules - Inconsistencies and gaps are easy to spot ● Find out incorrect assumptions. ● Find out real business value. ● Everybody gets this feeling of ownership.
- 23. Writing examples: Different approaches ● Whole team with stakeholders ● Three amigos: QA + Dev + PO/BA ● One developer with a stakeholder/domain expert ● Specification workshop 2 3
- 24. Specification workshop ● For harder to specify 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?
- 25. Automate examples ● Map examples to executable tests. ○ Use tools as Cucumber, Fitness, Specflow, Jasmine, Rspec.. ● Do not modify examples when automating.
- 26. Implementing the code is simple! ● Test first approach. ● Developers will have to code just what was specified in the examples. ● Make the tests green -> Done.
- 27. Single source of truth ● Examples = Requirements. ● Examples = Automated tests. ● Examples = What the system does.
- 28. Living documentation ● Run examples with every change to the system. ● Documentation never gets out-dated. ● All tests green -> system is doing what examples say.
- 29. User stories ● Relate examples with a 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>
- 30. What makes a good example ● Focused on a single thing. ● Self explanatory. ● Uses the domain language. ● SMART ○ Specific ○ Measurable ○ Achievable ○ Relevant ○ Time-bound.
- 31. Tools & Syntax - Gherkin/Cucumber ● Is the most common ● AAA style of structuring an example: ○ Given -> arrange ○ When -> act ○ Then -> assert
- 32. Tools & Syntax - Context/Specification ● Used in tools like: Jasmine, RSpec ● Also AAA style ○ describe - arrange ○ when - act ○ it - assert 3 2
- 33. 3 3
- 35. Mistake 1: Slow test suites ● Misconception: every example has to be a test against the UI or API - this is slow! ● Test pyramid. ● Good practice: For a feature ○ main scenario through the UI/API ○ rest of scenarios & edge cases with unit/integration tests
- 36. Mistake 2: Unreliable/Flaky tests ● UI tests are hard to maintain ○ this is because the UI changes a lot! ● Page Object pattern - to isolate UI Changes
- 37. Mistake 2: Unreliable/Flaky tests ● Do not couple your examples to the UI! BAD Given I enter “Asier” in the username input And I enter “p4ssw0rd” in the password input When I click the button “register” Then a page is loaded with the text “welcome Asier!” GOOD When I register with name “Asier” and “p4ssw0rd” Then I get notified with the text “welcome Asier!”
- 38. Mistake 3: Relaying too much in automation ● You can NOT automate EVERYTHING ● There would always be some manual testing. ○ Usability testing. ○ Exploratory testing. ● Be aware of this. Don’t forget that lovely manual QA ;)
- 39. Summary: benefits ● Quicker feedback in the software lifecycle and huge reduction of waste ● Alignment through early and frequent conversations - avoid misunderstandings ● Reliable documentation: Living documentation & Single source of truth ● Catalyst for ubiquitous language
- 40. Summary: 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
- 41. More Info + resources Book. Specification by Example: How Successful Teams Deliver the Right Software , Gojko Adzic http://www.amazon.co.uk/Specification-Exam ple-Successful-Deliver-Software/dp/161729008 4 Blog post. A.T. FAIL!, Robert C. Martin http://blog.8thlight.com/uncle-bob/2013/09/2 6/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-examp le/
- 42. But wait.. ● Can’t we reduce WASTE even more? ● Are our user stories wasteful? ● Are we really building what the user needs? ● How can we improve the feedback cycle? ● Can we be more LEAN? 4 2
- 43. 4 3
- 45. My experience with spec by example ● Company W: ○ Refinement meeting with PO, BA, QA and 1 dev - examples written collaboratively ● Company F: ○ Examples written by PO and refined/tweaked at kick off with BA ○ Demo at the end of feature development ● Company E: ○ Examples written by devs and refined/tweak with PO & QA. ○ Demo/Desk check at the end of development ○ PO & QA constantly checking living documentation ● Company O: ○ Examples written by BA, kick off with devs and PO ○ Demo at the end of feature development 4 5