Build Your Bugzilla System to Track Project Activities
Center for Systems and Software Engineering
University of Southern California
September 2013
Content
Build Your Bugzilla System to Track Project Activities 1
Introduction 3
1.1. What is Bugzilla? 3
1.2. What Does Bugzilla Do? 3
2. General workflow description 3
2.1. “Team meetings” 3
2.1.1. Win condition negotiation (example) 5
2.1.2. ARB meetings (example) 6
2.1.3. Weekly meetings (example) 6
2.1.4. Developer raises an important issue to discuss with the team (example) 6
2.2. Ticket life cycle 7
3. General guidelines 7
4. Main functions used in CS 577 8
4.1. Login 8
4.2. [All roles] Create a new ticket 9
4.3. [IV&Ver] Set up “Components” 11
4.4. [IV&Ver] Report an Artifact defect 15
4.5. [IV&Ver] Generate Report 17
4.6. [Project manager] Report a team meeting 19
4.7. [All roles] Report progress on ticket 19
5. Criteria for grading 21
6. Appendix: life cycle of a defect 23
7. Reference 23
Introduction
1.1. What is Bugzilla?
Bugzilla is a "Defect Tracking System" or "Issue-Tracking System". Issue Tracking Systems allow individual or groups of developers to keep track of project activities such as outstanding bugs and development tasks in their product effectively [1].
1.2. What Does Bugzilla Do?
· Track code and bugs changes
· In CS577 class it records all efforts spent on the class projects.
· Communicate with teammates
· Submit and review patches
· Manage quality assurance (QA)
Bugzilla can help you get a handle on the software development process. Successful projects often are the result of successful organization and communication. Bugzilla is a powerful tool that will help your team get organized and communicate effectively.
2. General workflow description
This section describes general Bugzilla workflow used in CS577 class. We used Event-driven process chain diagrams (notation description: http://en.wikipedia.org/wiki/Event-driven_process_chain ) to describe various workflow aspects.
2.1. “Team meetings”
During the course of any IT project team collaboration may consume a lot of effort; therefore, in CS577 class we require to report this effort in Bugzilla. Any interaction between team members, client and other stakeholders which involves two or more people and requires more than 30 minutes of your time can be considered as “team meeting” or “team discussion”. Events of this kind should be reported in Bugzilla. Project manager is responsible for reporting these activities, and everybody in the team is responsible to notify Project manager about these events if Project manager is not involved.
To report “team meeting” in Bugzilla Project manager has to create a Bugzilla ticket with the following credentials:
· Component: “Non-component activity”
· Importance: Normal Queue.
· Status: “In progress” if meeting was planned but not conducted; “Resolved” if it was already conducted.
· Assign to: Project manager
· Ticket type: Team activity.
· Description: add meeting agenda here.
The rest of the fields should be entered according to general instructions in section:
[All roles] Create a new ticket.
Figure 1 Event-driven process chain diagrams notation.
The following diagram shows the workflow:
Figure 2 “Team meeting” workflow in Bugzilla
2.1.1. Win condition negotiation (example)
Description of the case. In the very beginning of the 577 class team meets the client and discusses the project’s goals and arranges next meeting for win-win negotiation. Then the team conducts win condition negotiation and comes up with the initial set of the win conditions.
Workflow in Bugzilla. Project manager creates two tickets for each meeting (first meeting and win condition negotiation meeting). After the win condition negotiation IV&V team member should use win-win conditions (win-condition ids from winbook) in Bugzilla tickets.
2.1.2. ARB meetings (example)
Description of the case. Once team passes ARB session, all the identified defects in artifacts must be reported as Bugzilla tickets. All software defects such as bugs must also be reported by IV&V person.
Workflow in Bugzilla. Project manager creates a new Bugzilla ticket (ex. “DCP ARB meeting”) and reports effort spent (approximately 1 day). IV&Ver creates tickets for all software and artifact defects. All these tickets should refer to ARB meeting ticked (Triggering ticket: “DCP ARB meeting”).
2.1.3. Weekly meetings (example)
Description of the case. During the weekly team meeting a new work assignment was identified and assigned to a responsible person. For example, architect finished initial design of a new module and during the meeting distributed implementation assignments to other team members.
Workflow in Bugzilla. Project manager creates a ticket for the weekly meeting. Project manager also has to create tickets for each work assignment that architect suggested. All these tickets should refer to the task that architect had been working on (Triggering ticket: “Create initial design of the module B”).
2.1.4. Developer raises an important issue to discuss with the team (example)
Description of the case. During the implementation one of the team members realizes that the important change has to be done first before his task can be accomplished. This developer calls for meeting where he discusses identified issues with the team. Team decides on the change. If proposed change was accepted, proper work assignments are distributed among the team.
Workflow in Bugzilla. Project manager creates a ticket for the meeting (ticket type – team activity, triggering ticket – the task that developer has been working on), then Project manager creates all the tasks that implement this change (triggering ticket – meeting).
2.2. Ticket life cycle
Figure 3 Ticket life cycle
*Task is closed when its status is “Verified”.
3. General guidelines
· Project manager is the responsible person for creating tickets in Bugzilla. IV&V person is responsible for reporting defects in Bugzilla.
· All tasks must have estimated effort.
· Every week team has to update effort spend on all the tasks.
· Typical length of the activities that should be reported in Bugzilla is 2 hours-2 days. Do not create tickets for every small task, but group them in activates which require at least 2-4 person-hours effort. 1 person-day = 8 person-hours.
· List of roles can also be extended by IV&V person.
· In case of defects identified during the ARB, the summary of the report must begin with “From ** ARB” (otherwise, we couldn’t know you have done this )
· If your team members peer review each other’s artifact, you also should input defects into Bugzilla system.
· To close your ticket you have to change status from “Resolved” to “Verified” and set the proper resolution status (“Fixed”, “Won’t be fixed”, “Invalid”).
· If you accidentally created a Bugzilla ticked and don’t want to delete it, you need to change status from “Resolved” to “Verified” and set the resolution status to “Invalid”. It is not a deletion, but that allows us to filter such tickets.
4. Main functions used in CS 577
4.1. Login
Go to the website http://greenbay.usc.edu/bugzilla/, and enter your user name and password to get in. The user name is your USC email, the password is “team##” (e.g. team01 or team12) you belong to, and you could change it after you get in.
Figure 4
Figure 5
You could also learn how to use Bugzilla by clicking on “Bugzilla User’s Guide”
4.2. [All roles] Create a new ticket
v Click on the link “File a bug” or “New”
Figure 6
v Choose your project
Figure 7
v Create a new ticket
You need to enter the following information:
· Component: these are the artifacts that you want to report defect; e.g. LCP, FED, Architecture description, or any software component …
· Importance: describes the priority of a defect, which are Resolve Immediately, Normal Queue, Not Urgent, Low Priority, Resolve Later
· Status: “New” or “Assigned”, If you are sure it is a defect, then choose “Assigned” (assuming that you know the responsible person for this artifact)
· Depends on: list of tickets that this ticket depends on.
· Assign to: The email address of whom that is responsible for this artifact
· Ticket type: such as Artifact defect, Bug, Task, Team activity.
· Artifact version: artifact’s version number. This attribute applicable only to defects in documentation.
· Value of work: numerical representation of the value. 100 – very important and valuable work, 0 – not important.
· Related Win-Win conditions: associated Win conditions. Fill in win conditions’ ids from Winbook.
· Role: is a certain area of expertise required for accomplishing the task. Choose all the roles required for the task. Actual list of the roles is defined by the team. Here is a default list of roles, which could be extended by the team:
o Project manager
o Life cycle planner
o Feasibility analyst
o Operational concept engineer
o IV&V
o Prototyper
o Architect
o DB architect
o Developer
o UI developer
· Triggering ticket: Id of the Bugzilla ticket that caused creation of this ticked.
· ICSM Phase: identify the phase that you report this defect, Exploration, Valuation, Foundations, Development-Construction, Development-Transition, Operation
· Milestone: identify the milestone before or on which you report this defect VCR, FCR, RDCR, DCR, CCD, TRR, OCR
· Summary: a summary of the defect report
· Description: Describe the defect in details
· Orig. Est.: estimated number of hours for the task
· Hours Worked: this value should be updated at least once a week and every time ticket changes its status.
· Hours Left: this value should be updated at least once a week and every time ticket changes its status.
Figure 8 Mandatory fields
4.3. [IV&Ver] Set up “Components”
v Click on “Administration”
Figure 9
v Click on “Product”
v Click on the name of the product (the name is “Semester+Team##”) that you want to add components
Figure 10
v Click on “Edit components”, you can add or modify artifacts that you are going to review as components here:
Figure 11
Figure 12
v Please note: you need to know who in your team is responsible for each artifact and add his or her email address to “Default Assignee”
Figure 13
v Please use: the following recommended component structure:
Ø Project artifacts/documents:
§ FED
§ LCP
§ OCD
§ Architecture description
§ Project website
§ Other artifacts required in the ICSM process.
Ø Project source code components - this set of components should be specific for your project, for example:
§ User interface
§ Database
§ Scheduling algorithm module
§ Report generator module
Ø “Non-component activity” – choose this option for tickets that are not related any particular component above. For example, team meetings, win-win negotiation sessions, ARBs, project planning.
That is an example of how you components structure may look like:
Figure 14 Components list
4.4. [IV&Ver] Report an Artifact defect
v Create a new ticket
Create a new ticket using instructions in section [All roles] Create a new ticket. Choose ticket type: “Artifact defect” and fill in “Artifact version” field.
Figure 15
v Two tips to save effort to report defects.
When IV&Ver report defects, they are required to fill the required fields for each defects, however, some defects share the same fields, especially when you report defects from the same artifact. Filling the required fields for each defect might be time consuming. Bugzilla provides two functions that allow users not need to fill every field for each defect if they have the same value with the other defect.
1. Use “Remember values as bookmarkable template” button. This function will remember the field values of the current reported defect, and go to the “Enter Bug” page with the same fields’ values, and you just need to change the fields’ values that the new defect is different from the previous one.
Figure 16
2. Use “Clone This Bug” button. For example, If you know Bug#1 shares most of the fields’ values with the defect you are going to report, first you goes to the page of “Bug#1”, you will find the “Clone This Bug”, then click on it, and you will go to the “Enter Bug” page with the same fields’ values, and you just need to change the fields’ values that the new defect is different from the previous one.
Figure 17
4.5. [IV&Ver] Generate Report
v Click on the “Report” link
Figure 18
Use “Search” function to generate reports.
Figure 19
v Generate Report
At least choose fields as below:
Figure 20
Figure 21
v Click on “CSV” to generate the report, the report format is like below, you need to generate separate report for each artifact and name it according to the rules in the assignment and put it on the team project’s website.
4.6. [Project manager] Report a team meeting
v Create a new ticket using instructions in section [All roles] Create a new ticket.
v Enter ticket credentials according to section: “Team meetings”
4.7. [All roles] Report progress on ticket
v Find tickets assigned to you:
Figure 22
Figure 23 Bug list
v Update ticket properties:
Review and update ticket properties. If task was in progress and you spent some time on it, this effort must be reported. The following fields should be updated at least once a week:
· Depends on: task that blocks this ticket.
· Hours Worked: number of hours you spent on this ticket.
· Hours Left: number of hours you expect to spend on this ticket to finish it.
· Status: once you start working on this ticked status should be changed to “In progress.” If you think that work is done, then change status to “Resolved”, so that IV&Ver or Project Manager could review and verify completeness of the work. IV&Ver must verify all resolved tickets, and if there are some defects or questions then status should be changes to “Reopened”. Otherwise ticket should be closed. See workflow in section Ticket life cycle,