Bugzilla

AGENDA
Whats Bugzilla? Why we need Bugzilla? History of Bugzilla and release information Various other tools that can be used Defect and Defect Life Cycle. Installing Bugzilla Administration of Bugzilla Create a Project using administration part of Bugzilla Diff between severity and Prioirty Practice Log a defect.
Reporting system in Bugzilla - Various reports

What is Bugzilla?
Bugzilla is a Web-based general-purpose bug tracker and testing tool Originally developed by Mozilla as an in-house project for tracking defects in the Netscape Communicator Suite Released in 2001 as open source software.

WHY WE NEED BUGZILLA

Defect Tracking System that allows individuals or groups of developers to keep track of outstanding bugs in their product effectively. Scheduled Reports (Daily, Weekly, Hourly, etc) by Email Reports and Charts. Private Attachments and Comments. "Watch" Other Users, delegates. Move Bugs Between Installs . Save and Share Searches. Advanced Search Capabilities
Email Notifications
- New users can use a simple Google-like search for bugs while more advanced users can filter searched for very specific queries. - Users can choose to be notified by email about any changes made to any bugs in bugzilla. - Users can send Bugzilla an email that will create a new bug, or will modify an existing bug. - Users can display the time they think they will need to fix a bug, time spent on a bug, and deadline to fix the bug.

File/Modify Bugs By Email

Time Tracking

HISTORY OF BUGZILLA
When Mozilla first came online in 1998, one of the first

products that was released was Bugzilla, an open source bug system implemented using freely available open source tools. Bugzilla was originally for use at Mozilla to replace the inhouse system then in use at Netscape. Before Mozilla released it as open source, they decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. Bugzilla 2.0 was the result of that port to Perl, and the first version released to the public via anonymous CVS. Since then a large number of projects, both commercial and free have adapted it as their primary method of tracking software defects. Release information:

Various Other tools that can be used

Administering Bugzilla
Bugzilla Configuration User Administration Classification Products Components Version Milestone Flags Keywords Custom Fields Bug status workflow

Using Bugzilla
Introduction Create a Bugzilla Account Anatomy of a Bug Life Cycle of a Bug Searching for Bugs Filling Bugs Reports and Chats

Defect and defect Life cycle

While testing when a tester executes the test cases he might observe that the actual test results do not match from the expected results. The variation in the expected and actual results is known as defects. Different organizations have different names to describe this variation, commonly defects are also known as bug, problem, incidents or issues. Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirement gaps, e.g., unrecognized requirements, that result in errors of omission by the program designer. A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security. Software faults occur through the following processes. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. Not all defects will necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new computer hardware platform, alterations in source data or interacting with different software. A single defect may result in a wide range of failure symptoms.

Defect Life Cycle

Defect Life Cycle, Continues..

Log a Defect ::Can we practice?

Priority
It describes the importance and order in which a bug should be fixed. How fast the bug is to be fixed..there are different levels High, Medium, Low This field is utilized by the programmers/engineers to prioritize their work to be done. The available priorities range from: P1 (most important) to P5 (least important.)

Severity
Severity is seriousness of defect wrt functionality. What is the impact or effect of the bug over the business of customer is called severoity.. Blocker/sev1: Blocks development and/or testing work Critical: crashes, loss of data, severe memory leak Major: major loss of function Normal: functionality is not working correctly. Minor: minor loss of function, or other problem where easy workaround is present Trivial: cosmetic problem like misspelled words or misaligned text Enhancement: Request for enhancement

Demo - Search
2 types basic & advanced Basic Search Keyword search Advanced Search - Parameters include Status (New, Unconfirmed, Assigned, Resolved, Verified, Close, etc.) Resolution (Fixed, Invalid, Wont fix, Duplicate, etc.) Severity (Minor, normal, critical) Priority

Reports
You can run either an HTML-table-based report, or a graphical line/pie/bar-chart-based one. The two have different pages to define them, but are close cousins - once youve defined and viewed a report, you can switch between any of the different views of the data at will. Both report types are based on the idea of defining a set of bugs using the standard search interface, and then choosing some aspect of that set to plot on the horizontal and/or vertical axes. You can also get a form of 3-dimensional report by choosing to have multiple images or tables. So, for example, you could use the search form to choose "all bugs in the WorldControl product", and then plot their severity against their component to see which component had had the largest number of bad bugs reported against it. Once youve defined your parameters and hit "Generate Report", you can switch between HTML, CSV, Bar, Line and Pie.

Chats
A chart is a view of the state of the bug database over time. Bugzilla currently has two charting systems - Old Charts and New Charts. Old Charts have been part of Bugzilla for a long time; they chart each status and resolution for each product, and thats all. They are deprecated, and going away soon - we wont say any more about them. New Charts are the future - they allow you to chart anything you can define as a search. Note: Both charting forms require the administrator to set up the data-gathering script. If you cant see any charts, ask them whether they have done so. An individual line on a chart is called a data set. All data sets are organized into categories and subcategories. The data sets that Bugzilla defines automatically use the Product name as a Category and Component names as Subcategories, but there is no need for you to follow that naming scheme with your own charts if you dont want to. Data sets may be public or private. Everyone sees public data sets in the list, but only their creator sees private data sets. Only administrators can make data sets public. No two data sets, even two private ones, can have the same set of category, subcategory and name. So if you are creating private data sets, one idea is to have the Category be your username.

Questions

References
Bugzilla official site : http://www.bugzilla.org/ Mozilla's Bugzilla : https://bugzilla.mozilla.org/

Bugzilla Wiki: http://wiki.mozilla.org/Bugzilla

Documentation: http://www.bugzilla.org/docs/

Thank You