1 00:00:07,225 --> 00:00:09,654 - When we talk about user scenarios 2 00:00:09,654 --> 00:00:12,173 you want to start with a happy path. 3 00:00:12,173 --> 00:00:14,815 You have to have at least one. 4 00:00:14,815 --> 00:00:17,000 You might have several misbehaviors. 5 00:00:17,000 --> 00:00:19,081 When we're thinking about those scenarios again, 6 00:00:19,081 --> 00:00:22,323 we want to be thinking about the business rules as well 7 00:00:22,323 --> 00:00:24,919 because we really want to get that understanding 8 00:00:24,919 --> 00:00:27,583 of that feature and without the business rules 9 00:00:27,583 --> 00:00:30,640 mapping to the examples and the scenarios, 10 00:00:30,640 --> 00:00:32,478 you get lost. 11 00:00:32,478 --> 00:00:35,313 - Thinking about more business rule might make us realize, 12 00:00:35,313 --> 00:00:38,730 we actually need an additional story here 13 00:00:39,801 --> 00:00:42,565 or we need to make sure we do extra exploratory 14 00:00:42,565 --> 00:00:45,869 testing around these rules because they're pretty tricky 15 00:00:45,869 --> 00:00:47,571 and we want to make sure we get them right. 16 00:00:47,571 --> 00:00:48,948 We'll be talking about exploratory testing 17 00:00:48,948 --> 00:00:51,233 more in lesson five. 18 00:00:51,233 --> 00:00:54,158 Use examples that pertain to the business value. 19 00:00:54,158 --> 00:00:56,884 Again this isn't the time to think 20 00:00:56,884 --> 00:00:59,685 of every possible edge case and as testers 21 00:00:59,685 --> 00:01:01,888 we can usually think of lots of those. 22 00:01:01,888 --> 00:01:04,650 Again depending on risks and the domain you're working in 23 00:01:04,650 --> 00:01:07,466 and the context and the level of detail that you need. 24 00:01:07,466 --> 00:01:09,861 In general we want to be focusing on 25 00:01:09,861 --> 00:01:13,788 what are we giving the user with this feature. 26 00:01:13,788 --> 00:01:16,690 We want just enough examples to clarify the desired 27 00:01:16,690 --> 00:01:17,755 and undesired behaviors, 28 00:01:17,755 --> 00:01:20,792 so that the developers know where to start. 29 00:01:20,792 --> 00:01:22,977 - You mentioned a really good point there 30 00:01:22,977 --> 00:01:26,930 that don't get carried away on all the edge conditions. 31 00:01:26,930 --> 00:01:29,632 A lot of times I've heard teams say, 32 00:01:29,632 --> 00:01:32,130 "We don't want the testers in these meetings 33 00:01:32,130 --> 00:01:34,235 "because they ask too many questions." 34 00:01:34,235 --> 00:01:35,251 (laughs) 35 00:01:35,251 --> 00:01:38,786 I find that it's not too many questions. 36 00:01:38,786 --> 00:01:41,369 The level of detail is too low. 37 00:01:42,757 --> 00:01:45,349 Instead of realizing they're at the feature level, 38 00:01:45,349 --> 00:01:49,108 they're asking questions down at the task level 39 00:01:49,108 --> 00:01:53,275 and so understanding that level is quite important as well. 40 00:01:55,235 --> 00:01:58,933 Some of the scenarios that we're thinking of, 41 00:01:58,933 --> 00:02:02,354 user enters a valid option for the information 42 00:02:02,354 --> 00:02:04,700 and receives a confirmation appointment. 43 00:02:04,700 --> 00:02:05,572 - That's the happy path. 44 00:02:05,572 --> 00:02:06,621 - That's the happy path. 45 00:02:06,621 --> 00:02:09,046 That's the expected behavior. 46 00:02:09,046 --> 00:02:12,633 What about if the user selects a time slot, 47 00:02:12,633 --> 00:02:17,053 enters all the information and then moves away from the page 48 00:02:17,053 --> 00:02:19,938 without the confirmation because the phone rang. 49 00:02:19,938 --> 00:02:22,631 - We really don't want that user to lose their data. 50 00:02:22,631 --> 00:02:23,951 People would really hate that. 51 00:02:23,951 --> 00:02:25,696 - What would you do if you come up 52 00:02:25,696 --> 00:02:27,304 with that kind of question? 53 00:02:27,304 --> 00:02:30,634 Would you say, make it so 54 00:02:30,634 --> 00:02:32,767 or would you come up with some concrete examples? 55 00:02:32,767 --> 00:02:34,537 - We might just make them know that we need 56 00:02:34,537 --> 00:02:36,456 to think of a way to mitigate that 57 00:02:36,456 --> 00:02:38,254 or we might even discuss some options like 58 00:02:38,254 --> 00:02:40,336 where we can cash that information in the browsers 59 00:02:40,336 --> 00:02:42,501 so that they an come back and they haven't lost it. 60 00:02:42,501 --> 00:02:45,204 - But you wouldn't solve all of them at this point in time. 61 00:02:45,204 --> 00:02:47,012 - Right, right. 62 00:02:47,012 --> 00:02:50,384 - What about say, sequel injection exploits? 63 00:02:50,384 --> 00:02:52,376 Somebody wants to get out of a pet salon 64 00:02:52,376 --> 00:02:54,375 and book up all our appointments 65 00:02:54,375 --> 00:02:59,223 because maybe they just are mad at the dog groomer? 66 00:02:59,223 --> 00:03:00,056 - Exactly. 67 00:03:01,405 --> 00:03:03,811 All kinds of evil hacks could happen 68 00:03:03,811 --> 00:03:05,977 and we talked about things like 69 00:03:05,977 --> 00:03:08,618 the importance of privacy of data, things like that. 70 00:03:08,618 --> 00:03:11,531 These are questions that are good to bring up 71 00:03:11,531 --> 00:03:12,618 and the answer might be, 72 00:03:12,618 --> 00:03:15,787 "Our architecture already takes care of that 73 00:03:15,787 --> 00:03:17,424 "or we take care of that at the database level, 74 00:03:17,424 --> 00:03:18,399 whatever it is." 75 00:03:18,399 --> 00:03:21,235 But asking that question because of the highrisk 76 00:03:21,235 --> 00:03:22,764 is appropriate. 77 00:03:22,764 --> 00:03:26,035 - Alright, next let's look at how we can actually 78 00:03:26,035 --> 00:03:29,035 use tests to guide your development.