The document discusses using business stories to test requirements and systems. It explains that stories can help identify omissions, inconsistencies, and ambiguity in requirements. Stories are applicable at any stage of a project for different purposes. Structured stories follow a common format with a header, scenarios with given/when/then structures, and can have multiple scenarios to test different conditions. Stories can validate requirements by example and generate both manual and automated test cases. The document argues that a structured, disciplined approach to stories can benefit both agile and structured development approaches.

1. Using Business Stories toTest Requirements and SystemsPaul Gerrardpaul@gerrardconsulting.comTwitter: @paul_gerrardWeb: gerrardconsulting.comSlide 1Intelligent 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 AssuranceSlide 2

3. Intelligent Testing, Improvement and AssuranceSlide 3This session is for…What we’ll explore…Anyone who writes/reads requirements or testsBusiness Analysts in Structured ProjectsRelationship of Stories to RequirementsTest Analysts in Structured ProjectsHow Stories can test RequirementsTesters inAgile ProjectsHow Stories fit Agile and StructuredDevelopers inAgile ProjectsHow Stories spawn manual/automated testsWe’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 cardsSlide 6From cave paintings to story cards… progress?

7. StoriesA powerful antidote to the complexity of systems and analysisTelling stories helps stakeholders to have a sufficiently wide view to avoid problemsStories 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 helpPeople are very good at reasoning from even quite short stories to identify (for example):OmissionsInconsistenciesAmbiguityThese innate human capabilities give stories their powerStories are applicable to systems of all types, at any stage for different purposes.Slide 8

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

10. Story HeaderFeature: ship ordersAs a orders clerkI want to acknowledge and ship the order So thatwe fulfil a book orderScenario: ship a single book from stockGiven I select a valid order And the ordered book is in stockWhen I choose ‘acknowledge and ship’Then order status is changed to ‘shipped’ And an address label is printedStructured stories (other variations exist)Slide 10Key wordStory textEach Story has multiple ScenariosScenarios can be data driven

11. Anatomy of a business story headerIntelligent Testing, Improvement and AssuranceSlide 11The story brings together these aspects so we can view the feature from different viewpoint to explore it

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

13. Personas could be “18 year old male gamer” or “65 year old female retired nursery school teacher” for example.Anatomy of a scenarioIntelligent Testing, Improvement and AssuranceSlide 12The parallel with test cases is obvious:

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.

16. If I do – stop me.Stories may have many scenariosSlide 13Feature: Ship an OrderIn order to fulfil a book orderAs a orders clerkI want to acknowledge and ship the orderScenario: ship a single book from stockGiven I select a valid orderAnd the ordered book is in stockWhen I choose ‘acknowledge and ship’Then order status is changed to ‘shipped’And an address label is printedScenario: advise a book is out of stockGiven I select a valid orderAnd the ordered book is out of stockWhen I choose ‘message the purchaser’Then Enter message to purchaser advising the order statusAnd an email is sent to the purchasers email addressScenario: advise an item is discontinuedGiven I select a valid orderAnd the ordered book is discontinuedEtc. etc.

17. Scenario outlines allow scenarios to be data-drivenSlide 14Feature: Log in process As a system user In order to protect the system I want accounts to be protected with secure credentialsScenario: 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 1Agile Methods are EvolvingThere’s lots of themExpect consolidation

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

20. Emerging ApproachesWe seem to be in the middle of an explosion of new approachesMostly Agile but not exclusively soSome new but many rework established ideasLean, Kanban and anything oriental in vogueEmerging management methodsAcceptance-, Behaviour-, Design-, Test-Driven Development…Emerging specification and development methodsSlide 17

21. Wikipedia Search:‘driven development’Test-Driven Development*Feature Driven Development *BehaviorDriven Development *Tester Driven DevelopmentBusiness-Driven Development *Community Driven Development *Design-Driven DevelopmentProcess Driven DevelopmentTest-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 adaptiveSlide 19Regular TimeboxesEvent-DrivenWaterfallExtracted from: http://www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf

23. Feedback loops (NOT to scale)Slide 202-4 weeklyDailyHourlyMinutesSecondsPair ProgrammingUnit TestContinuous IntegrationDaily ScrumSprintFeedback ranges from personal observations (pairing), throughautomated 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 codeSlide 22Stories are not (usually) retainedThe Test code is crafted by handThe StoryThe TestThe Software

26. Behaviour-Driven – structured story to code using today’s toolsSlide 23The stories are captured as plain text, code or htmlThe Test code is generated by a tool from the storiesThe StoryThe TestThe Software

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

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

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

30. Stories and the range of development approachesSlide 27“We’re not structured, let’s go Agile” Aaarghhh!Process FormalityWaterfall/StructuredNo man’s land‘Pure’ AgileAgileHigh Structure/FormalityWhere Stories Are MeaningfulA one-dimensional view of the range of approaches

31. Varying formality, but ALL require discipline

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

33. Stories won’t work where they are regarded as ‘throwaway’ in Agile projects (or anywhere)Slide 28Intelligent Testing, Improvement and AssuranceCustomer DomainStories and Structured ProjectsStories validaterequirements+ Test DetailingRequirementsStories derived from written requirements can be used to walk-through business scenarios and when users see the proposed system ‘in action', requirements anomalies stand out and trigger informed discussions of situations, variations and outcomes. A disciplined approach to story-writing and…StoriesStories derivedfrom requirementsTests derivedfrom storiesAcceptanceTestersSupplier DomainStories generatetest code for TDDStories examplethe rulesRequirementsDefine rulesDevelopers using TDD can use business stories as a ‘starter for 10’

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

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

36. Requirements  Stories orStories  Requirements?Requirements are written for the benefit of ITComplete, concise, precise, consistent, unambiguousOr none of the aboveUsers want to tell stories and provide examplesThe analysts transform these into requirements for the techies to work withBut if stories are part of the process, the natural, iterative approach to requirements elicitation, analysis and validation fits nicelySo… adopt an Agile approach to requirements in your structured process?Intelligent Testing, Improvement and AssuranceSlide 30At which point the analysts say, “but we’ve always worked that way”

37. Stories support all development methodsIntelligent Testing, Improvement and AssuranceSlide 31

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

39. So we need a tool that will…Manage business definitionsIndex defined terms throughout requirements, stories and scenariosCapture requirements and story detail, and cross-refer themOutput requirement and story content in an easy-to-review formatOutput BDD/TDD code for use by developers.Intelligent Testing, Improvement and AssuranceSlide 33

40. How to Test Requirements with StoriesIntelligent Testing, Improvement and AssuranceSlide 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 AssuranceSlide 35As 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 AssuranceSlide 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 AssuranceSlide 37

44. Typical questions to ask of a requirementWhat 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 AssuranceSlide 38DefinitionFeatureOutcomeScenariosPredictionAmbiguityMissing

45. D e F O S P A MDefinitionsFeaturesOutcomesScenariosPredictionAmbiguityMissingIntelligent Testing, Improvement and AssuranceSlide 39See HandoutIdentify the termsOne story per featureOne scenario per outcomeOne scenario per scenarioCan’t predict? Scenario + guess outcomeTwo stories with conflictsAdd a story as a suggestion

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

47. D e F O S P A M – Exercise 0DefinitionsFeaturesOutcomesScenariosPredictionAmbiguityMissingIntelligent Testing, Improvement and AssuranceSlide 41The calculator will accept three inputs: a number A, an operator O and another number, B.

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

51. The calculator will print the result as a real number with up to 20 significant digits.Using Testela

52. Accessing Testela BETANetwork: checkout the posters on the wallsAccessing Testela through your browserAccount details: “usernnn@testela.com” password: “password”nnn is 001–100 – I’ll allocate numbers to youWhen you log in, click ‘edit profile’ and change your details (and change password too perhaps)Intelligent Testing, Improvement and AssuranceSlide 43

53. Features we’ll use todayRequirementsStoriesScenariosDictionaryExport Feature/ScenariosExport Unit TestsIntelligent Testing, Improvement and AssuranceSlide 44

54. Exercise 1: Adding your first storyProduct tab-> Click ‘Add Story’Select requirement, role, leave ‘assigned to’ as isSubmitClick ‘Find Stories’ and user filter to find your storyClick ‘Add a scenario’ – confirm itClick ‘View All Story Scenarios’Intelligent Testing, Improvement and AssuranceSlide 45