And this is Inder P Singh on today's class, which is How to report bugs effectively?
Now, there are many situations in which
we need to report bugs. Whether you are working as a tester or you're working
even as a product owner or a developer or
you are the customer or the
user of a product or service and you need to report a problem,
you need to have the skill to be able to report bugs effectively (to write bug reports effectively).
So, let us dive in to this class.
First of all, we have to understand, what is a bug?
Well, put simply a bug is a
condition where the system does not satisfy a particular requirement.
So, let us say that the system
was supposed to
show the user details when the user is logged in. But it is not showing the user details. Instead of showing the user details,
it just shows a blank page with the user name.
So, that is an example of a bug in the system.
bug can also be
the condition when
what you observe in the system is unexpected
or not according to your expectations.
So maybe, there are
two areas of the system, which you expected to behave similarly. But they are not behaving similarly.
on every page of the website,
you expect the same logo size to be there. But the logo size is different on one page of the website.
the condition where the system is not satisfying your requirements, whether these are documented
(or stated requirements) or some implicit requirements (which the system should have satisfied) or there are discrepancies.
Or the system does not conform to certain standards or certain regulations or
does not conform to
even competing products and the standards established in the market.
So, in other words a bug is a problem
with the system.
Now, the second question is why do we have to report bugs?
Well, most systems are complex. So they are not
everybody knows everything about at all times.
So since most systems are complex,
it is not sufficient to tell the developer that "Look, I found a bug in the system."
The developer would like to know more details because if the developer
had the knowledge of the bug, then they would have fixed that particular bug.
So, a lot of information is required to objectively
state different facts about the bug so that the developer can
first of all, try to understand what the bug is all about. Then try to reproduce it
themselves within the system so that they can see the problem for themselves.
And then come up with a solution to fix that bug.
So, this kind of a report, which contains
factual objective data about the bug is called the bug report.
So, when you report bugs, you report bugs in the form of a bug report.
So every bug is reported by a separate bug report.
So if you are a tester, you have to write bug reports (one bug report for every bug that you find).
Even if you are a user of a product or service and you have to
inform the developers, still you have to write a bug report. And even if you're the customer of the product or service,
then in order to
explain the problem, you have to file the bug report.
Now, let us see
what the bug report is.
Since the bug is a problem with the system (something that is unexpected
within the system any unexpected behavior
or any unexpected errors
or unexpected state, any kind of problem within the system), that has to be documented
within a bug report.
Now you don't have to write everything yourself in the bug report.
Many projects use bug tracking systems. These are called bug trackers,
like Bugzilla. And there are many more bug tracking systems. There can be a
public bug tracking systems that may be used in your team in your organization, or there may be
in-house developed bug tracking systems that may be in use. So whatever is the case,
usually if you have a bug tracking system, the bug tracking system provides you
places where you can you can create a new bug report and you can enter all the required data.
Now, let us see what are the different data that you have to write in the bug report.
Well, the first one is the Id.
Now, Id is an important part of the bug report because it
uniquely identifies that particular bug.
Now, what is the advantage of assigning an ID? Why do we need to identify a particular bug uniquely?
Well, the same problem should not be reported again and again
because that would lead to
more developer analysis. They would have to look up all the duplicate reports and
realize that they are all talking about the same problem. They are all talking about the same bug.
So, every bug is assigned a
Now, the next data that you have to give in the bug report is the Summary.
Summary is, you can say the most important or the second-most important data that you have to write in the bug report.
So, write it very very carefully.
the essence or it should capture
the overall bug or the overall problem in a compact form (in few words).
So, that is what the summary is about.
And summary should just state
what is the problem in simple words, in a small number of words so that anyone who is looking at the summary is
immediately able to understand what this bug is about.
how the defect tracking of the bug tracking system is set up, there may be other data that you need to provide.
Some of the other important data is the Project where you found the bug.
So, you may have to type the name of the project
or more commonly, you may have to select the project value from a drop-down.
Then within the project, there can be multiple Components or multiple Modules.
So if the bug is specific to a particular component or module, then you have to specify that.
The purpose of all these fields is
to provide as much specific data to the developer as possible, so that they can narrow down the problem.
They can reproduce the problem.
And they can come up with a fix or a
solution to the problem that takes care of all the things mentioned in the bug report.
You also have to provide the build. In which build of
the product or service did you observe the bug?
So, whether it was a recent build or you were testing an older build of the product or service,
the build number has to be specified over there. Some people call it the build number. Some people call it the version number.
So depending on whatever is your
naming scheme, you can use the corresponding build number.
Another data that you should provide is the Type of the bug.
some bugs are related to functionality.
So you give some input, you expect certain operations to happen, but those operations are not happening.
So, that is an example of a functional bug.
There can be
non-functional bugs also.
There can be bugs related to the performance of the system, so that is a performance bug.
If you are loading the application page, and it takes a lot of time or times out or
performs operations very slowly, so those can be performance bugs.
Another example of a non-functional bug is security bug. So maybe, you were able to
the security mechanism in the system
and able to see data, which you should not have seen
or able to run functionality which you should have not ran,
depending on your privileges.
So that is an example of a
you can specify the type of the bug also, whether it is a functional bug or a performance bug or a security bug or a
usability bug or
an accessibility bug. That will give additional information to the developers concerned to fix
the bug by thinking of a suitable solution.
An important field of the bug report is a Severity.
the scope of the problem or the size of the problem. So severity can range from
Showstopper to Minor.
So, a showstopper kind of a bug could be that
you are not even able to log into the system.
therefore unable to do any work at all.
So the entire system is out of reach for you. That is a kind of a showstopper severity bug.
A minor severity bug can be that, okay,
the help file contains some type of graphical errors.
So that is something that will not
major concern to anyone, but still it is a problem, and it should be fixed, so the severity can range from
then Cosmetic. So these can be the different severity values depending on how severe the problem is?
How much It affects
the overall system?
So, you can assign the severity value based on your judgement of the severity of the problem.
the more severe the problem is, the more rapidly the developers will try to look into it, to find out
what is the problem. So if it is a high severity problem, like you try to save data
but some of your data was saved and some of it was not saved (it was lost).
So that is a high severity problem and
that high severity bug report would be looked at
more urgently than a bug report with the severity of Minor or a severity of Cosmetic.
Just as severity indicates
how severe the bug is, in terms of
impact on the system,
Priority is another
data that you have to provide in the bug report. And priority indicates
Important it is to fix the bug
sooner rather than later. So this priority can also range from
Very High, High,
Low. So, priority can have a number of values.
a High priority bug can be for instance, the same example that we discussed that the users are not
able to log into the system and
therefore they cannot do, nobody can do any work.
So obviously, the priority of that bug is going to be urgent, because it is
a problem (a bug) that requires
an urgent solution (an urgent fix).
But it is also possible that sometimes the severity is High and the Priority is Low.
How that is possible? Let us say, it is a severe bug
but it impacts only a less used area of the system (the area used by very few users).
So, even though it is a severe bug in that particular area,
the priority can be Low, so developers can look at it later.
even if the severity is Low,
the priority can be High. An example of Low severity and High priority can be on the home page,
the logo of your
organization is incorrect. Now, that is a very
It is not causing any data loss or anything or it is not impacting any functionality or causing any performance problems.
it has a High priority because it gives the incorrect message
because the logo is wrong. So such a bug where the logo is incorrect on the home page will have
Cosmetic severity, but it can have Urgent priority, even though it is a
very less severe problem. It is a very mild problem. Still it has to be fixed urgently, because the priority is Urgent.
Now, we come to the most important part of the bug report and this is the Description.
Now, we already saw that out of the previous data that you have to give in the bug report, Summary was important .summary is
Basically, a concise
short form of
the bug report, describing the bug report in few words in a compact manner.
Description is where you give the
entire data (whatever data the developer is going to require).
The bulk of that data is given in the Description.
So, in Description, you can describe what is the problem? So how you do that is you can give the Steps
you ran until you faced a problem. So you can give each of the steps. You can also specify
what data you used when you ran each of those steps. So, if you logged into the system
what was the username you used? What was the password you used?
Then you clicked on which link? Then you clicked on which button?
Then you entered what data?
Until you can give all the steps with the data that you use (which is called the test data),
you can give all the steps and the test data until
you came across the problem (until you came across the bug). And then you can describe what is the bug.
If required, you can specify what requirement the bug violates.
Which requirement is not being satisfied due to the presence of this bug?
And also, you can give additional information. This additional information can be
Now, several attachments are possible. Maybe you want to attach
your test case along with the bug report, so that the developer has a better idea how to
run the steps leading to the bug. Or you can even automate
bug reproduction by
using a tool. If it is a web application, you can probably
automate the test case steps using Selenium Ide and attach that or
you can have any additional files like server logs
or screenshots, which show what was the problem.
And you can highlight the problem area within the screenshot using any drawing software.
So, the Description contains the bulk of the data and this is
the data that the developer is going to be looking at
most closely, when they look at your bug report.
And also, when you are filing the bug report, you can mention your name.
So, these are the different fields of the bug report. Just be very very careful with writing the Summary
and the Description. You have to be careful with the Summary because Summary is what is
the face of your bug report. So anyone who wants to look at the different bugs and
decide which bug they should look at first,
is going to first look at the summary.
Also managers do not look at the bug reports in detail.
They look at the Summary first and
if they want, then they will look at the entire bug report. So Summary is an important field and you should
design it carefully, so that it correctly
shows the problem.
And Description is where you should accurately record what steps you took, what test data you used to execute those steps,
what was the problem, what was your expectation,
any requirement that was violated by this bug. And you can give additional information
in the form of logs, in form of screenshots, in form of
test case scripts. You can give all this information
but at least, the Description should contain
the steps and the data to reproduce the problem, the problem itself and what you
expected instead of the problem.
Now, let us look at a sample bug report and
after this, we will do a summary.
Now this is the public bug database from the Apache Software Foundation and here, I just have opened a
bug report to show you the different fields.
So, this is an already existing bug report so once it is created, this is how it looks like.
So here, you can see that it says Bug 54058.
So, 54058 is the Bug Id, so this Id is unique
across the entire
And then it has a line.
This is the Summary. So, the Summary says in HTTP Requests Defaults
something is not saved if something is not checked.
So, this basically captures the core of the problem. The core of the bug is captured in the Summary.
Then there are some fields. Some of these fields have been filled up, but some have been left blank.
So, the important ones have been filled. So, it says the Status.
The Status is what state the bug report is in. So if it is a brand new bug, the status is going to be New.
If it is allotted to a particular developer, the Status is going to be Assigned.
If the developer has found the solution and applied it in the product or service, then the Status will be Fixed.
So, here the Status is Resolved and Fixed. So that means the problem was noted by the developer.
The developer found out a solution to the problem and they applied the
solution to the product. So, the new build of the product does not contain this particular problem.
Then it says a product is JMeter and
JMeter has many components. There are different areas of JMeter, so it specifies that
this problem exists in the HTTP component of JMeter.
Then there is a Version.
So here, the tester or the bug reporter has not specified. So that is why it says please specify the date and
then here, instead of Severity and Priority, it is showing the Importance field because
depending on your organization or your team, you can call the fields differently.
So here it P2.
P2 means Priority 2 and
Normal Severity and
it is already assigned to something and there are some dates over here.
So, this is the Reported date and it also
talks about Reported by the username.
So, this particular user has reported and it was last modified on this particular date.
Now, this is the overall
bug report and
there are no attachments over here. Otherwise, we would have seen attachments.
And down below, we can see the different comments.
So when the bug is first reported, it does not have any comments. When the developer is assigned and the developer
analyzes the bug, they can give their own analysis and that is present as a comment.
So here there is a comment by the bug reporter only and it provides additional information.
Now this if you notice
this first comment is
this Description was left blank.
basically, they forgot to put the Description.
They did not put the Description, so they had to give the other details in the
So in the comment, they have given the URL and
they have described the problem in HTTP Request Defaults, the value of field embedded urls is not saved if the checkbox is not checked.
And the same
Id also given over here, 54058 is also given over here.
And they have given
what file they modified, so what was the solution to fix this particular problem?
So perhaps the bug reporter and the developer was the same person. That is also a possibility.
Some time developers when they do their own testing (whether they do unit testing or integration testing),
they can find bugs and they can
report those bugs.
And then if it is the same developer who has to fix it, the same developer can fix it. It just creates
documentation for that particular bug, so if later on,
if users come to know about this problem,
the fix would already be available.
So these are all the possibilities over here. So let us go back and do a recap of
what we learned today.
we have seen how to report bugs effectively. So, we saw what is a bug?
A bug is a condition where your expectation and
what the system is doing or
the system is behaving, do not match. So basically, a bug is a problem with the system.
Why report bugs? Well, most systems are complex, and you have to give a number of information
to the developer in order for them to understand what exactly is a problem.
And so that they they are able to replicate the problem and
able to understand the problem and come up with a solution and apply that solution on the system.
So, you have to report bugs if you are a tester, if you are a product owner,
even if you are a developer or if you are just a user of the system, or you are a customer,
you should know how to report the bugs.
Now, how you report the bugs is in the form of a bug report? So, you should not be
reporting bugs in
emails, you know, because then you tend to
lose some of the information. So there will be back and forth and
then again somebody will have to go to the bug tracking system and
report the bug on your behalf. So, it is always good that you go directly to the bug tracking system and their file the correct
required bug report. Now there are many fields in the bug report that you have to specify.
the important ones are the Summary. Summary is a short description of
the problem and the summary is useful because
managers and developers, when they look at all the bugs together in a list, they see only the summaries.
So, your summary should correctly explain
what is the problem, so that quick action can be taken on it. If the summary is not in line with
the actual bug, then it is possible that
action will be delayed on your reported bug.
So, have a correct short Summary.
The most important field of the bug report is the Description. Description is where you provide the detailed steps of
your test case or whatever test you ran,
along with the test data (the inputs that you gave) and what is the problem that you observed. And instead of the problem,
what was your expectation? And you can provide additional files like screenshots, server logs, or
automated test cases to help
replicate the problem. So these are the important fields.
Then we saw sample bug report. In short, when you have to report bugs effectively,
you'll be able to do so if
you spend some time thinking about exactly what you want to write.
Because keep in mind that bug reports are shared between different people. So when you submit a bug report,
it tends to be a permanently recorded bug report for time to come
and it is also read by various people. It can be read by the developers,
it can be read by the business people, it can be read by managers, it can be read by the customer, so just be
very factual and compact.
Don't use any unnecessary words. Don't give any unnecessary Description.
Just whatever is required. Everything that is required in the bug report, you should write in the bug report.
Everything that is
you should avoid any unnecessary data in the bug report. So make sure it is as compact as possible and also factual.
Factual in the sense that it should just state the facts i.e. what you did,
what data you used, what was the problem, what you were expecting. You should not give your feelings that
"this is not at all what I was expecting" or anything like that. Just state the facts in a
very clear objective manner and
in order to be effective, your bug report has to be complete in all respects.
If there is any missing data, then the assigned developer will come back to you asking for that data.
So you will have to again think about the problem and
get that data and send the bug report back to the developer. So that all it takes time.
It's a sheer waste of time. So, when you are creating the bug report, at the first time,
make sure it is compact. It contains facts only,
no feelings or emotions anything like that. And the data is complete in all respects so the developers
get the full information, and they are able to understand the problem and come up with a solution.
So, that is how to
report bugs effectively.
I hope you liked this class. If you liked this class, then please do a like, share
or subscribe to the Software and Testing training channel. Thank you very much.
With this software testing training, learn what are bugs in software testing , different types of bugs in software testing that is classification of bugs in software testing , bug report meaning , what are the fields in a bug report like severity and priority in software testing using a bug report sample and how to report defects. This QA training is useful for software tester to know how to write bug report in manual testing . The quality assurance training includes how to write a good bug report tips and tricks. In some organizations, a bug report is also called defect report or incident report in software testing