Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
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.
Definitions
- 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
Name/Description:
Location:
Screenshots/Videos:
Steps to Reproduce:
Expected Result:
Actual Result:
Data Set:
User:
Workaround:
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
User: N/A
Workaround: Edit the card and include name.
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
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 upYou need to sign up for Treehouse in order to set up Workspace
Sign up