Jump to content

Photo

HOW-TO: Make a proper bug report


  • This topic is locked This topic is locked
No replies to this topic

#1 Eurysilas

Eurysilas

    Paladin

  • Members

Posted 15 September 2008 - 04:50 PM

The purpose of this thread is to show how to make a proper bug report. It's singular goal is to improve the quality of bug reports being submitted. The following template does not HAVE to be used, but it is encouraged that you do so, and certainly speeds up the process of submitting a report. With that in mind, the first thing you should know is that a bug report has three main phases:

*Report Bug

*Submit Test Quest

*Follow up

This document will cover the "Report Bug" section, though it will also describe the "Submit Test Quest" and "Follow Up" sections. Let's examine the "Report Bug" phase in closer detail:

*Report Bug

+Priority

+Program

+Onset Version

+Affected Subsystem

+Reproducibility

+Unwanted Behavior

The various subsections correspond to what should be in your bug report. Each one provides another piece of the puzzle that is debugging, and is therefore essential. Priority, for example, allows developers to take care of bugs they deem the most critical, whereas the onset version, which is the most critical section after unwanted behavior, gives developers a clue what changes caused the bug in the first place, and therefore act as a kind of locater. The following is a more in-depth explanation of each subsection. Some of what is covered is fairly obvious to most, but is mentioned so that no one forgets:

Priority: Minor (Does not crash player/editor and does not render certain features of editor unusable/quests unplayable), Major (renders certain features of the editor unusable/quests unplayable, but does not crash editor/player), Critical (crashes player/editor).

Program: Is the bug in Zelda Classic (the player) or Zelda Quest (the quest editor)?

Onset Version: In what version did the bug appear in? DO NOT USE THE FINAL VERSION NUMBER OF AN UPCOMING RELEASE HERE, USE THE BUILD NUMBER INSTEAD.

Affected Subsystem: What area of the program is being affected (graphics, pixel editor, combos, etc)?

Reproducibility: Is the bug consistently reproducible, or only occasionally?

Unwanted Behavior: The most critical portion of the report, what is the undesirable behavior that is taking place?

When filling out these various subsections, remember to be thorough. Too much information is preferable to too little. This is important especially in the "Unwanted Behavior" subsection, but can apply to other subsections as well (for example, if you know for a fact that a bug spans more than one build of the player or editor, report it!). Now, let's move on to submitting a test quest.

A Test Quest is essentially a quest whose focus is to demonstrate the bug you're encountering. It is a very important element of a bug report, as it provides an environment where the bug can easily be verified and reproduced (if done correctly), and can if the developer so chooses serve as a testing ground for new code. Naturally, this step will be skipped if your bug is not in the player. A Test quest should be created with the intent of being as simple and direct as possible. Try to keep it to one room if you can, and don't be tempted to do more than is necessary to provide a playable environment in which to test the bug.

The last phase in the bug reporting cycle is to follow up on the report. This can only take place once the developers have committed a fix, so be sure to check back often to see the status of your particular bug. If a fix has been attempted, try confirming it. If the bug still occurs or is fixed, then make an addendum in your report to indicate this. If a different bug now occurs, start on a new bug report, but be sure to mention that the old bug and new may be related in your report.

I realize this may seem like a bit much to do for one bug, but ask yourself this- do the developers go through any less coding a fix? Their time is just as valuable to them as ours is to us, so let's make every effort to give it maximum value by giving thorough bug reports, so developers don't have to waste their precious time sifting through gobbledygook. This concludes the bug report tutorial. I hope you found it informative, and that you'll use it. Remember, the developers couldn't possibly find and correct all the bugs without your help, so please, if you enjoy Zelda Classic and wish for its continued development, become a beta tester today! You could literally make the difference.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users