Specification by example - course summary
Upcoming SlideShare
Loading in...5
×
 

Specification by example - course summary

on

  • 1,679 views

Key lessons from the course on specification by example called From user stories to acceptance tests lead by Gojko Adzic in Oslo, 1/2012....

Key lessons from the course on specification by example called From user stories to acceptance tests lead by Gojko Adzic in Oslo, 1/2012.
What SbE is, what are its key goals, how to introduce it, selected techniques including Effect Mapping and Specification Workshop.

Statistics

Views

Total Views
1,679
Views on SlideShare
1,678
Embed Views
1

Actions

Likes
2
Downloads
32
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Specification by example - course summary Specification by example - course summary Presentation Transcript

  • Morten Berg and Jakub Holy present: From user stories to acceptance tests What we learned about Specification by example Iterate :: 1/2012
  • Quick fly-through
  • The Key Concerns of SbE"Doing the right thing vs. doing the thing right." Deliver true business value Build shared understanding (Evolve living documentation)
  • Shared understandingin business terms Shared understanding + business terms and relations (also less rework) Aligned business, SW, test modelsSmall change in business => small in SW, testMuch, much better maintainability, evolvability Build the right thing
  • SpecifyThe 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
  • Goal: Shared understanding0. Clarify the goal1. Build the shared understanding ○ Collaborative specification... ○ ... with examples2. Keep it ○ Automate validation3. Profit from it ○ Evolve into living documentation "The devil is in the details"
  • Example specification with examplesTitle: Free book deliveryObjective: VIP users who order more books getfree shipping in Norway.Examples:Customer Books Country Free shipping?VIP 5 Norway YVIP 4 Norway NVIP 10 Danmark NRegular 10 Norway N
  • Sidenote: AutomizationCustomer Books Country Free shipping?class FreeBookDeliveryTest { void setCustomer(..) {..} void setBooks(..) {..} void setCountry(..) {..} boolean isFreeShipping() {..}}
  • Showtime: Some real-worldspecifications with example
  • What makes a good specificationwith examples?Good● Good google-able title● Clear objective - how to read the examples?● Uses business language, unified terms● Couple of key, focused examples, completeBad● Script ("click here, find css class X, ...)● Too detailed, too verbose, duplication● Many examples (bad understanding, bad representation, more concepts mixed)
  • Show the poster!
  • Introducing SbE & Its Applicability 9-15 moStrategy: Whats the teams top pain? Cansomething from SbE fix it? buzz- words BigExamples: Bang● Lot of rework devs - testers => better shared understanding via Specification workshop● Late feedback from testers => automateKey: Introduce what you need, when you needit, step by step. Shift culture first. Its easy!
  • Why to specify collaboratively?
  • can becomeExamples Tests ela rify bo ve rat e Requirements
  • Single source of truthDevs: Truth in codeTesters: Truth in test casesBusiness analyst: Truth in documentsUse a single source of truth, avoid translation!=> Start with business analyst Extend with examples from devs Extend with examples from testers
  • Random highlights
  • How to Make Acceptance TestsMaintainable1. Aligned business, software, and test models ○ => small change in one is small in the other too2. Test under the surface level, if possible ○ Service > Servlet > UI - decide by risk vs. cost3. Isolate tests from implementation by layers of test abstraction (What>Instrumentation>DSL)See The Holy Java: How to Create MaintainableAcceptance Tests (http://wp.me/pTHiC-tl)
  • Why Are We Doing This?The Effect Maps TechniqueSimple mind-mapping technique that incrediblyfacilitates agile product design, planning,prioritisation, and scoping. demoLevels:1. Why - the measurable business goal2. 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?
  • Techniques: Spec Workshop andDiverge & MergeSpecification Workshop (½ day → 2w sprint) ● All: business + devs + testers ○ Business: What, why ○ Devs: Whats 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
  • 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), ...
  • The end is coming, run for your life!
  • 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 :-))
  • QuizWhat have we learned today?
  • 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)