Bugzilla is an extremely popular, browser based, full featured Bug Tracking and Testing tool. It is used in thousands of installations around the world - from small software shops to some of the world's largest and most popular software products including MOZILLA FIREFOX, Apache server, LINUX Kernel to just name a few.
Learn and Master Bugzilla to build a WORLD CLASS defect tracking system for your organization and team.
Bugzilla: The FREE Testing Tool used on the World's most used Software Products
Bugzilla is used by both Microsoft Tech based companies and Open Source companies alike - product companies or services or consulting firms - have benefited from the robust, scalable and no-frills Bugzilla.
Course Overview and Contents
Upon completing this course, you will be able to use Bugzilla as a powerful tool in quality assurance and project management for your organization. You will also be able to implement end-to-end defect tracking and management for your product or project alike.NOTE:
Welcome and congrats on your interest to learn Bugzilla.
I am Srikanth and have been managing software development for more than a decade. Bugzilla is one of the first things I get configured for my projects and I find it is an invaluable tool.
First of all, what is Bugzilla?
Bugzilla is a powerful and FREE Bug Tracking System. Bugs in a software project are also called by other names such as Issues, Defects, Errors - they all mostly mean the same. Bug Tracking Systems allow developers to keep track of outstanding bugs in their product very effectively. Most commercial defect-tracking software vendors charge enormous licensing fees. Even though Bugzilla is "free" it has many features its expensive competitors lack. Because of this, Bugzilla has quickly become a favorite of thousands of organizations across the globe. Bugzilla is
In this course you will learn how to employ Bugzilla completely for your software development team. You will first start by creating Bugzilla accounts for yourself and your team members. Then you will learn the components and lifecycle of a bug. That is, you will see how to create a perfect bug report and also you will understand the workflow of bugs in the system. You will also learn how to search, sort and manage from amongst hundreds and thousands of bug reports if required. There are some powerful features that Bugzilla provides.
Finally, you will see how to create fantastic reports to share with managers, with developers and other team members. And you will also see that you can customize every aspect of Bugzilla to suit your own organization, team and particular project.
This course is for any technology professional who wants to use a defect tracking system to - increase productivity, reduce downtime, raise customer satisfaction, and improve communications. Regardless of the size of your organization, Bugzilla can help you achieve these goals.
However, I do not teach software testing as a discipline in this course, though you will learn a lot of testing best practices.
In this lesson, we will start with the very basics and see how you can get an user account in your Bugzilla installation.
There are 3 different ways in which an user account can be created in Bugzilla.
The first method is the creation of the Administrator - also called as the "super user" - and this happens when you are installing Bugzilla. When you first run "checksetup. pl" after installing Bugzilla, it will prompt you for the administrative username (email address) and password for this "super user". Since this method is used during installation process, for this course we will assume this is already created for you and you have access to this super user or any other user with Admin privileges.
The second method is through user self registration. We will cover this self registration method in this lesson. There is a big button on the Bugzilla Main Page called as "Open a New Account" and this link will be used.
The third method is that an Admin user can create one or more user accounts from the Administration section of Bugzilla. We will look at this method in an upcoming lesson in this same section.
So, I will switch over to my Bugzilla installation.
Here on the main page, I have a big button which invites me with a message "Open a New Account".
I will click on the button - and in the following screen we can create a new account.
Now all that is needed to create a new account is - a valid and functional email address.
Without further ado, I enter an email address and click on the send button. When I do that, Bugzilla will send a verification email - and the mail has to be confirmed for an actual user account to be created.
This will take just a moment - waiting for the "mail sent message" - and there it is - a confirmation mail has been sent to my email address.
Now, let me switch over to my mail account and let us wait for the email.
There it is - and let us confirm by clicking on this link.
This takes me back to Bugzilla - where I have to enter my account details.
Real name - which is optional - I will give as "LearnGood Bugzilla". Then the password.
And when I click on "Create" button, my account is finally created.
So, in this lesson, we have seen the self registration technique of creating a new user account in Bugzilla. You can ask your team members to self register - and if you want to give your customers access to an external installation also you can use this method.
Once that you have a Bugzilla account for yourself and before you actually start recording bugs and issues - you must create a product on Bugzilla.
Let me log into my admin account and show you how the Product page looks. Once I am logged in, I will go into the Admin section by clciking on this link.
Now, here is the link called "Products" that will let me create, or edit all aspects of products. We are first taken to a listing page which will list all the existing products - and you can either select one to edit it - OR create a new one with this "Add" link.
Bugzilla creates a default product for you on installation called "TestProduct" - and you can just delete it if you like. I suggest you keep it there and play with it while you are still learning and getting familiar with Bugzilla.
I will click on the Add link - and we get to the new product creation page.
Before we create a product that we will use all through this course, let's take a moment to understand what a product really means here.
Products typically represent real-world shipping products. Products can be given Classifications. For example, if a company makes computer games, they could have a classification of "Games", and a separate product for each game.
While the terminology used in Bugzilla is "Product" - it can very well be used to represent a "project" if that is what is used in your situation.
Let us first add the Product name - and here I will give this as "LearnGood WebApp". This is the real world example that we will use through out this course.
"LearnGood. in" is a learning management web application - you can see on the screen. This webapp has several typical areas such as the registration section, course taking, course administration, discussion forum, assessment and gradebook areas - to name a few. These parts of the webapp are called as "Components" in Bugzilla.
Now returning back, I will add a mandatory description.
This checkbox determines if the product is active or not - that is whether new bugs can be entered or not. If you disable this checkbox, then new bug entries can not be made.
You can also specify a unique version number for the product - if multiple versions of the product will exist in the real world.
I will leave the other options as it is we will see some of them later in the course.
The final part is that a minimum of 1 component should be created with the product. I will enter that here as "UX" - which stands for the User Experience of the web application - that is all the look and feel aspects of the product.
A default assignee to the bug is also mandatory. The default assignee should be the primary person who fixes bugs in that component. In many cases you can also assign this to the Team Lead or the Project Manager here - and they can later re-assign the bug to an individual programmer.
Now, finally when we click on add, the product is finally created. We get a confirmation message "The product LearnGood WebApp has been created".
So, in conclusion, we have seen that Bugzilla needs you to first create a product and minimally one component so that you can then start reporting bugs against the product.
In this lesson we will see how you can create new Bugzilla accounts for your team members or perhaps for your customers. In a previous lesson, you have already seen how a new user can be created by self registration and in this lesson we will see how an Admin level user can create user accounts for others.
We will start from the From the Main Page, click on Administration
The administration page opens up. We are not going to look into this page in detail for this tutorial - but this is the central location from where you can administer every aspect of your installation.
For now, I will only want to look at the link here called "Users" - which will allow you to create new users as we want to do in this lesson. [crud possible]
Now, when I click on the "Users" link - it leads me to a page where I am presented with a search interface. This page actually, can be used not just to create new users, but also to edit existing users but we will not look at that now.
One convenient thing that you can do with this search feature is that you can search to see if the user already has an user account. This is quite possible if you work in a large organization and the user account is already created.
There is a link "add a new user" - and we need to click it.
This interface is real simple and let us create a new user real quickly now.
For the "Login name" - give the email address of the new user - I am going to paste it here. Then the optional real name.
You can disable issues related mails from going to this user if you turn on this checkbox labelled "Bugmail Disabled".
The next box is interesting. Suppose you were disabling an existing user from accessing Bugzilla - you can write a message in this box. And if you write ANYTHING in this box, even an empty space character, then that user will be disabled and this message will be displayed when the user tries to log in.
However for this lesson, we will ignore this box.
Now, all we have to do is click on the Add button and the new user will be created.
You can see a confirmation message in the next page that the user has been created.
Now, I want to quickly do a test that the user I have created will be able to login correctly. Since I am already logged in - I will have to logout and try to login with the new user id. One simple trick is to login with a different browser - since the cookie that Bugzilla stores to remember current login is only applicable to that particular browser. Since I am currently using Firefox, I will login through Internet Explorer.
I will open IE and login.OK that looks great and I have been able to login with the new user.
So, in this lesson, we have seen how to create new users on the system. You might want to do this for your own team members or the customers team members. Once you create the userids, you should of course give them the user names and passwords that you have set and have them change the password later if they want.
Let us dive right into Bugzilla and see the core page of Bugzilla which displays a particular bug. It's a good place to explain some important Bugzilla concepts and general best practices.
I am purposely not logged into Bugzilla currently. I will open an existing Bug from the database now and show you how it looks.
The labels for most fields are conveniently hyperlinks; clicking them will take you to context-sensitive help on that particular field.
Let us look at each of the fields one-by-one.
Summary: A one-sentence summary of the problem.
Status and Resolution field: These define exactly what state the bug is in - from not even being confirmed as a bug, through to being fixed and the fix confirmed by Quality Assurance.
We will see all the different possible values for Status and Resolution in a later lesson - which will teach about the lifecycle of a bug.
Product and Component: Bugs are divided up by Product and Component, with a Product having one or more Components in it. In this particular case, we created the product "LearnGood Webapp" in the previous lesson. And "Authentication" is a component.
Version: The "Version" field is usually used for versions of a product which have been released, and is set to indicate which versions of a Component have the particular problem the bug report is about.
This is also useful for situations where for example you want to report a bug in different environs - say dev, testing, staging or production.
Hardware and OS: These indicate the computing environment where the bug was found. For web applications typically you can ignore these.
Priority: The first word here signifies the "Priority". The bug assignee uses this field to prioritize his or her bugs. It's a good idea not to change this on other people's bugs.
Severity: The second word here signifies the "Severity". This indicates how severe the problem is - from blocker ("application unusable") to trivial ("minor cosmetic issue"). You can also use this field to indicate whether a bug is an enhancement request.
Importance: The importance of a bug is described as the combination of its Priority and Severity. This is just an easy way to quickly assess the importance of a bug.
Assigned To: The person responsible for fixing the bug.
URL: A URL associated with the bug, if any.
Dependencies: If this bug cannot be fixed unless other bugs are fixed (depends on), or this bug stops other bugs being fixed (blocks), their numbers are recorded here.
These two are pretty nifty tools for complicated projects - because you can automatically generate tree and graph views to analyse dependencies.
Reporter: This shows the person who filed the bug.
CC list: This is a list of people who get mailed when the bug changes.
Description field: This is the real meat of the bug. Here the person who raises the bug will describe the steps to reproduce the bugs.
In this well written example - you can see that there have been 3 separate tests done and steps provided on how to reproduce the bug. An "expected result" is also added showing what the deviation is - that resulted in this bug being raise.
Attachments: You can attach files (e.g. screenshots or testcases or patches) to bugs. If there are any attachments, they are listed in this section.
Additional Comments: Anybody can add their additional comments to the bug discussion here, if they have something to say.
In conclusion, you have seen the anatomy of a bug in this lesson - that is all the different items of information that will make up a well written bug in Bugzilla.
One more thing to note that this report is extensively customizable. You might disable or ignore some fields if you want - such as the platform and hardware fields.
Or else, there are many other ready-made fields that you can add to this report such as a time management column with estimated resolution times as set by both the manager and the developer - which are great if you are working on a time bound bug resolution mode.
As soon as a bug is entered into Bugzilla - it's lifecycle starts. In this lesson, you will get a solid understanding of the workflow provided by Bugzilla throughout the life of a bug. You will also get a clear idea of how different players like the Tester, Developer or the Manager can change the course of a Bug in Bugzilla.
This flowchart shows the default workflow of a bug lifecycle in Bugzilla. Even though it looks complicated - it is very easy to understand as you will see by the end of the lesson.
Every bug will exist in one of these 5 states shown in the flowchart - starting it's life as either an Unconfirmed or a Confirmed bug - it can then proceed to "In_Progress" or "Resolved" or "Verified".
State changes can be initiated by either a Quality Assurance personnel or a Developer. Sometimes, the Manager also might explicitly set the state of a bug - but that should mostly be to resolve some conflict of understanding.
To understand how this workflow works - let us first see the most simple and straight path for a bug in the next slide. Then we can look at other different paths which are rarer.
In this slide, let us see the most common path for the lifecycle of a bug.
The bug is first entered into the system by an authorised person - and starts its life as a CONFIRMED bug. A mail is sent to the developer assigned to the bug.
As soon as the developer starts work on resolving the bug, they change the state to "IN_PROGRESS" - this means that the bug is under the processing of being resolved. For example, the manager can search for bugs with status "In progress" - to know what all bugs are currently being worked upon and by whom.
After some time, when the developer has finished their work on the bug - will again change the bug status to "RESOLVED". What this means is that they have done their bit on the bug. A mail will go out to the tester that the bug has been resolved.
But, after the developer has marked a bug as resolved - it still needs to be retested by the tester. And they have to verify that the resolution provided by the developer is acceptable or not.
Assuming for this example that the bug has been resolved to the acceptance of the tester - the tester will then change the state of the bug as "RESOLVED". This is a final end state for the bug.
In this next slide, you will see some more possible use cases for the workflow paths.
Firstly what is the "UNCONFIRMED" status that a bug resides in? If a bug is created by a person who doesn't have sufficient permissions then the bug will be created in the "UNCONFIRMED" status. A very common example is when one developer raises a bug on another developer's module.
In that case, someone who knows the functionality of both modules should confirm that indeed the bug is real and valid - and this will put the bug into a "CONFIRMED" status.
Specifically a user with permission called "Can confirm a bug" - can put a bug in the "CONFIRMED" state.
Typically, very busy engineers will probably generally ignore UNCONFIRMED that have been assigned to them, until they have been confirmed in one way or another.
The use case we will see is: What happens when a tester is not satisfied with the resolution provided by the developer? In that situation, the developer has put the bug in a RESOLVED state - but now because the tester is not convinced that the problem is really resolved - they will put the bug back into a CONFIRMED state - ideally with a note explaining what is still wrong.
Sometimes, you will come across bugs that just can not be fixed, maybe because the bug itself is invalid or because of some technical or budgetary limitation. In that case the bug can change state directly from an CONFIRMED or UNCONFIRMED to RESOLVED.
Finally, we will see one more case when a VERIFIED bug is found to be wrongly tested or maybe the bug reappears due to a regression problem. In that case the bug can change state back to CONFIRMED.
These examples that we saw will cover almost all the real life situations you are likely to experience. However, beyond that, this workflow can further be customized to your own organizations requirement.
In the next slide, we will see the different resolutions that can be possible on a bug. When a developer changes the state of a bug from "IN_PROGRESS" to "RESOLVED" - they will have to give a resolution reason also - and there are 5 possible options for this.
The 5 possible resolutions are: Fixed - when the bug has been corrected in code (and this should be the most common type in your case). Next is duplicate - which means that there is another bug which is the same as this, probably reported by another tester. In this case, the developer is indicating that they are marking this bug as duplicate and the OTHER bug will be marked as fixed. You will have to be careful that both bugs are not just resolved as duplicate.
The most common example of when to use WONTFIX is when it is too expensive, in time and effort to fix some trivial bug.
Sometimes, fixing one bug by one developer can automatically resolve several other bugs for other developers. In this case, when the developer gets around to fixing a bug, they will find none - and in such cases they can mark a bug as "WORKSFORME". It basically says the bug report is itself incorrect.
Finally, a bug can be resolved as INVALID if the issue described in the bug is not a bug generated from the application (and from maybe somewhere else on the platform) or if the issue is intended behavior.
So these are the 5 types of resolutions that can be used by developers appropriately. Let us also note that whatever the resolution provided by the developer - the bug will still have to be retested by the Quality Assurance before finally being laid to rest in the VERIFIED state.
So, in conclusion, we have seen the complete lifecycle of a bug in Bugzilla and how a bug will change states depending on the actions of the testers and developers on the system. We all saw the different types of resolutions that can be done on a bug from the developers perspective.
In this lesson, we will see how to report a new bug.
Step 1: Click the “New” link available in the footer of pages, or the “Enter a new bug report” link displayed on the home page of the Bugzilla installation.
Step 2: This leads you to the Product Selection Page. You first have to select the product in which you found a bug.
Now this is the bug reporting page.
First specify the component (that is, the part of the product which is affected by the bug you discovered; if you have no idea, just select “General” if such a component exists). I will select the "Course" component.
The version of the program you were using, the Operating System and platform and the severity of the bug (if the bug you found crashes the program, it's probably a major or a critical bug; if it's a typo somewhere, that's something pretty minor; if it's something you would like to see implemented, then that's an enhancement).
I am going to ignore the OS and platform - since this is a web application. The severity I will mark as Normal. You can see there are 7 options in all. 6 of them are actually levels of severity - going from "Blocker" which is the most severe to "Trivial" which is the least severe. You and you team should be consistent in your evaluation of the severity of bugs.
The 7th option is "enhancement". This is a very smart choice. Very often, when your customers are evaluating your application - enhancement requests will start to appear as bugs! So having this here is a great option and you should use this wisely.
You now have to give a short but descriptive summary of the bug you found. Do not give something like “App is crashing all the time” - it is a very poor summary and doesn't help developers at all. Try something more meaningful or the developers will soon be complaining. I will paste in a summary that I have kept ready.
As I type in the summary, Bugzilla will very smartly search automatically to see if there are any duplicate bugs with a similar summary. If it finds anything, it will list here - and you can recheck the existing bug.
The next step is to give a very detailed list of steps to reproduce the problem you encountered. Let me paste in the description that I have kept ready and you can see it.
Try to limit these steps to a minimum set required to reproduce the problem. This will make the life of developers easier. If there are more than one ways to reproduce the same bug - then definitely write them down also.
Here again, I will paste in a description that I have kept ready for this lesson.
As you file the bug, you can also attach a document (testcase, patch, or screenshot of the problem).
Now is a good time to read your bug report again. Remove all misspellings, otherwise your bug may not be found by developers running queries for some specific words, and so your bug would not get any attention. Also make sure you didn't forget any important information developers should know in order to reproduce the problem, and make sure your description of the problem is explicit and clear enough. When you think your bug report is ready to go, the last step is to click the “Commit” button to add your report into the database.
You will get a confirmation message that the bug has been filed successfully in the database. Emails will be automatically sent to the developers who are assigned by default to the Component. And they can either attend it themselves or re-assign it to others.
So, we have successfully reported a bug and seen the simplicity that Bugzilla brings in its design. You can turn on other fields such as "URL" if it useful to you by visiting the Administration section.
Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.Principles
In a previous lesson, we saw from a tester's perspective on how to raise a new bug. And when a new bug is raised, we will also have to specify a product, and a component that the bug belongs. Every component will have a default bug assignee.
What this all means is that - every time you raise a new bug, the bug will be automatically assigned to someone or the other - who is responsible to keep that component bug free.
The default behaviour also is that a mail notification goes to the assignee of the bug that a new bug has been filed in their component.
In this short lesson, let us see from a developer's perspective how the Bugzilla bug email notification looks.
I will now switch over to my outlook which is configured to catch all my Bugzilla mails - and I see that a new bug mail notification has arrived.
The mail is very simple keeping with Bugzilla design. All the relevant information that was captured while creating the bug is sent across to the developer.
The Bug ID is a direct link - which I can click to see the report inside Bugzilla - useful when there is an attachment, for example.
Everything else is straightforward. You will see at the bottom here of the mail - why it is so important to write steps to reproduce the bug in a report. It can help in preserving the developer's sanity.
One last item to notice - Bugzilla explains why I recieved this specific mail - "You are the assignee for the bug".
Mails can go out not only to the assignee - but to others also as configured in the system, for example, the Project Manager might be on a default CC list - and will see this same mail also - except that this message will be different for them.
So, in conclusion, in this lesson, we saw how Bugzilla's notification emails look like.
This section distills some Bugzilla tips and best practices that have been developed.
While Bugzilla installation is not covered in this course - this simple lesson must help you understand the sequence in which Bugzilla should be installed on a Windows machine.
PLEASE NOTE: A fully featured Bugzilla installation test server is available for your FREE access online, hosted by the Mozilla Corporation. Please search for "Landfill: The Bugzilla Test Server".
Srikanth's recent leadership role as Senior Software Delivery Manager for one of the World's Largest Learning Management System implementation for online structured higher education - with more than 400,000 students pursuing online Masters/Bachelors and Certificate for one of India's largest and most diversified Education Providers with a global footprint in countries including the US, Singapore, UAE-Dubai, Malaysia etc.
Srikanth has directly managed clients including Telegraph Media Group UK, Microsoft, Yahoo, Marriott, Expedia, British Airways, Precise Media Group UK, Sequoia Media Group US, Tesco, and Hooper Holmes Inc. Managed teams sized in excess of 50, cross functional and projects/products in excess of 15 million USD.
Srikanth has over 18 years of experience in Software Delivery Management, Project Management, design and architecture, development of software solutions, spanning high-transaction enterprise level applications to standalone product development. He has extensive exposure to successful Program/Project management techniques such as PMP and Prince2; Experience in various software development methodologies like ISV Product Lifecycle, traditional Waterfall, Agile (Scrum and DSDM).Extensive experience in Proposal Engineering – effort, schedule and pricing estimations using WBS, COCOMO, pre-sales and customer relations – specially in Off shoring model. Specialties: Proposal Engineering, Product Development, Client relationships, high complexity and visibility software delivery management, architecture and design.