Betaboard(tm) Quality Assurance Manager
OverviewFeature tourBest practicesSubscriptionsSupport
QA processExample workflowFilling out a QA noteGeneral tips
Betabord(tm) Quality Assurance Manager


Want to work with your Betaboard data in other applications? Use the All Note Data report to export all your QA notes in tab-delimited format. This feature also provides an easy way to make local backups!

Subscriber login | Contact us

A service of Arlo Leach
Copyright © 2001-24, all rights reserved

Filling out a QA note

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:

Getting started...

(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 automatically.


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:

Effective subjects
- broken link in footer
- still need intro video
- popup window too small

Inffective subjects
- 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 issue.

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 appear.

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.)

Attached file

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.

Other comments

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."

Send to

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 is needed.


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.