LOADING ...

Bug Reporting in Software Testing | bug report example | How to report bug in Bugzilla

118K+ views   |   747 likes   |   51 dislikes   |  
31:01   |   Nov 21, 2013

Thumbs

Bug Reporting in Software Testing | bug report example | How to report bug in Bugzilla
Bug Reporting in Software Testing | bug report example | How to report bug in Bugzilla thumb Bug Reporting in Software Testing | bug report example | How to report bug in Bugzilla thumb Bug Reporting in Software Testing | bug report example | How to report bug in Bugzilla thumb

Transcription

  • Hello, it is time for testing training.
  • 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.
  • Now, a
  • 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.
  • For instance,
  • 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.
  • So, a
  • bug is
  • the condition where the system is not satisfying your requirements, whether these are documented
  • requirements
  • (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
  • systems that
  • 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
  • with
  • 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
  • unique Id.
  • 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 summary
  • should capture
  • 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.
  • Depending on
  • 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.
  • Now,
  • 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
  • bypass
  • 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
  • security bug.
  • So,
  • 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.
  • Severity is
  • 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.
  • And
  • 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
  • cause any
  • major concern to anyone, but still it is a problem, and it should be fixed, so the severity can range from
  • Showstopper,
  • Major, Minor,
  • 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.
  • Now obviously,
  • 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
  • it's
  • overall
  • impact on the system,
  • Priority is another
  • data that you have to provide in the bug report. And priority indicates
  • how
  • Important it is to fix the bug
  • sooner rather than later. So this priority can also range from
  • Very High, High,
  • Medium,
  • Low. So, priority can have a number of values.
  • Now,
  • 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.
  • And
  • 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
  • simple problem.
  • It is not causing any data loss or anything or it is not impacting any functionality or causing any performance problems.
  • But
  • 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
  • with attachments.
  • 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
  • the
  • 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
  • automated
  • 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
  • bug tracking
  • system
  • 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
  • here,
  • this first comment is
  • basically...
  • this Description was left blank.
  • So
  • basically, they forgot to put the Description.
  • They did not put the Description, so they had to give the other details in the
  • comment.
  • 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.
  • So 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.
  • But
  • 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
  • really unnecessary,
  • 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.

Download subtitle

Description

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

Software Test Report : /watch?v=9GRtyvs5CTQ

Software Testing Tutorials : https://www.youtube.com/playlist?list=PLc3SzDYhhiGWuMK03uYO-UENAx0s2woWM

Selenium : https://www.youtube.com/playlist?list=PLc3SzDYhhiGUrFqriDJjdxTmND0D3pgYG

Automation Testing full course : https://www.youtube.com/playlist?list=PLc3SzDYhhiGXVcy8EcrTSfwsC-v8EUZvg

Website : http://inderpsingh.blogspot.com/
Twitter : https://twitter.com/inder_p_singh

Trending videos