This was presented by Paul Gerrard at the London Tester Gathering at SkillsMatter on 16 May 2011.

1. Using Business Stories toTest Requirements and Systems Paul Gerrard paul@gerrardconsulting.com Twitter: @paul_gerrard Web: gerrardconsulting.com Slide 1 Intelligent Testing, Improvement and Assurance

2. Who are You? Agile, Structured or ‘Hybrid’ Analysts, Testers or Developers (Pick any 2, 3, 4, 5, or all 6) Intelligent Testing, Improvement and Assurance Slide 2

3. Intelligent Testing, Improvement and Assurance Slide 3 This session is for… What we’ll explore… Anyone who writes/reads requirements or tests Business Analysts in Structured Projects Relationship of Stories to Requirements Test Analysts in Structured Projects How Stories can test Requirements Testers in Agile Projects How Stories fit Agile and Structured Developers in Agile Projects How Stories spawn manual/automated tests We’re going to examine how we can elicit and refine requirements that are testable and viable for development and capture requirements knowledge in a useful way.

4. What are Stories? From Caveman, through Agile to Mainstream

5. Slide 5

6. Agile story cards Slide 6 From cave paintings to story cards… progress?

7. Stories A powerful antidote to the complexity of systems and analysis Telling stories helps stakeholders to have a sufficiently wide view to avoid problems Stories vary from brief statements to richly coloured analyses (sagas) Usually based on a sequence of actions carried out by intelligent ‘agents’. Slide 7

8. How stories can help People are very good at reasoning from even quite short stories to identify (for example): Omissions Inconsistencies Ambiguity These innate human capabilities give stories their power Stories are applicable to systems of all types, at any stage for different purposes. Slide 8

9. A trigger for a conversation A story could be a few words stuck on a post-it note or index card Simplest definition: “A trigger for a conversation” But post-it notes (many tools just simulate them) aren’t good requirements repositories We need something better. Slide 9

10. Story Header Feature: ship orders As a orders clerk I want to acknowledge and ship the order So thatwe fulfil a book order Scenario: ship a single book from stock Given I select a valid order And the ordered book is in stock When I choose ‘acknowledge and ship’ Then order status is changed to ‘shipped’ And an address label is printed Structured stories (other variations exist) Slide 10 Key word Story text Each Story has multiple Scenarios Scenarios can be data driven

12. Note that roles can sometimes vary, but it is often better to reference ‘personas’ that have multiple roles.

14. given=precondition(s), when=steps, then=outcome(s)

15. A scenario maps directly to a test case – but we haven’t used the word test yet.

17. Scenario outlines allow scenarios to be data-driven Slide 14 Feature: Log in process As a system user In order to protect the system I want accounts to be protected with secure credentials Scenario: log in process Given the home page login screen When i enter an Email address: <email> and i enter the password: <password> and <check> the “remember me” check box and click the submit button Then the system <logsmein> and the system displays <display>Examples:email | password | check | logsmein | displayvalid email | valid password | check on | logs me in | home pageno email | anything | anything | rejects the email address| “invalid email”invalid email| anything | anything | rejects the email address| “invalid email”valid email | invalid password| anything | rejects the password | “invalid password”

18. The View from Above 1 Agile Methods are Evolving There’s lots of them Expect consolidation

19. Overview Countless new approaches emerging out of the Agile community There seems to be a natural evolution towards ‘Specification by Example’ Looks terrific in theory, and a few companies appear to have it working But first some background… Slide 16

20. Emerging Approaches We seem to be in the middle of an explosion of new approaches Mostly Agile but not exclusively so Some new but many rework established ideas Lean, Kanban and anything oriental in vogue Emerging management methods Acceptance-, Behaviour-, Design-, Test-Driven Development… Emerging specification and development methods Slide 17

21. Wikipedia Search:‘driven development’ Test-Driven Development* Feature Driven Development * BehaviorDriven Development * Tester Driven Development Business-Driven Development * Community Driven Development * Design-Driven Development Process Driven Development Test-Driven Development by Example * Model-Driven development * Event Driven Development * Goal-Driven Software Development Process * Slide 18 ‘Variations on a theme’? * Entries updated less than six months ago

22. Prescriptive v adaptive Slide 19 Regular Timeboxes Event-Driven Waterfall Extracted from: http://www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf

23. Feedback loops (NOT to scale) Slide 20 2-4 weekly Daily Hourly Minutes Seconds Pair Programming Unit Test Continuous Integration Daily Scrum Sprint Feedback ranges from personal observations (pairing), through automated unit, build/integration tests, user tests and team retrospectives

24. From Test-Driven to Specification by Example …in 5 minutes

25. Test-Driven – from stories to code Slide 22 Stories are not (usually) retained The Test code is crafted by hand The Story The Test The Software

26. Behaviour-Driven – structured story to code using today’s tools Slide 23 The stories are captured as plain text, code or html The Test code is generated by a tool from the stories The Story The Test The Software

27. Spec-by-Example – flowdown from requirements to code Slide 24 The stories are used to validate requirements The story is captured in the SAME tool as requirements The Test code is generated by the SAME tool from stories The Story The Test The Software

28. Test code generation In the previous slides, I’ve used the generation of xUnit (in this case, Python unit test) code to illustrate the story => test code process Test code could be the plain text, html or pseudocode used by existing BDD tools Developers don’t need to change their ways Test code directly into version control means they can’t tinker with it This stage is the natural interface from users and testers to (e.g. offshored) developers. Slide 25

29. The View from Above 2 Structured folk want the best of Agile Stories provide a natural link Expect to see hybrid methods, new toolsets emerge

31. Varying formality, but ALL require discipline

32. But stories are universal as examples of features in use

34. Coverage of Business Stories is a necessary, but not sufficient, contractual requirementDevO’Lopper

35. How stories will help Stories instantiate features of the system and example them Stories fed back to stakeholders to validate requirements Requirements PLUS stories provide a better foundation for developers (less wriggle room) Stories provide logical tests for acceptance; testers can add detail and procedure, if necessary Stories can generate BDD (e.g. Cucumber) scripts or TDD (xUnit) code Customer-Supplier contract supported by stories and tests Improves stability of the requirements and the relationship Suppliers who rely on vague requirements and change requests for their business model wont like it though (tough!) Intelligent Testing, Improvement and Assurance Slide 29

36. Requirements  Stories orStories  Requirements? Requirements are written for the benefit of IT Complete, concise, precise, consistent, unambiguous Or none of the above Users want to tell stories and provide examples The analysts transform these into requirements for the techies to work with But if stories are part of the process, the natural, iterative approach to requirements elicitation, analysis and validation fits nicely So… adopt an Agile approach to requirements in your structured process? Intelligent Testing, Improvement and Assurance Slide 30 At which point the analysts say, “but we’ve always worked that way”

37. Stories support all development methods Intelligent Testing, Improvement and Assurance Slide 31

38. Ubiquitous Language An emerging discipline, coming from the ‘Domain-Driven Design’ community To create a flexible, knowledge-rich design, calls for a versatile, shared team language Ubiquitous language is intended to be used in business, system designs and even code UL is beyond the scope of this session, but expect it to gain traction over the next few years. Intelligent Testing, Improvement and Assurance Slide 32 COBOL was meant to be a Common Business-Oriented Language in 1959

39. So we need a tool that will… Manage business definitions Index defined terms throughout requirements, stories and scenarios Capture requirements and story detail, and cross-refer them Output requirement and story content in an easy-to-review format Output BDD/TDD code for use by developers. Intelligent Testing, Improvement and Assurance Slide 33

40. How to Test Requirements with Stories Intelligent Testing, Improvement and Assurance Slide 34

41. Example requirement: what needs definition? A customer order will have a unique order reference a customer identifier, an order date and a required-by date. Each order generates multiple order items each of which has a unique ID, a product identifier, an order quantity, a unit price, a unit weight, a promised delivery date and required-by date. The total order price, earliest and latest delivery date, total weight will be calculated from the items on the order. Intelligent Testing, Improvement and Assurance Slide 35 As a tester; as a developer

42. Example requirement: what needs definition? A customer order will have a unique order reference a customer identifier, an order date and a required-by date. Each order generates multiple order items each of which has a unique ID, a product identifier, an order quantity, a unit price, a unit weight, a promised delivery date and required-by date. The total order price, earliest and latest delivery date, total weight will be calculated from the items on the order. Intelligent Testing, Improvement and Assurance Slide 36

43. What other questions might you ask? ‘customer order will have…’ means what? ‘unique order reference’ unique in what context? ‘Order date’: date placed, or date recorded or other date to be defined? ‘Each order generates’ – means what? Can an order have zero items? Is there a limit to how many items? Can order quantity be negative, non-zero, is it a decimal or integer? Must dates be weekdays or can they be weekends? Are there any date rules to apply? What currency are prices in? What units is weight measured in? Is deliver-date the last required-by date or is it calculated some other way? Other definitions? ‘Customer’, ‘required-by’, ‘weight’, ‘unit’, ‘promised’, ‘total (price)’, ‘product’ Where do these pieces of data come from? Where are they stored? Where do they ‘go to? Intelligent Testing, Improvement and Assurance Slide 37

44. Typical questions to ask of a requirement What do the nouns and verbs actually mean? What features are being described here? What outcomes do these features provide? What scenarios (normal, extreme, edge and exceptional) should they cope with? Are all outcomes predictable from the text? Are all outcomes unambiguous? Is anything (definitions, features, scenarios or outcomes) missing? Intelligent Testing, Improvement and Assurance Slide 38 Definition Feature Outcome Scenarios Prediction Ambiguity Missing

45. D e F O S P A M Definitions Features Outcomes Scenarios Prediction Ambiguity Missing Intelligent Testing, Improvement and Assurance Slide 39 See Handout Identify the terms One story per feature One scenario per outcome One scenario per scenario Can’t predict? Scenario + guess outcome Two stories with conflicts Add a story as a suggestion

46. Creating Stories I have a 12-page ‘User Story Guideline’ that might help. Email me and I’ll send you a copy.

48. The calculator will validate the numbers A and B as valid in the range -1000,000,000 to +1000,000,000

49. The operator may be one of the following: "+" (plus), "-" (minus), "*" (multiply) or "/" (divide)

50. The calculator will perform the calculation according to standard arithmetical rules

52. Accessing Testela BETA Network: checkout the posters on the walls Accessing Testela through your browser Account details: “usernnn@testela.com” password: “password” nnn is 001–100 – I’ll allocate numbers to you When you log in, click ‘edit profile’ and change your details (and change password too perhaps) Intelligent Testing, Improvement and Assurance Slide 43

53. Features we’ll use today Requirements Stories Scenarios Dictionary Export Feature/Scenarios Export Unit Tests Intelligent Testing, Improvement and Assurance Slide 44

54. Exercise 1: Adding your first story Product tab-> Click ‘Add Story’ Select requirement, role, leave ‘assigned to’ as is Submit Click ‘Find Stories’ and user filter to find your story Click ‘Add a scenario’ – confirm it Click ‘View All Story Scenarios’ Intelligent Testing, Improvement and Assurance Slide 45

55. The Dictionary The Dictionary allows you to capture definitions of terms in a glossary These definitions are indexed for requirements and stories Benefits Term, entity, concept… coverage Encourages ubiquitous language Tagging of content is not necessary Business impact analyses are possible. Intelligent Testing, Improvement and Assurance Slide 46

56. Using the dictionary What terms need definition? I’ll add them to the glossary And re-index Now look at the requirement and your story Index listing at the bottom of page Go to Dictionary->Index Let’s look at some of your stories and discuss Intelligent Testing, Improvement and Assurance Slide 47

57. Exercise 2: Requirement 207 To access requirement enter r/207 in the fast access field and press return This is a better requirement than before Add a story as before and we’ll walk through creating an examples table Let’s add some glossary terms too Intelligent Testing, Improvement and Assurance Slide 48

58. Exercise 3: Requirement 206 If we have time… To access requirement enter r/207 in the fast access field and press return This is a better requirement than before Add a story as before and we’ll walk through creating an examples table Let’s add some glossary terms too Intelligent Testing, Improvement and Assurance Slide 49

59. Exercise 4: Generate test scenarios Find one of your stories and view it Click on the ‘Lock Story’ link Click ‘View Test Scenarios’ Click on ‘Edit’ for one of them Intelligent Testing, Improvement and Assurance Slide 50

60. Demo Code Generation

61. Close

62. Using Stories We can use stories to: Illustrate features described by requirements in business language Validate requirements by feeding back to users Generate acceptance test cases manual end to end tests Generate BDD script (e.g. Cucumber) or xUnit or (in principle) and automation framework code Stories plus a dictionary allows us to manage knowledge in a consistent way New coverage types, tagging/taxonomies and impact analyses are now possible Why haven’t we always used stories? Intelligent Testing, Improvement and Assurance Slide 53

63. Intelligent Testing, Improvement and Assurance Slide 54 Want to evaluate Testela?Do get in touch.More info at:testela.comThanks once again

64. Using Business Stories toTest Requirements and Systems Paul Gerrard paul@gerrardconsulting.com Twitter: @paul_gerrard Web: gerrardconsulting.com Slide 55 Intelligent Testing, Improvement and Assurance