realbasic-nug
[Top] [All Lists]

Bug Reporting Best Practices

To: REALbasic Network Users Group <realbasic-nug at lists dot realsoftware dot com>
Subject: Bug Reporting Best Practices
From: Aaron Ballman <aaron at realsoftware dot com>
Date: Thu, 19 Feb 2004 18:06:17 -0600
Common Mistakes:

1) Do not enter multiple bugs or feature requests in the same report.
Doing this will most likely cause your report to be closed when we only
implement part of it.

2) Do not file new bug reports or feature requests about the same bug or
feature.  Doing so takes a lot of time out of testing for them to merge
your reports.  Also, it's harder for us to contact you when a bug has
been fixed because that bug may have 10 different reports about it
strewn throughout the system.  The search feature of the feedback system
is everyone's friend...

3) Do not file feature requests or bug reports about the feedback system
itself.  Those reports will be closed immediately.  Direct all feedback
about the feedback system to <webmaster at realsoftware dot com>.

Feature Request Mistakes:

1) Do not enter a feature request in which you explain how to implement
the feature.  Things like telling us what API to use or how to name
things only detracts from the request and makes it harder to gauge what
you're really asking for.  It is much better to file a feature request
explaining what problem you are trying to solve.  Doing so helps other
users who are viewing your report as well as developers to understand
the underlying problem that needs solving.

Bug Reports Mistakes:

1) Always send in a sample application.  Doing so reduces the amount of
time spent by the tester and the developers in having to figure out how
to demonstrate the problem.  I cannot stress this enough!  Sending in a
SIMPLE EXAMPLE PROJECT will typically vastly reduce the turnaround time
on fixing your bug.

2) Make sure your sample project compiles.  I know this may sound silly,
but you'd be shocked at the number of projects that come in that are
missing external files (including pictures, resources or sounds) and/or
plugins.  Also, if your sample project has all of these things, then it
sometimes is a good sign that you should try to simplify the problem and
reproduce it in a smaller project.  This isn't always possible, but when
it is, it drastically helps.

3) Crash logs typically are not that helpful by themself.  Image files
are even less so.  We believe that you have found a bug (why else would
you be filing a report!), so you don't need to send in pictures of it,
or a crash log to prove it to us.  What really matters is whether we can
reproduce the problem.  Pictures and crash logs are a good first step,
but to really be helpful, we need clear, concise ways to reproduce a
problem, or better yet, a sample project that demonstrates the issue.

4) This is related to #3 above: sending in your compiled executable
doesn't help at all.  We believe that you are seeing a problem, but
sending us the compiled application doesn't help us to track down what's
causing the issue.

5) Don't assume anything is obvious to us.  Saying things like "read
above" or "it's clear" or "the description says it all" tend to be very
unhelpful in actually reproducing the bug.  If you are not attaching a
sample project, then in the Steps to Reproduce field, please put all the
steps (preferably using code snippets) to reproduce the issue.  If you
are submitting a sample project, then please put down what you expect to
see and what you are actually seeing in the Steps to Reproduce field
along with a quick summary of how to run your app (if it's more complex
than just a single button to push to see the problem).

Things You Can Do To Help

1) If you notice something you filed a bug report against has been
fixed, please use the Submit a Suggestion field to let us know that we
can close your report.  Doing so helps us out by not having to try to
verify whether your report is still an issue or not.

2) When filing a bug report, be sure to select the proper system
information.  If you see a bug in Windows or Linux, but select Mac OS X
as the system it occurs in, chances are we won't be able to reproduce
your bug, and it will be closed.

3) Don't assume that a bug has been filed just because it seems obvious
to you.  If you run across a bug, search the feedback system to see if
someone else has already reported it.  If they have, then "me too" the
report.  If no one has reported it, then report it so it can be fixed.
--
To me, hockey is like boxing, except there's no bell, no ropes, and the boxers carry sticks.

- - -
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

<Prev in Thread] Current Thread [Next in Thread>
  • Bug Reporting Best Practices, Aaron Ballman <=