Writing a Bug Report8:17 with Ryan Saul
In this video we’re going to show you how to create a bug report that your team can use to reproduce and fix problems in your software.
- Bug report: A formal write-up of a defect
- Workaround: How to get around the defect if it is blocking someone's workflow.
Bug Report Outline
Steps to Reproduce:
Bug Report Example
Name/Description: Invite Someone - Empty card created when submitting with no name
Location: Invite Someone
Screenshots/Videos: <include screenshot here>
Steps to Reproduce:
- Open RSVP app
- Without typing in a name, click Submit button.
Expected Result: Error should appear letting the user know that they need to enter a name before submitting.
Actual Result: A card is added to the Invitees list with no name.
Data Set: Default
Workaround: Edit the card and include name.
In this video, we're going to show you how to create a bug report 0:00 that your team can use to reproduce and fix problems in your software. 0:04 Bug reports are important to get correct, because it costs a lot of time for 0:09 developers to reproduce issues and find the right fix for them. 0:13 The better we can lead developers to the true defect, 0:18 the quicker the fix can happen. 0:21 Much of the bug fixing process involves recreating or reproducing the issue 0:23 in a way the developer can see in their own version of the software. 0:29 Bug reports need to give the developer 0:33 all of the details they would need to reproduce it. 0:36 So a bug report will include the following necessary parts. 0:39 A description or name of the bug, the steps to reproduce, 0:43 the expected result, and the actual result. 0:48 These are the most important things to the developer and 0:52 others who need to reproduce the defect. 0:56 A description or name of the bug should probably include where the bug happened in 0:59 a short blurb about what the bug is. 1:03 So like, Header bar- Logout 1:07 button does not log user out when clicked. 1:12 Try to do better than undescriptive names like, logout button does not work. 1:19 This doesn't really tell us anything about the actual problem, and 1:24 it will probably create some issues down the road 1:28 when we inevitably have another problem with the logout button. 1:31 I like to include a when in the name that quickly describes 1:34 how that problem came to be. 1:38 So in this case, I say, when clicked. 1:40 The steps to reproduce are directions for the developer on how to make 1:43 this defect happen locally, or maybe one of the test servers. 1:48 So here we list steps, kind of like how we would in a test case. 1:52 So we follow a simple step one, step two, step three type of formula. 1:56 And that's it. 2:01 More criteria to reproduce the issue 2:02 means that you need to add more qualifying steps. 2:05 So if our logout button only has a problem when logged in as an administrator, 2:08 we probably want to mention that in the first step. 2:13 In this case, our steps to reproduce would be log in to the application, 2:16 and then click the logout button in the header, simple. 2:23 So I'm going to add on to that last step, 2:30 click into the application as an administrator. 2:33 Now we want to write up the expected results, 2:39 which is what we want the application to do. 2:42 When I click the log out button, I want the application to log out and 2:45 take me to the log in screen. 2:49 So I'll write this in the expected results section. 2:51 Take the user back to the log in screen. 2:55 This is important to write down each time, because often the developer does not have 2:59 the same context that you do for what is expected to happen here. 3:04 And the reason that we're here is what is actually happening. 3:08 So we'll write down the actual outcome in the actual results section. 3:12 The button doesn't do anything when I click on it. 3:16 So I'll write that down here. 3:19 The logout button does not do anything when clicked. 3:22 Great, this is important so the developer can look for 3:29 what you are seeing and report if they are seeing something different. 3:32 Maybe they're seeing what happens in expected results for instance. 3:35 Maybe they're seeing something else entirely. 3:39 That's a pretty good start to our bug report, and 3:43 our developer could reasonably reproduce the issue and see what is wrong. 3:45 On top of all that, we probably want to include a bunch of other pieces of data, 3:50 so the location of the defect in the app. 3:55 I like to include this in the name of the bug, but 3:58 often bug reporting systems have a special place to categorize this. 4:00 Any particular data set or user role that needs to be used in recreating it. 4:05 In our log out bug example, we needed to use an administrator. 4:10 Any configuration notes, so if the bug is only seen in Firefox, 4:15 that would be a good piece of information to include. 4:20 Any screenshots or videos of the defect happening. 4:24 This is extremely helpful. 4:27 When you're demonstrating what is happening, 4:30 you can show things a lot better than you can describe them. 4:33 A picture is worth a thousand words. 4:37 A lot of screenshot programs include these big red arrows and text boxes that 4:39 you can put in your screenshots to make sure the problem is much more obvious. 4:44 Finally, any workaround used to get around the defect. 4:49 A workaround is simply how the user can still do what they wanna do 4:53 despite running into that defect, like how you might need to click through a few 4:58 other pages to get somewhere when another button isn't working. 5:03 Maybe the log out button works as long as you go back to the home page. 5:08 This is helpful if the defect is high or critical severity and 5:13 the user needs a way to keep working. 5:17 And this is how we file a defect. 5:19 Let's try to put this into practice by writing up the bug 5:22 we found in our last video. 5:25 If you remember, our defect was an issue where when we click submit, 5:27 the app creates a new card below with no name. 5:31 We expected an error to happen instead 5:35 that would tell the user that they need to include a name before they can submit. 5:38 So let's go over and try to create a new bug report for that. 5:42 First, let's name the bug. 5:46 We wanna put the location of the bug in the name, which is Invite Someone, so 5:48 Invite Someone, and we want to describe what happens and when. 5:53 So I'll call this Invite Someone- Empty 6:01 card created when submitting with no name. 6:06 This tells the developer where this happened, Invite Someone, and 6:11 it tells them what exactly happened and what the simple condition was. 6:15 That's the with no name part. 6:20 Since we do have a location here, I'm gonna add it right here, 6:23 which is Invite Someone. 6:26 For steps to reproduce, 6:29 we wanna list every step that we needed to get to this state. 6:31 So first we need to open the RSVP app. 6:35 This step is fairly obvious, but 6:39 I'm going to include it here anyway just to be complete. 6:40 And without typing a name, Click the Submit button. 6:44 Now I'm only including the without typing a name part because it might not be 6:52 totally obvious to the developer what the conditions were to get this defect. 6:56 These are all steps we need to reproduce this. 7:01 Now let's add expected results. 7:04 Errors should appear letting the user 7:06 know that they need to enter a name before submitting. 7:12 I'll let the developer decide how to handle exactly what it should look like 7:20 since a simple red box around Invite Someone would probably suffice. 7:25 They could also add a message in there telling the user what to do. 7:29 But we're not gonna tell them exactly what to do to fix that. 7:33 Now let's add the actual result. 7:37 A card is added to the invitee's list with no name. 7:40 By now the developers should be noticing that too, but 7:48 we wanna call attention to what the problem is specifically. 7:51 I'm also going to add a screen shot to the issue of the defect so 7:54 the developer knows exactly what they're looking for. 7:58 And that's it. 8:05 We don't need to provide a data set or any workarounds here, so 8:07 let's leave it at that. 8:10 In our next video we'll learn about bug severity versus priority. 8:12
You need to sign up for Treehouse in order to download course files.Sign up