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.