To make your notes as useful as possible for your colleagues and
reduce back-and-forth traffic that they might require to gather
more information, consider these tips for filling out each of
the note fields:
(click to enlarge)
For web projects, enter the URL of the page on which you've
discovered an issue. For non-web projects, you can enter
any description that makes sense for your project, such as
a screen or module name. The important thing is that other
team members can quickly find the issue you're describing. If you're
creating a new note from the Betaboard
browser, the complete URL will appear in this field
Select the computer platform and, for web projects, the web
browser name and version from the popup menus. If the issue
appears in multiple environments, you can state that in the Other Comments
field below. If you're creating a new note from the Betaboard browser, the
Environment settings will appear automatically.
Enter a short but distinctive description of this issue. The
subject will appear in Betaboard's main note list, so a good
subject will help your team members quickly scan open issues. Here are some
examples of effective and ineffective subjects:
- broken link in footer
- still need intro video
- popup window too small
- text change (not unique)
- error (not specific)
- set vlink color to #330066 and alink color to #9999CC
in home and default templates (too long to scan)
This setting should be self-explanatory, but be sure to set
it, as it will help your project managers quickly assign
notes to team members.
Select a priority based on your sense of the importance of
this issue. As a rule of thumb, the notes you post should
be distributed fairly equally across the different priorities. After all,
setting all your notes to Urgent is like crying wolf and will probably result
in all your notes being ignored! Also, be aware that project managers or
other team members may change the priority as new notes are posted or more
information about this issue becomes available.
Setting the difficulty for each note makes it much easier
for project managers to prioritize which notes should be
addressed within the available time. However, it's usually
best to let developers or other technical staff set the difficulty,
since they will understand the work required to address the
Hours to complete
For even greater accuracy in prioritization, especially
when deciding which issues to address in an hourly billing
situation, notes can include an hour estimate in addition
to a general difficulty setting. Again, it's best to let
technical staff enter these estimates.
Describing the issue...
(click to enlarge)
What did you see?
This is your chance to tell team members about the issue
you've discovered. However, it's best to focus your description
on what you literally see when you look at the issue,
rather than an interpretation of what is happening or why.
If you see an error message, include the complete text of
the message. It also helps to be as specific as possible.
For example, "When
I click the Home button, a file not found page appears" is much
more useful than "The
home button doesn't work."
What did you expect to see?
Sometimes a description of the issue is not enough to show
what change you'd like to make. So, Betaboard includes this
second field to give a complete picture. For example, if
you entered "when I clicked the Exit button, the window closed"
in the first field, you could enter "I expected to receive a confirmation
message before the window closed" in the second field.
Is this a fix or a new idea?
Some Betaboard notes will describe new ideas that you want
to add to the product, and the previous two fields will be
enough to describe those. But when describing fixes to an
existing portion of the product, a bit more information will
be helpful. If you select Fix here, the next two fields will
Do you see the problem every time?
If this issue appears every time you view the page, and
you're confident that other team members will see it when
they look, set select Yes here. If you're dealing with an
intermittent bug that you've only seen occasionally, and
aren't sure when it will appear again, select No.
What steps can someone else take to see this?
Chances are, other team members use the product slightly
differently than you do, and that's why they haven't already
seen and fixed the problem you've found. You'll need to describe
exactly what you're doing so they can see it, too. Here's
an example: "Navigate
to any of the Flash demos in module 2. Set the volume
of the demo. Click the menu button. Navigate to the same
Flash demo. The volume setting is correct. Now click
Next to view another Flash demo. The volume resets
to 100%." (This example assumes that you did test several Flash demos
to be sure the problem occurs with each of them. If the problem
only occurs with particular demos, you would want to specify
that as well.)
If new content or other assets are contained in a separate
file such as a Word document or Photoshop file, you can
attach it here as a convenient way to send the file to other
team members. The file will remain attached for the life
of the note.
If any other information seems relevant, but doesn't fit into
the other fields, you can enter it here when you post a new
note. Your comments will appear in the note's History area when other users
view the note.
Collaborating with your colleagues...
(click to enlarge)
For existing notes, enter additional details, questions, or
a report of decisions or changes you've made in this field.
Here are some examples of useful discussion entries:
"Manuel, I think this is fixed now, but can you try
it once more on your computer?"
"Shelved for phase 2 per discussion with client this
morning. See also note 1265 for a related issue."
"This change has been uploaded to the development
server but not the production server."
Select the member of your team who should read this note next.
On new notes, this menu probably won't appear unless you're
a project manager.
Select the status that best describes where this issue currently
stands in the development cycle. A status might remain at
In progress, for example, for several submissions, or it might revert from
In review to In progress if someone on your team decides that more work
Select this checkbox to send a short email message to the
recipient you selected in the Send to menu. The message he
or she receives will contain the subject of the note and
a direct link to the note.