Specification by example - course summary
4 likes2,686 views
Morten Berg and Jakub Holy discuss the importance of Specification by Example (SBE) in aligning business goals with software development and testing through collaborative specification. They emphasize creating a shared understanding among stakeholders using examples, which leads to more effective acceptance tests and living documentation. The document also covers techniques for maintaining acceptance tests and addresses common pitfalls in specifications.
Specification by example - course summary
- 1. Morten Berg and Jakub Holy present: From user stories to acceptance tests What we learned about Specification by example Iterate :: 1/2012
- 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
- 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)