"Java Data Structures - Retired" was retired on May 31, 2019. You are now viewing the recommended replacement.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Introduction to QA Engineering!
You have completed Introduction to QA Engineering!
Preview
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.
Definitions
- 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.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
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 upYou need to sign up for Treehouse in order to set up Workspace
Sign up