1 00:00:00,760 --> 00:00:04,070 An important distinction to make when you're reporting bugs 2 00:00:04,070 --> 00:00:07,370 is between the severity and the priority of the defect. 3 00:00:08,370 --> 00:00:10,990 Now these terms sound very similar and 4 00:00:10,990 --> 00:00:14,480 you may see them used interchangeably in some workplaces. 5 00:00:14,480 --> 00:00:19,270 But you should really strive to make sure that these terms are used differently. 6 00:00:19,270 --> 00:00:23,740 Severity should be a rigidly defined set of criteria for 7 00:00:23,740 --> 00:00:26,290 how bad a bug is to the system. 8 00:00:26,290 --> 00:00:30,360 Usually a severity rank is a sign like this. 9 00:00:30,360 --> 00:00:35,030 Low severity, visual defects that are easily overcome by the user and 10 00:00:35,030 --> 00:00:38,140 do not affect their data or their workflow. 11 00:00:38,140 --> 00:00:42,380 Medium severity, defects that may affect the data or 12 00:00:42,380 --> 00:00:47,880 workflow but have a clear work around, which we mentioned in the last video. 13 00:00:47,880 --> 00:00:52,710 And high severity, defects that may greatly impact the data or 14 00:00:52,710 --> 00:00:56,830 the users workflow and there are no clear workarounds. 15 00:00:56,830 --> 00:01:01,140 On the other hand, priority exists as the company's definition 16 00:01:01,140 --> 00:01:06,160 of how quickly the bug needs be fixed, ranked again from low to high. 17 00:01:07,440 --> 00:01:11,070 Low priority defects are not as important as medium, 18 00:01:11,070 --> 00:01:14,170 which aren't as important as high defects. 19 00:01:14,170 --> 00:01:18,350 It's helpful for the company to define criteria for priority too, but 20 00:01:18,350 --> 00:01:20,760 in terms of when defects need to be fixed by. 21 00:01:21,790 --> 00:01:27,150 For instance, high priority defects need to be fixed before the next release. 22 00:01:27,150 --> 00:01:32,200 Medium defects can be fixed within any of the next six months of releases. 23 00:01:32,200 --> 00:01:36,480 And low priority defects have no set time that they need to be fixed by. 24 00:01:36,480 --> 00:01:39,920 And these are just examples though. 25 00:01:39,920 --> 00:01:43,530 Your company may come up with something entirely different. 26 00:01:43,530 --> 00:01:47,260 What's important to agree on is what low, medium, and 27 00:01:47,260 --> 00:01:51,810 high means here, so that everyone's expectations are the same. 28 00:01:51,810 --> 00:01:55,990 Generally low severity and low priority or high severity and 29 00:01:55,990 --> 00:01:58,820 high priority go pretty hand in hand. 30 00:01:58,820 --> 00:02:02,890 Your company will wanna prioritize a lot of defects by their impact to 31 00:02:02,890 --> 00:02:07,860 the customer, but it's still possible to have a low severity yet 32 00:02:07,860 --> 00:02:11,070 high priority defect and vise versa. 33 00:02:11,070 --> 00:02:14,850 This is why making the distinction between the two is very important. 34 00:02:15,870 --> 00:02:19,570 We might have a low severity bug that needs to be fixed right away 35 00:02:19,570 --> 00:02:23,725 because our management team has decided it looks too terrible not to fix it. 36 00:02:24,735 --> 00:02:29,055 We might also have a high severity but low priority bug 37 00:02:29,055 --> 00:02:32,895 because none of our customers are using that part of the application or 38 00:02:32,895 --> 00:02:35,755 fixing it would cost the company weeks of work. 39 00:02:36,855 --> 00:02:41,915 Typically low priority defects and others that simply can't be resolved quickly get 40 00:02:41,915 --> 00:02:48,050 pushed to what we call a backlog or more specifically, a defect backlog. 41 00:02:48,050 --> 00:02:52,480 This is a list of unresolved defects that you can keep track of. 42 00:02:52,480 --> 00:02:56,980 This can help your company prioritize what needs to be fixed in the next release 43 00:02:56,980 --> 00:03:02,430 by having a place that you can sort all of your defects by their age and severity. 44 00:03:02,430 --> 00:03:05,710 Having a list somewhere, like in the popular Jira application, 45 00:03:05,710 --> 00:03:10,680 is also a useful place to give developers a place to find easy things to work on 46 00:03:10,680 --> 00:03:12,550 if they are done with other work. 47 00:03:12,550 --> 00:03:16,900 But also remember that while some defects are either low severity or 48 00:03:16,900 --> 00:03:22,160 low priority, there is still a concept of death by 1,000 paper cuts. 49 00:03:22,160 --> 00:03:27,220 Where all those little low severity defects really add up. 50 00:03:27,220 --> 00:03:31,030 It's very easy to keep pushing low-priority defects out to future 51 00:03:31,030 --> 00:03:35,690 releases that never actually arrived and sooner or later your customers will 52 00:03:35,690 --> 00:03:40,870 notice that those glaring but otherwise benign defects are still hanging around. 53 00:03:42,120 --> 00:03:44,170 Push these to get fixed. 54 00:03:44,170 --> 00:03:47,690 One strategy I've seen in the past is to put many of these bugs 55 00:03:47,690 --> 00:03:49,820 into related bundles. 56 00:03:49,820 --> 00:03:52,760 So if there are five or six low priority defects for 57 00:03:52,760 --> 00:03:57,100 your header bar, bundle them all together to get them fixed at once. 58 00:03:57,100 --> 00:03:58,700 Your customers will definitely thank you. 59 00:04:00,840 --> 00:04:03,767 Before I leave you on this section about bugs, 60 00:04:03,767 --> 00:04:07,818 I wanna talk about one more distinction that often gets made when 61 00:04:07,818 --> 00:04:10,612 deciding what makes a bug and when to fix it. 62 00:04:10,612 --> 00:04:16,630 A lot of bugs that might be reported are actually feature requests and not bugs. 63 00:04:16,630 --> 00:04:21,260 Problems with the way the UI has been designed, or maybe the data has been laid 64 00:04:21,260 --> 00:04:26,010 out in the database, may be problems for the end user, but if they're otherwise 65 00:04:26,010 --> 00:04:30,050 working as they were designed, then they are not considered bugs. 66 00:04:31,100 --> 00:04:35,610 Bugs should be flaws in the way the software was intended to be used, 67 00:04:35,610 --> 00:04:38,850 not the way a user wants the software to be used. 68 00:04:39,990 --> 00:04:43,940 So with that, we usually like to make the distinction between feature requests and 69 00:04:43,940 --> 00:04:47,400 bugs as working as designed or not. 70 00:04:47,400 --> 00:04:51,930 This can be tough, though, because sometimes the design of the software 71 00:04:51,930 --> 00:04:55,140 is just objectively bad for the user. 72 00:04:55,140 --> 00:04:58,490 But it's important to triage those problems with everyone who should be 73 00:04:58,490 --> 00:05:01,380 involved in creating new features. 74 00:05:01,380 --> 00:05:06,860 Perhaps the design was intentional to make the users act in a very specific way, 75 00:05:06,860 --> 00:05:08,960 even if it's not working out. 76 00:05:08,960 --> 00:05:10,310 Let me give an example. 77 00:05:10,310 --> 00:05:13,597 In our RSVP app, it's possible to edit a person's card so 78 00:05:13,597 --> 00:05:15,688 that you can change the name around. 79 00:05:18,521 --> 00:05:22,756 But it's also possible to click the Confirmed checkbox while you 80 00:05:22,756 --> 00:05:24,520 are editing it. 81 00:05:24,520 --> 00:05:28,060 I think that's counterproductive, since we want the user to focus on 82 00:05:28,060 --> 00:05:32,800 editing the username and saving it before they can interact with the card. 83 00:05:32,800 --> 00:05:35,810 But this is how the application was actually designed, and 84 00:05:35,810 --> 00:05:40,610 was actually a choice made by our product manager, so we shouldn't file a defect. 85 00:05:40,610 --> 00:05:42,780 We should instead file a feature request. 86 00:05:44,020 --> 00:05:48,480 You might also remember an example I gave in our first video, where I argued that 87 00:05:48,480 --> 00:05:53,840 the styling of some boxes was inconsistent and therefore a defect. 88 00:05:53,840 --> 00:05:56,540 The style wasn't written down anywhere, though, and 89 00:05:56,540 --> 00:06:00,430 didn't match what I'd otherwise expect to see in the application. 90 00:06:00,430 --> 00:06:02,860 So there's a little bit of intuition happening there. 91 00:06:04,200 --> 00:06:08,400 But the other important point is that I approach the team about it to find out if 92 00:06:08,400 --> 00:06:10,800 it was by design or not. 93 00:06:10,800 --> 00:06:12,000 Turns out it wasn't and 94 00:06:12,000 --> 00:06:15,160 that the product manager agreed with me that it should be fixed. 95 00:06:16,480 --> 00:06:19,310 That concludes our section on bug reporting. 96 00:06:19,310 --> 00:06:24,750 I look forward to seeing you in our next and final section improving QA practices. 97 00:06:24,750 --> 00:06:25,250 See you there.