Successfully reported this slideshow.
Your SlideShare is downloading. ×

Agile Requirements Exploration: How Testers Add Value

Ad

Copyright	2016	:	Lisa	Crispin	and	Raji	Bhamidipa9	
With	material	from	Janet	Gregory,	and	from	Discover	to	Deliver		
by	Ell...

Ad

Lisa	(with	Janet	Gregory):	Agile	
Tes/ng	2009	
More	Agile	Tes/ng:	2014	
@lisacrispin	
www.lisacrispin.com		
www.agileteste...

Ad

Who	are	testers?	
Who	are	business	analysts?	
Who	are	programmers?	
Who	are	managers	of	some	kind?	
	
Agile	experience	
Ne...

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Loading in …3
×

Check these out next

1 of 81 Ad
1 of 81 Ad
Advertisement

More Related Content

Advertisement
Advertisement

Agile Requirements Exploration: How Testers Add Value

  1. 1. Copyright 2016 : Lisa Crispin and Raji Bhamidipa9 With material from Janet Gregory, and from Discover to Deliver by Ellen Go6esdiener and Mary Gorman
  2. 2. Lisa (with Janet Gregory): Agile Tes/ng 2009 More Agile Tes/ng: 2014 @lisacrispin www.lisacrispin.com www.agiletester.ca Raji BhamidipaJ So you want to be a scrum master? 2016 www.raji.me @raji_bh 2
  3. 3. Who are testers? Who are business analysts? Who are programmers? Who are managers of some kind? Agile experience New (less than 6 months) > 6 months > 1 year > 5 years > 10 years? 3
  4. 4. • Coffee break 11 – 11:30 • Lunch 13:00 – 14:15 • Coffee break 16:15 – 16:30 • Finish at 18:00 4
  5. 5. •  Share experiences •  PracJce techniques to elicit, explore specificaJons, build shared understanding •  Perhaps some brand new ideas! •  Inspect and adapt as we go •  You’ll leave with some experiments to try 5
  6. 6. • Techniques that your team can use to help your customers idenJfy the right features to build • Ways to enable shared understanding of features and stories, and tesJng consideraJons. 6
  7. 7. • Small differences can cause big mispercepJons • The classic “Jre swing” metaphor - each stakeholder has own viewpoint, agenda
  8. 8. 8 What’s slowing you down? Gehng in the way of shared understanding? •  Write one problem per sJcky note. •  Share with your table group. •  Post on your wall chart by the parachute. Group related problems.
  9. 9. 9 Intro Req’ts & TesJng EssenJals Big Picture Release & Feature Levels Explore with Examples IteraJon Level Stories - 7 dimensions -  funcJonal -  non-func’l -  quadrants -  mindset -  levels of detail -  Using 7 dimensions -  Tools to help -  ATDD -  Example mapping -  using acceptance tests Wrap-up Wrap-UP
  10. 10. 10 Copyright 2016 : Janet Gregory – DragonFire Inc.
  11. 11. 11 Copyright 2016 : Janet Gregory – DragonFire Inc.
  12. 12. 12 Levels of Precision
  13. 13. 13 Intro Req’ts & TesJng EssenJals Big Picture Release & Feature Levels Explore with Examples IteraJon Level Stories - 7 dimensions -  funcJonal -  non-func’l -  quadrants -  mindset -  levels of detail -  Using 7 dimensions -  Tools to help -  ATDD -  Example mapping -  using acceptance tests Wrap-up Wrap-UP
  14. 14. 14
  15. 15. 15 Meaning Descrip9on I Independent Self-contained, so no inherent dependency on another user story N NegoJable Can be changed and rewri6en unJl they are accepted into an iteraJon V Valuable Relevant and necessary; linked to a business goal E EsJmable Must be able to size (or esJmate) the story S Small Small enough to have a certain level of certainty T Testable Must be able to test it Origins: Bill Wake, 2003
  16. 16. func9onal nonfunc9onal www.DiscoverToDeliver.com/visual-language.php Source: DiscoverTo Deliver, Gottesdiener & Gorman, 2012
  17. 17. “ an aspect of a product that expresses product capabiliJes or things the product must do for its users.” - includes users, acJons, data and control product dimensions Ellen Go6esdiener, Mary Gorman 17
  18. 18. agile tesJng quadrants (based on Brian Marick’s matrix)
  19. 19. Amablé Autobus tour bus company -- see handout Choose a feature: 1.  Ability to assign and schedule subsJtute buses and drivers for transporJng tour groups around Madrid 2.  Ability to noJfy staff at desJnaJon when bus is broken down, along with a plan of acJon 19
  20. 20. 20 As the scheduler, I need to schedule regular hours as well as add additional hours for overtime hours to the payroll system So that the drivers get paid correctly.
  21. 21. 21 Dimension Ques9ons User Is the scheduler an administrator of the system? Or is she a data entry person only? Data Is Jme measured in hours or minutes? AcJon Can the drivers add their hours in manually, or do they submit Jme sheets? How does she find out about extra hours? Control Do the Jmesheets have to be approved by a supervisor or somebody?
  22. 22. In your group, using your feature: 1.  Ask quesJons about funcJonal requirements for the dimension you have been given. 2.  Write each individual quesJon on a sJcky note and put on the Dimensions wall chart. 22
  23. 23. “ aspects of a product that express properJes that the product must have” -  includes environment and interface dimensions -  Also known as “non-funcJonal requirements” or “para-funcJonal requirements” Go6esdiener, The Sosware Requirements Memory Jogger 23
  24. 24. 24
  25. 25. agile tesJng quadrants
  26. 26. 26 As the scheduler, I need to schedule regular hours as well as add additional hours for overtime hours to the payroll system So that the drivers get paid correctly.
  27. 27. 27 Dimension Ques9ons Interface Who / what else has access to the scheduling system? Environment Can it be entered remotely or is it desktop only? Quality A6ributes Are there performance requirements? Can I assume there is only one person accessing at a Jme? What level of security do we need for the scheduler?
  28. 28. In your group, using the same feature… 1.  Ask quesJons about quality a6ributes for the dimension you have been given. 2.  Write each individual quesJon on a sJcky note and put with the Dimension wall chart. 28
  29. 29. 29 Intro Req’ts & TesJng EssenJals Big Picture Release & Feature Levels Explore with Examples IteraJon Level Stories - 7 dimensions -  funcJonal -  non-func’l -  quadrants -  mindset -  levels of detail -  Using 7 dimensions -  Tools to help -  ATDD -  Example mapping -  using acceptance tests Wrap-up Wrap-UP
  30. 30. 30 Levels of Precision
  31. 31. Can be used at product backlog level as well as at story level • Helps visualise a users journey through the product • Useful tool for visualising product backlog 31
  32. 32. 32
  33. 33. We will create a ‘now map’. How did you start your day and get here this morning? 33
  34. 34. User Interface Action Data Control persona user role map context diagram prototype relationship map business process diagram capability map dependency graph story, story map use case value stream map data model state diagram business policy, rule decision table decision tree Source: DiscoverTo Deliver, Gottesdiener & Gorman, 2012
  35. 35. 35 As the scheduler, I need to schedule regular hours as well as add additional hours for overtime hours to the payroll system So that the drivers get paid correctly.
  36. 36. 36
  37. 37. 37 Name: Sarita the Scheduler Schedules buses Schedules bus drivers Matches bus drivers to buses Arranges emergency buses and drivers Ensures hours get logged Liaises with the bus maintenance Detailed oriented Likes working with numbers Likes trying new ideas Likes the outdoors, camping Introvert Doesn’t like conflict DescripJon Values Likes
  38. 38. 38 Schedule regular shiss Scheduler Driver Payroll Accepts shiss Reports hours (including overJme) Validates hours Submits to payroll Creates payment Driver gets paid
  39. 39. 39
  40. 40. Scenarios for payment of hours 1.  Regular hours only 2.  Regular, plus overJme 3.  Regular, plus addiJon call-out due to bus breakdown 4.  Call-out only due to bus breakdown 40
  41. 41. 41 Scenarios Business Policies Regular hours only Seasonal part-Jme hours paid Regular plus overJme OverJme is paid at 1.5 x regular Call-out for bus breakdown AddiJonal compensaJon for extra call
  42. 42. Consider personas, process flow, context and state diagrams for your feature, what scenarios and business policies can you find. Pair up, each pair try a tool and report to the group. What quality a6ributes might be applicable at the feature level? Consider all 7 dimensions. 42
  43. 43. 43 • Write one item per sJcky note. • Share with your table group. • Post on your wall chart by the race car. How can you explore funcJonal requirements and quality a6ributes to improve quality?
  44. 44. 44 Intro Req’ts & TesJng EssenJals Big Picture Release & Feature Levels Explore with Examples IteraJon Level Stories - 7 dimensions -  funcJonal -  non-func’l -  quadrants -  mindset -  levels of detail -  Using 7 dimensions -  Tools to help -  ATDD -  Example mapping -  using acceptance tests Wrap-up Wrap-UP
  45. 45. Feature (with examples) User Story High- Level AT Fix Defects Code, test & automate story ATDD Acceptance Test Driven Development Accept Story Explore Examples 45
  46. 46. •  To elicit requirements •  To reduce uncertainty •  To test people’s understanding of the requirement 46 Credit and thanks to Brian Marick “That’s not right” can be music to your ears •  Can become the actual tests •  Are a form of specificaJon
  47. 47. 47 As a user, I want guidelines to create a strong password, so that I have limited risk for identity theft
  48. 48. 48 Copyright 2016 : Janet Gregory – DragonFire Inc. 1.  Pick a partner table group 2.  Using the blue index cards, invent 3 secret business rules for “Create a strong password” story 3.  Write 3 (and only 3) examples on the white cards to express those rules <2 min> 4.  Now pass them to your partner table. 5.  Guess the rules based on the examples – write them on the sJcky notes, and pass them back 6.  Let’s stop and reflect
  49. 49. 49 • Write more examples to clarify the rules – sJll no conversaJon except yes or no. •  Two more iteraJons: Pass examples to your partner table and have them guess the rules. Now: Have a conversaJon about the story.
  50. 50. 50 What did this exercise show you? What did you learn? Are rules or examples be6er? Why or why not?
  51. 51. 51 From MaR Wynne
  52. 52. As a user, I want guidelines to create a strong password, so that I have limited risk for iden/ty theC 52 Story Rules Examples QuesJons 1.  Minimum 8, maximum 32 characters 2.  One or more of each: lower-case le6er, upper-case le6er, number, punctuaJon mark Valid: p4ssW0rd!, paSSw.rDp Invalid: p4ssword1, p4ssw@d, Pa%swd. What wording to use for the error messages? Should we have a password strength meter?
  53. 53. 53 Create a story from your feature, write it on a yellow card. For example: •  Send email to hotel staff … •  Select an alternate bus …
  54. 54. For your story, 1.  IdenJfy a couple of obvious business rules (blue cards) 2.  Explore examples for at least one rule (green cards) 3.  Are there quesJons (pink cards) 54
  55. 55. 55 • Write one item per sJcky note. • Share with your table group. • Post on your wall chart by the abyss. What pizalls do you want to help your team avoid?
  56. 56. 56 Intro Req’ts & TesJng EssenJals Big Picture Release & Feature Levels Explore with Examples IteraJon Level Stories - 7 dimensions -  funcJonal -  non-func’l -  quadrants -  mindset -  levels of detail -  Using 7 dimensions -  Tools to help -  ATDD -  Example mapping -  using acceptance tests Wrap-up Wrap-UP
  57. 57. 57 Levels of Precision
  58. 58. Define, constrain or enable behaviour of the sosware, business processes, data structure 58 Business goals Business policies Business rules
  59. 59. It may help priori/ze stories Example: Schedule a distributed team meeJng in our scheduling app. 1.  MeeJngs with > 2 Madrid a6endees need a meeJng room 2.  Remote a6endees must have video link 3.  MeeJngs are during normal work hours for all a6endees (employees located across Europe). 59
  60. 60. • Where can you get the data? ◦ Data dicJonary, model, fixtures • What kind of data might you need? • Is there appropriate test data? 60
  61. 61. • Means to evaluate capability from a user’s perspecJve • Provide the scope of the story (or feature) • Results are accepted or not accepted ◦ If not – revisit! 61
  62. 62. Scenario example: As a user with valid login credenJals, I can log in and see the landing page. Test might look like: •  Given Janet has a valid login, •  When she enters her valid username and password, •  Then she sees the landing page. 62 User Email Password Expected Result Comments Jara jara@example.com Passw0rd22 Logged in Valid login scenario
  63. 63. 63 As a driver called in as a replacement, When I submit hours including overtime, I receive the correct pay amount. Rule: 1.5 x regular pay if more than 1 hour over scheduled driving Jme Rule: 1 hour extra pay in addiJon to overJme hours if call-in replacement
  64. 64. BDD – Behaviour driven development Captures shared understanding, guides development. Given - precondiJon When – trigger, acJon Then – consequences, results 64
  65. 65. Story As a driver called in as a replacement, When I submit hours including overJme, I receive the correct pay amount. Scenario Regular hours plus overJme plus call-in replacement pay business rule(s) OverJme is calculated as: (Total driving Jme minus regular hours) * overJme Given pre-condition(s), state Driver exists and drove his bus fixed data Driver: José, worked 40 hours, including 4 overJme hours when called in as a replacement Regular wage: 20 euros/hour OverJme percentage: 150% (1.5 x regular pay) When action Driver submits hours input data Hours submi6ed: 36 regular, 4 overJme call-in replacement Then observable outcome: message, output Total wages: 860 post-condition Paycheck cut
  66. 66. Given 40 hours has been worked in one week When the driver submits overJme hours Then the driver gets paid for regular hours plus the overJme hours Given 40 hours has been worked in one week When the driver submits overJme hours Then the scheduler submits the regular hours plus the overJme hours for payment to payroll
  67. 67. Driver Regular Wage Regular hours Over9me hours Total paid José 20.00 36.0 4.0 840.00 José 20.00 36.0 2.0 780.00 José 20.00 30.0 0.0 600.00 67
  68. 68. 1.  Use the story from your example mapping 2.  Create BDD acceptance tests using Given/ When/Then format 3.  Then idenJfy possible examples (test data) that could be input in a tabular format 4.  Show your tests to another table group. Do they understand the capability to be delivered? 68
  69. 69. • Interfaces ◦ tesJng design – how does it interface with other apps? ◦ Different plazorms, consistency, how does it react? • Quality a6ributes ◦ Constraints to be considered with every story • ImplementaJon environments ◦ Requirements that limit build and deploy opJons 69
  70. 70. • Consider the quality a6ributes – are there any that are applicable to your story? • Are there any interfaces you need to consider? • What about your environments? Anything specific to worry about? Discuss in your teams 70
  71. 71. • Stories are a reminder to have a conversaJon • Acceptance tests agreed upon with the customer ◦ with examples to express business rules • ConversaJon – examples, clarificaJons Requirement Story Acceptance Tests with examples Conversa9on + + = 71
  72. 72. 72 • Write one item per sJcky note. • Share with your table group. • Post on your wall chart by the abyss. What experiments can your team try?
  73. 73. 73 Intro Req’ts & TesJng EssenJals Big Picture Release & Feature Levels Explore with Examples IteraJon Level Stories - 7 dimensions -  funcJonal -  non-func’l -  quadrants -  mindset -  levels of detail -  Using 7 dimensions -  Tools to help -  ATDD -  Example mapping -  using acceptance tests Wrap-up Wrap-UP
  74. 74. 74 Examples Tests Adapted from: Agile Alliance FuncJonal TesJng Tools Open Space Workshop 2007, & EBG ConsulJng 2012
  75. 75. 75 Levels of Precision
  76. 76. Assemble op9ons Source: DiscoverTo Deliver, Gottesdiener & Gorman, 2012 76
  77. 77. 77
  78. 78. And always, strive for quality! photoshd.wordpress.com/2008/04/24/13/
  79. 79. Agile Tes/ng: A Prac/cal Guide for Testers and Agile Teams More Agile Tes/ng: Learning Journeys for the Whole Team www.agiletester.ca, www.lisacrispin.com Email: lisa@lisacrispin.com 79 Save 35%: h6p://informit.com/ swtesJng or h6p://informit.com/ agiletest Use code AGILETESTING
  80. 80. Ques9ons?
  81. 81. • Go6esdiener, Ellen and Gorman, Mary, Discover to Deliver, 2012 • Wynne, Ma6, "Introducing Example Mapping", h6p://bit.ly/ 1iw19w4 • Wynne, Ma6 and Aslak Hellesoy, The Cucumber Book: Behavior-Driven Development for Testers and Developers, PragmaJc Programmers, 201 • Adzic, Gojko, Specifica/on by Example: How Successful Teams Deliver the Right SoCware, Manning, 2011 • Adzic, Gojko, Bridging the Communica/on Gap, Neuri Limited, 2009 •  Gärtner, Markus, ATDD By Example: A Prac/cal Guide to Acceptance Test-Driven Development, Addison-Wesley, 2012a • Keogh, Liz, h6p://lunivore.com - look for her posts on BDD, Real OpJons 81

×