Happy Path vs. Testing Edge Cases

Now that we've gotten a fairly basic test case created, 0:01 it's time that we start to test more of the less obvious pathways. 0:04 In software, we often like to use the terms happy path and 0:09 edge cases as ways to describe what the feature was intended to do, 0:13 versus what are users might actually do. 0:19 Let's picture that we're at a really nice grassy park, 0:23 a path cuts down the middle of it and it's the only way to get through. 0:27 This is our happy path where nothing wrong can happen as long as we stay on it. 0:32 We might become bored though, and venture off that path. 0:38 Some of the ground here is muddier than we thought. 0:41 There's bramble and bushes to get through. 0:44 And it's pretty obvious that the park creators never intended for 0:46 us to walk off of the path. 0:50 In a lot of ways, code ends up being like this when it's first written, 0:52 where designers and developers only really think about the clear cut happy path for 0:56 users to take. 1:01 It's our job as QA engineers to think about what the common scenarios are, 1:03 where people will wander off of that path. 1:07 That seems pretty difficult to do, though, doesn't it? 1:10 How can we possibly know everything that our users will want to do 1:14 that we didn't think of? 1:18 Maybe instead of typing in their name, 1:20 the user will type in their user ID by mistake. 1:22 Maybe a user has a particularly long name that a text box can't handle. 1:26 Or maybe, a user is having a slow internet connection and decides 1:32 to click the save button very rapidly over and over again, and it causes a big error. 1:36 The answer is that we can't possibly think of everything users will do. 1:42 Experience will teach us a lot about what to look for. 1:46 There is a lot of fairly common things that users will do however, 1:50 that we can look for. 1:54 The most common places where users can stray heavily off the happy path 1:56 are inputs. 2:00 So anything where the user can type something in, add a photo or 2:02 a file, or quick and drag, or move things in the application. 2:06 So think web forms, add a file button, drag and 2:11 drop images, or even games that involve where the mouse pointer is on the screen. 2:15 Our other most common area is state management. 2:20 This can get complicated though. 2:23 Basically, it is doing an action in one part of the app 2:26 that affects what can happen in another part of the app. 2:29 Think workflows or how the user navigates through the application. 2:32 If a user goes to one area before they've done an important action in another part 2:37 of the app, then it's probably outside the normal happy path. 2:41 And we need to test what happens in that case. 2:45 These two things will make up the majority of testing user edge cases. 2:48 For inputs you can ask questions like, 2:53 can the user enter anything in this text field? 2:55 And if so, how much can they enter? 2:58 One very common issue is when a user tries to enter in 3:01 way more text than what the developers intended. 3:04 Is this icon always draggable and if so, where can I drag it? 3:08 Sometimes, users will move an icon to a weird part of the screen that we didn't 3:13 think of, and make the icon disappear entirely. 3:18 For state management, we can ask questions like, 3:21 can I click this icon if this other icon is highlighted? 3:24 If the developers were trying to lock out the screen to your other actions, 3:29 then they probably didn't want users clicking anything else. 3:33 But, it's best to assume that users will still try to do that though. 3:37 Our RSVP app has a few places where we can look for these edge cases. 3:42 In the next video, we'll be writing a test for some of these common edge cases. 3:46 Our added name feature from the first video 3:51 involves a text field which allows the user to re-enter whatever they want. 3:54 Some things to consider here are, 3:59 how many characters should the user be allowed to enter? 4:01 What if the user has a very long name with no spaces? 4:04 What if the user has some special characters in the name that 4:07 aren't supported by the website? 4:11 A few state management things here happen too. 4:13 For instance, it's possible to hide users who haven't responded yet. 4:16 What happens when we hide users while editing a user? 4:22 On the whole, edge cases are going to make up 4:26 a lot more of your test cases than just the happy path. 4:29 So it's good to understand them. 4:33 But also understand that you simply can't think of everything. 4:35 Users will find other ways to break the application. 4:39 Our job is to simply try to stay as far ahead of them as we can within reason. 4:42 In our next video, we'll be putting some of those edge cases into our 4:48 edit button test from the last video. 4:52 I'll see you then. 4:55