What is a Bug?

First, it's important to know what constitutes a bug: A bug is a problem with the code that causes the program to do something in an incorrect way, usually (but not always) producing some sort of error message.

Simple enough, right?

Feature Requests

It's important to note that wanting something to work differently than it does (or even for it to work "as it did in the last version") is not considered a bug, but instead a feature request.

While we're always happy to take feature requests, during the beta testing period, we must focus on actual bugs. All feature requests will be considered for future versions, not for the one currently being tested.

Before You File the Bug

In order to be as efficient as possible and spend our time making the best software we can, there are a few things, listed below, that we would ask of you.

Stay Current!

Keep your beta testing installation up-to-date with the latest version released here on the Beta Blog.

There are few things more painful than spending a lot of time working to communicate and understand a problem only to discover later that you're on an older version. This is a waste of your time and ours.

In beta testing, last week's build is non-existent. Always make sure before reporting any bug that you are using the latest test version and that everything is as up-to-date as it is on our side.

Reproduction and Reduction

Reproducibility is crucial in bug submission and fixing. If we can't reproduce your problem, it is almost impossible to determine its cause and hence to fix it. Before submitting any bug, you should try to reproduce the problem multiple times and carefully note the result of each test.

A side benefit of reproducing a bug is that the events are very clear in your mind. If you can reproduce a bug five times or more, you can easily describe it accurately without leaving things out or clouding the issue with extraneous details.

When you are trying to reproduce the problem, try to reduce it down to the exact cause. If you can point to one environment variable that can be changed to either cause or alleviate the problem, then you've probably done a good job of reduction.

Test in Alternate Environments

In attempting to reproduce your bug, you should also try it in different browsers or under different environments to eliminate the possibility of it being a browser bug or a result of some special setup (i.e. plugins, Apache configurations, operating systems, etc).

Having this information can speed both the discovery of the source of the problem and its fix.

Check the Known Issues list

Because we are using an internal bug database, it is impossible for you to see that over three thousand people beat you to reporting the bug you found. As you can imagine, however, such a scenario would be not only highly inefficient, but may land the Bug Master in a nice white jacket in a padded room.

For that reason, we shall be maintaining a known issues list with all of the biggest issues listed. Before you file any bug, please, please check this list first. If you bug is on that list, don't submit another case. Please be patient and know that we're on it.

A Picture is Worth a Thousand Words

Someone said that a picture is worth a thousand words, and with bug reports, it's worth three times that.

Screen shots help frame the discussion so that we know where you were in the interface and what you were seeing. They eliminate the need for a lot of discovery and help speed us along to reproducing the problem.

If you're having a UI issue or even a bug that can be easily explained with a picture, please attach it to your bug report. Alternately, you can use the Upload file feature in Movable Type to place a screenshot on your testing site, and include the URL to the image in your bug report. This is particularly great if you have multiples.

Words can be confusing, but pictures rarely are.

One bug, one report

When you file multiple bugs in a single report, God kills a kitten. We've written about this before...

Where to Submit a Bug

Now that you've got the bug identified, reproduced, isolated, and perhaps taken a screenshot or six, it's time to pass it on! You can do so through our beta tester bug submission interface. The next few items will explain what goes into that email.

Name and email

The chances are pretty high that we will need to correspond with you regarding any bug you submit even if it's only to tell you when we've fixed it. So on the form, we ask for your name and email, because that way, we can contact you and call you by name, like real humans.

Summary

To write a good summary, you have to boil down the problem into, say, less than ten descriptive words. Choose every word carefully. Discard useless or redundant ones or any which convey emotion or opinion. Try to put the most important words close to the front of the subject. Use abbreviations if you need to but only well-known or obvious ones.

Description

The description should contain details that will help our team "follow along" so they can attempt to reproduce the behavior you're seeing. Describe what you were doing and what screen you were on, what you expected to happen, what should have happened, the error you saw, etc. A clear, numbered, step-by-step outline of reproduction steps is ideal

This is also where you'll include any other information specific to your bug, including environmental details and (hopefully) a link to a screenshot.

Remember: If we can't reproduce, we can't fix it.

Attachment

Did we mention we love screenshots?

Where NOT to Submit a Bug

• In email or instant message to any member of the MT team
• In a support ticket from Your Account
• In the comments in the beta blog
• In the Community Forum, unless you're asking for help from other testers to know whether something is a bug

So, there you have it. The basics on filing a bug. Please keep in mind that we may refine, update, or clarify this entry as the testing gets underway, so take a moment to review it periodically (perhaps whenever you update to the latest beta release).