Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Happy Path vs. Testing Edge Cases4:56 with Ryan Saul
In software we use the terms Happy Path and Edge Cases as ways to describe what the feature was intended to do, versus what our users might actually do.
- Happy Path: Testing with only the acceptance criteria of the feature.
- Edge Cases: Testing outside of the base assumptions, finding different ways to use a feature that were not intended.
- Inputs: Where a user can create their own data or interact with the application
- State management: features that may work in different ways depending on actions taken by the user
Common things to look for with user behavior:
- Inputs - anything where the user can type something in, add a photo or file, or click/drag/move things in the application.
- State management - Doing an action in one part of the app that affects what can happen in another part of the app. Think workflows or how the user navigates through the application.
Common edge case questions to ask:
Can the user enter anything in this text field?
- How much can they enter?
- Can they enter special characters?
- Is it numbers only, alphanumeric characters only, date only?
Is this icon always draggable?
- Where can I drag it?
Can I upload a file?
- What kind of files are supported?
- How large can the file be?
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
You need to sign up for Treehouse in order to download course files.Sign up