Bug Tracking and Bugzilla

1
Bug Tracking and Bugzilla

• CS 420 Software Engineering in Practice

2
Why we dont like writing bugs

• It takes timethat we dont think we have.
• We already know the information we are only
  writing about it for someone else. Ill just
  tell him about itor not.
• We know we can fix it before the time it takes to
  write up the bug. So, why write up the bug?
• Who really cares besides Orest?
• The bug tracking system drives me nutsI dont
  understand it.
• Theres no reason to draw attention to the
  problem. I should have caught it earlier.
• Im a developer Im supposed to be an introvert
  who likes to keep problems to myself.

3
That saidwhy enter bugs anyway?

• You are part of team, and it serves as a means of
  communicating problems across team members.
• Your bug may be one of many bugs that you and
  others dont know about unless it is tracked. It
  may even be related to another already known
  problem.

4
That saidwhy enter bugs anyway?

• Release management procedures may already be in
  place, which dont take your bug or fix into
  account. A Help file change might be needed.
• Someone else may know more about the priority of
  deferring or fixing the bug than you do.
• A fix might require regression testing, which
  needs to be scheduled.

5
Why use a bug tracking tool?

• Provides a history as to the effort and decisions
  involved with solving a particular problem.
• Provides a means for tracking the status of the
  test and fix cycle.
• Helps prioritize the development and QA effort.

6
Why use a bug tracking tool?

• Serves as a repository for future enhancements to
  products.
• Helps to assess the overall quality of a release
  candidate application.
• Its simply the intelligent thing to do!

7
Approaches to Bug Reporting

• If the bug report is not clear and
  understandable, chances are that the bug report
  will be ignored. Take a moment to learn how to
  write an effective bug report.
• Write problem reports immediately, as soon as you
  can. You are more likely to write an effective
  report.

8
Approaches to Bug Reporting (cont)

• Team members are likely to dismiss reports of
  problems that they cannot see or reproduce. Take
  a moment to ensure the bug is reproducible. If
  you cant reproduce it, indicate this.
• Team members are more likely to postpone dealing
  with a bug report that looks long. Provide
  supporting evidence in the form of an attachment.

9
Approach to Bug Reporting (cont)

• Check if the same bug already exists in the
  database. Someone else may have already reported
  it. Duplicates waste time and confuse the
  process.
• Get familiar with the bugs logged against a
  project you are working on. Learn to run queries
  on the various bug data fields, and customize
  your views.

10
Approach to Bug Reporting (cont.)

• A bug report that irritates the reader does not
  motivate him/her to fix it or verify it. Be
  respectful focus on the problem, not the person.
• Enter one bug per report. Multiple bugs can
  result in multiple resolutions which complicate
  the bug reporting process, when written as a
  single bug.
• Dont skip fields that are optional. They are
  meant to be optional only when they dont apply
  to a particular problem.

11
How to enter a new bug

• Reporter That will be you! Its automatically
  filled in.
• Version Options provided.
• Component Options provided.
• Platform Options provided.
• Operating System Options provided.
• Severity Options provided.
• Frequency Options provided.
• Priority Options provided.

12
How to enter a new bug

• Assigned To Enter the email address of the team
  member to whom the bug should be assigned. If you
  do not fill out this field it will automatically
  be assigned to the default component owner.
• CC Enter the email addresses of any team
  members you wish to give notice of the bug
  report.
• URL Enter the URL for the application instance
  

13
How to enter a new bug

• Summary Enter a concise statement that
  describes the problem. Remember that this field
  is used to find and review bugs. Make it as
  short and meaningful as possible.
• Steps to Reproduce/Description Steps for
  describing the bug should be enumerated when
  appropriate. It makes it easier for the
  investigator to reproduce it, and it makes it
  possible for someone, other than the reporter, to
  verify the fix. Provide any useful comments or
  information that enhances the description. If
  you have a copy of the log file, a screen shot,
  or any other supporting documents include them as
  attachments.
• To include an attachment Finish filling out the
  bug report and select Commit. The confirmation
  page which follows will include the ability to
  add attachments. However, once the bug is saved,
  you are free to return to the bug and add an
  attachment at any time. The attachment field
  will be visible.

14
Determining Severity/Frequency/Priority

• First, some definitions
• Severity the impact or consequence of the bug
  to the end-user, an organization, third parties,
  a service, etc.
• Frequency the likelihood of the bug occurring
  or manifesting itself to the end-user, an
  organization, third parties, a service, etc.
• Priority the relative importance of addressing
  and resolving the bug
• Given the above definitions, it is easy to see
  why the Priority would best be defined as a
  result of understanding the combination of both
  Severity and Frequency of a bug.
• The Registry Team should review and agree upon
  the definitions and guidelines that follow.

15
Defining Severity

• Severity the impact or consequence of the bug
  to the end-user, an organization, third parties,
  a service, etc.
• Blocker
• Critical
• Major
• Normal
• Minor
• Trivial
• Enhancement

16
Severity - Blocker

• Blocks development and/or testing work (new
  build, with fix, needed immediately)

17
Severity - Critical

• Critical
• Application crashes
• Application or service does not work as intended
  impossible to use the application or a main
  function of the application critical
  functionality lost
• Stored data corrupted
• Conflicts with a high-priority (must-have)
  accepted requirement
• Severe memory leak
• Compromises Stanfords standards or policy (e.g.
  security)
• Help file is missing
• Help file is incorrect and misleads the user

18
Severity - Major

• Operation is significantly impacted
• User is possibly lead to creating future problems
  
• Conflicts with a medium-priority accepted
  requirement
• Spelling or grammatical mistakes in the User
  Interface

19
Severity - Normal

• (Would like to see this changed to Average)
• Loss of function, but there is a clear
  work-around
• Unfriendly behavior that is hindering, but
  workable, for the user or service
• Explanation of feature missing from Help File

20
Severity - Minor

• Cosmetic problems in the UI, other than spelling
  and grammatical mistakes i.e. font sizes,
  placement of controls (edit boxes, list boxes,
  etc.) that are not hindering
• Unfriendly behavior that is merely annoying to
  the user
• A problem of small impact to the user
• Spelling or grammatical mistakes in the Help File

21
Severity Trivial/Enhancement

• Trivial (Remove Redundant to Minor. We do not
  need this level of granularity.)
• (Do not use Use Minor instead)
• Enhancement
• Nice to have feature (not in scope)
• Request for change

22
Severity

• Severity is a required field.
• By default, Bugzilla has Normal selected on the
  new bug entry form. If this is not correct for
  the bug which is being entered, you should change
  it to the correct Severity.
• If there are better ways to describe the severity
  of defects for applications that are background
  processes (i.e. the Regis apps and Slogs), then
  we should be sure to add those here.

23
Defining Frequency

• Frequency the likelihood of the bug occurring
  or manifesting itself to the end-user, an
  organization, third parties, a service, etc.
• Always encountered at all time
• Likely will probably be encountered
• Unlikely will probably not be encountered

24
Frequency

• Determining Frequency can get confusing
  considering that likelihood of occurrence can
  be applied to all users or a single user.
• Frequency is a required field.
• By default, Bugzilla has Likely selected on the
  new bug entry form. If this is not correct for
  the bug which is being entered, you should change
  it to the correct Frequency.
• Frequency should be determined by those who have
  the knowledge to do so. However, you should make
  an educated, or uneducated, guess.

25
Defining Priority

• Priority the relative importance of addressing
  and resolving the defect
• P1 Resolve Immediately
• P2 Give High Attention
• P3 Normal Queue
• P4 Low Priority
• P5 Waiting Priority (not in scope or
  significant enough to be prioritized)

26
Defining Priority