BugZilla Issue Tool Training

November 11, 2007

This is a moderator-led training session.

INTERNAL ñ the client doesnít see these. Projects are all located under the ìseiî tag.

bugs.seiofwa.com/sei

EXTERNAL ñ this is for us to solve problems for the client. They log a bug here and we fix it. Not for internal use, and be conscious of the fact that the client will have access to all comments. Projects are located under their specific project code.

bugs.seiofwa.com/tw

bugs.seiofwa.com/orts

bugs.seiofwa.com/radar

The information below is mostly from the help file of Bugzilla, so if you get lost or forget, go look there.

The Anatomy of a Bug

At its most basic form, a bug consists of three parts:

1. What the problem is
2. Who logged the bug
3. When the problem occurred

Summary and Comments

The comment field is something we've already covered: a list of comments on the bug, including the bug's original description. Comments is plural, because other users or testers may wish to make comments during the regression process.

However, since comments can span many pages, it's not a good idea to display them in a list of results. Because of those space constraints, the summary field was created. This way, when a tester brings up a list of bugs, each has a short description. The summary gives a general idea of the bug's contents without taking up much space.

Be specific with this.

Summary: ìMissing ëclick nextíî is better than ìbugî.

Course, Screen ID, Browser, and Operating System

The main thing that separates one bug from the rest is where the problem happened. Accordingly, there are three fields to indicate what part of the courseware a bug was found in.

Category, Version, and Priority

We are still working on categories. Global, text, narration, animation, GUI, ??

Status and Resolution

Reporter, Assignment, CC Lists, and Times

Attachments

The Life Cycle

Bugs move in a fairly predictable pattern:

Note that a bug may move between Resolved and Reopened as many times as is necessary, before being closed. Bugs can also be re-opened once they have been verified or even closed.

A Typical Lifespan

One Bug, Many Resolutions

There are many ways for bugs to be resolved, and many times the bug can be resolved without being fixed. Below, we'll cover each resolution, and when a bug qualifies for that status.

• Fixed means exactly what it says, though; the bug was a valid bug, and it has been corrected.
• Invalid bugs are not really bugs at all, but rather mistakes. It is appropriate to mark a bug as Resolved Invalid if there is not enough information to reproduce, find, or fix the bug. Also, occasionally someone may not be familiar with a project's specifications and log a bug on what is actually desired behavior or content: those bugs may also be marked invalid.
• A bug is Unfixable if the bug is actually a bug, but other parts of the project or course depend on that quirk. For instance, if the course specifications require that all images be in 24-bit color, but one image is created in 8-bit color to preserve the tone of the photograph, that bug may be stamped as unfixable.
• Later, however, means that the bug is verified to be a bug, but that time or resource constraints prevent it from being fixed at the moment.
• Reminder bugs are kept open even when they are fixed, so that the bug can be kept as a more visible example of something.
• When a bug is identical to another one that has already been logged, it is marked as a Duplicate. A notice is added both to the original bug, and the new bug.
• Nonconfirmed bugs are ones that cannot be reproduced; in other words, "It works for me."
• Last, bugs moved from one database to another are marked as Moved to indicate that they were successfully placed elsewhere.

On the search page, there is an extra entry in the select box: "----". This is not really a resolution in itself, but is used to indicate that a bug has no resolution.

Help - Creating Bugs

Overview

A bug is a defect in data, software, or hardware that prevents normal or desired operation of a process. The following are examples of bugs:

 The home page has overlapping images.

 The second link on the page does not work.

 Permissions for this course need to be allocated.

However, there are many things that are not bugs:

 This graphic sucks!

 I don't like the color scheme.

 Why are we using Flash anyway?

As you can see, these examples are subjective comments that are not actually problems. So, let's move on to the rules of bug making.

The Bug Commandments

Write professionally.
Although this might seem to be something obvious, tempers often flare around deadlines and blame gets thrown around. It's often tempting to make snide comments, because Bugzilla seems so impersonal. However, it is the responsibility of a manager to deal with someone's responsibilities (and to do it offline.) Avoid things like !! or ??. Emoticons are generally also a no-no and sarcasm is often misunderstood. Writing professionally will keep your teammates happier with working with you, because the bugs you write address a problem with the product, not a problem with them, the creator.

Avoid accusatory comments.

Using accusatory statements like ìYou did this animation wrongî is counter-productive in many cases. Instead, write something like, ìThis animation is inaccurate. Please have the arrows going the other way.î

Create objective bugs.
This is the most important rule. If something is your opinion, it probably isn't a bug. Even if you feel strongly that something is really wrong, go back to the project specifications and make sure your feeling is legitimate.

One thing at a time.
Putting more than one problem into a single bug report messes things up by confusing everyone involved. It's perfectly fine to put more than one editorial fix in a bug if all of the fixes are on the same screen, or two programming issues that are obviously related, but putting a programming problem and an editorial issue in the same bug is not a good idea.

Bug 24

Mark enhancements appropriately.
If you do have an opinion, you're welcome to share it as long as you mark it as an enhancement and explain your suggestion logically. If your suggestion is good and can be implemented without too much trouble, chances are that it will happen.

"All" means global.
When you're entering a report on a bug that affects more than one screen of content, use the word "All" in the screen ID and summary fields. This helps people to search for global bugs more quickly, and is a great way to indicate very severe problems.

Also, if this applies to all, mark the category as ìglobalî.

Be ready to reproduce your bug.
Bugs will never get fixed unless they are always happening. If a bug seems to show up just once in awhile, chances are that it's your computer acting strangely.

Be specific about the bug's location.
It's really hard to fix a bug when you can't even find it. When writing, be sure that you include as much information as you can about where the bug is. If it's on a screen of courseware, include the Screen ID; if it's on a website, include the URL. More information is always better.

Be specific about what is happening.

This seems obvious, but what this means is to make sure to use pronouns as little as possible, and call whatever you can by its name. Much of our time is lost trying to figure out what the reporter was talking about.

#27

Reference other bugs only by necessity.

Only reference another bug if it will add to what you are making a comment on.

A bad example of this would be #5:

Once again, why is the full text for the segments of the exercise in the CC area?
 
 

EXAMPLES OF BUG WRITING

The Good and the Ugly

Most bugs are fairly well-written: they explain where to find the bug, what it is, and what should be happening instead. But occasionally, we all slip up and write something like this:

 My browser crashed. I think I was on screen 15 in 12B10. This

 is a really bad problem and you should fix it or else nobody

 will want to take the course. By the way, I think your icons

 really suck. Oh, and my bold tags aren't working in the next

 module either, they're all messed up. Thx 4 fixing theze bugz.

On the other hand, this is far more likely to get fixed:

 My browser crashes when I visit B01_2_3_13 in NBC and try to

 play the Option3A_Audio file. I'm using Internet Explorer 6

 SP1, on Windows 2000, and this also happens in IE 5.5 on

 Windows 98.

The differences between the two examples are fairly obvious. The first is unprofessional, subjective, mentions three different issues, and doesn't provide a specific location. It is far more likely to be ignored and marked as Invalid, even though the problems may very well be real. The second, however, will be treated with more deference.

Bug Categories

When logging a bug, you should choose its category carefully. Otherwise, people will waste time moving the bug around.

You should be especially careful when logging Programming bugs. Often, a bug that seems to be a programming issueóa screen that doesn't go to the correct page when you hit Next, for exampleóare actually issues with Instructional Design or Graphics. Also, it's often tempting to include lots of problems in a single bug because they seem related. Avoid the temptation, and unless you know that two problems are connected, keep your descriptions thin.

For the most part, all bugs belong to Graphics, unless it addresses something the ID is the decision maker on. For example, breaking apart instruction across separate screens.

Creating a Bug

After clicking on the New Bug link at the top of a page, you may be asked to choose a course to enter a bug in. If you only have permissions to a single course at any given time, then that course will automatically be chosen for you.

You should search to make sure you are not logging a duplicate bug. This is especially important when logging global bugs, because often the bug will affect screens in a variety of different locations. Communication with your co-workers is essential so that the job doesn't get done twice.