Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Severity vs. Priority6:25 with Ryan Saul
An important distinction to make when you are reporting bugs is between the severity and the priority of the defect. This video describes the difference so that you can better understand and report effectively.
- Severity: A rigid definition of how bad a defect affects the system graded from lowest to highest.
- Priority: What the company's rank is for when to fix a defect in relation to other things that are being worked on.
- Feature Request: A proposed change to the software that is not a flaw or defect in the intended use of the software.
- Defect backlog: The list of defects that are not currently assigned to be worked on, but are known to the company and could easily be pulled in when there is extra time.
An important distinction to make when you're reporting bugs 0:00 is between the severity and the priority of the defect. 0:04 Now these terms sound very similar and 0:08 you may see them used interchangeably in some workplaces. 0:10 But you should really strive to make sure that these terms are used differently. 0:14 Severity should be a rigidly defined set of criteria for 0:19 how bad a bug is to the system. 0:23 Usually a severity rank is a sign like this. 0:26 Low severity, visual defects that are easily overcome by the user and 0:30 do not affect their data or their workflow. 0:35 Medium severity, defects that may affect the data or 0:38 workflow but have a clear work around, which we mentioned in the last video. 0:42 And high severity, defects that may greatly impact the data or 0:47 the users workflow and there are no clear workarounds. 0:52 On the other hand, priority exists as the company's definition 0:56 of how quickly the bug needs be fixed, ranked again from low to high. 1:01 Low priority defects are not as important as medium, 1:07 which aren't as important as high defects. 1:11 It's helpful for the company to define criteria for priority too, but 1:14 in terms of when defects need to be fixed by. 1:18 For instance, high priority defects need to be fixed before the next release. 1:21 Medium defects can be fixed within any of the next six months of releases. 1:27 And low priority defects have no set time that they need to be fixed by. 1:32 And these are just examples though. 1:36 Your company may come up with something entirely different. 1:39 What's important to agree on is what low, medium, and 1:43 high means here, so that everyone's expectations are the same. 1:47 Generally low severity and low priority or high severity and 1:51 high priority go pretty hand in hand. 1:55 Your company will wanna prioritize a lot of defects by their impact to 1:58 the customer, but it's still possible to have a low severity yet 2:02 high priority defect and vise versa. 2:07 This is why making the distinction between the two is very important. 2:11 We might have a low severity bug that needs to be fixed right away 2:15 because our management team has decided it looks too terrible not to fix it. 2:19 We might also have a high severity but low priority bug 2:24 because none of our customers are using that part of the application or 2:29 fixing it would cost the company weeks of work. 2:32 Typically low priority defects and others that simply can't be resolved quickly get 2:36 pushed to what we call a backlog or more specifically, a defect backlog. 2:41 This is a list of unresolved defects that you can keep track of. 2:48 This can help your company prioritize what needs to be fixed in the next release 2:52 by having a place that you can sort all of your defects by their age and severity. 2:56 Having a list somewhere, like in the popular Jira application, 3:02 is also a useful place to give developers a place to find easy things to work on 3:05 if they are done with other work. 3:10 But also remember that while some defects are either low severity or 3:12 low priority, there is still a concept of death by 1,000 paper cuts. 3:16 Where all those little low severity defects really add up. 3:22 It's very easy to keep pushing low-priority defects out to future 3:27 releases that never actually arrived and sooner or later your customers will 3:31 notice that those glaring but otherwise benign defects are still hanging around. 3:35 Push these to get fixed. 3:42 One strategy I've seen in the past is to put many of these bugs 3:44 into related bundles. 3:47 So if there are five or six low priority defects for 3:49 your header bar, bundle them all together to get them fixed at once. 3:52 Your customers will definitely thank you. 3:57 Before I leave you on this section about bugs, 4:00 I wanna talk about one more distinction that often gets made when 4:03 deciding what makes a bug and when to fix it. 4:07 A lot of bugs that might be reported are actually feature requests and not bugs. 4:10 Problems with the way the UI has been designed, or maybe the data has been laid 4:16 out in the database, may be problems for the end user, but if they're otherwise 4:21 working as they were designed, then they are not considered bugs. 4:26 Bugs should be flaws in the way the software was intended to be used, 4:31 not the way a user wants the software to be used. 4:35 So with that, we usually like to make the distinction between feature requests and 4:39 bugs as working as designed or not. 4:43 This can be tough, though, because sometimes the design of the software 4:47 is just objectively bad for the user. 4:51 But it's important to triage those problems with everyone who should be 4:55 involved in creating new features. 4:58 Perhaps the design was intentional to make the users act in a very specific way, 5:01 even if it's not working out. 5:06 Let me give an example. 5:08 In our RSVP app, it's possible to edit a person's card so 5:10 that you can change the name around. 5:13 But it's also possible to click the Confirmed checkbox while you 5:18 are editing it. 5:22 I think that's counterproductive, since we want the user to focus on 5:24 editing the username and saving it before they can interact with the card. 5:28 But this is how the application was actually designed, and 5:32 was actually a choice made by our product manager, so we shouldn't file a defect. 5:35 We should instead file a feature request. 5:40 You might also remember an example I gave in our first video, where I argued that 5:44 the styling of some boxes was inconsistent and therefore a defect. 5:48 The style wasn't written down anywhere, though, and 5:53 didn't match what I'd otherwise expect to see in the application. 5:56 So there's a little bit of intuition happening there. 6:00 But the other important point is that I approach the team about it to find out if 6:04 it was by design or not. 6:08 Turns out it wasn't and 6:10 that the product manager agreed with me that it should be fixed. 6:12 That concludes our section on bug reporting. 6:16 I look forward to seeing you in our next and final section improving QA practices. 6:19 See you there. 6:24
You need to sign up for Treehouse in order to download course files.Sign up