Please note:If you have not been given access to a CodeGear field test,
this field tester guide will not apply to you.
QualityCentral(QC) is an issue tracking tool
that supports field tests for CodeGear products. You can use QualityCentral to create reports that are only visible to
other field testers and CodeGear. Field test reports are treated exactly the same as all other reports in
QualityCentral, except field test reports are only visible to field testers and CodeGear until the field test has
completed.
Before using any QualityCentral client, you must have a Developer Network account. You can create one, or login to set
your user cookie, by going to https://members.codegear.com.
All three clients for QualityCentral have a field test registration dialog. When you register in QualityCentral as a
field tester, your user account is flagged as a field tester for that specific field test. The field test registration
dialog allows you to register for one specific field test at a time. You can participate in multiple field tests at the
same time using QualityCentral. You just need to use the field test registration dialog to register for each field
test.
All field test registration dialogs require the same three pieces of information: the field test name, the field test
username, and the field test password. All values are case sensitive. Your field test administrator
will provide you with the exact spelling for each value. Use these values in the field test registration dialog, not
your personal user account information.
Once you successfully register for the field test, the QualityCentral client will automatically make project entries or
product version entries visible for you. If you are using the Java or Windows client, you will need to restart them in
order to see the field test values. For the Web client, you can go to the main page and see the field test project for
which you just registered.
The field test registration dialog is found at http://qc.codegear.com/wc/qcmain.aspx?ftreg=1. Put in the
appropriate field test values and click submit to register for the field test. If you are not currently logged in to
the Web client, you will be required to login before registering for the field test. Once you are registered, you can
go to the homepage for QualityCentral, and navigate to the appropriate area for the field test. Field test entries will
now be available for you to see.
The Web client interface is entirely browser-based and should be compatible with all popular browsers. You can login to
the Web client at any time by going to http://qc.codegear.com. Please note that the PrimeTime IDE browser currently does not
support cookies, so you will not be able to use it for the QualityCentral Web client.
You can download the Windows client by following the link on the QualityCentral
homepage. You may also want to download the Windows client auto downloader to ensure your QualityCentral client is
always current.
The field test registration dialog can be found in the Windows client by invoking the View|Options menu
and selecting the "Beta Registering" tab. Fill in the three required values and hit the Apply button to
register for the field test. Then restart the client to retrieve all field test lookups in addition to the standard
lookups.
The Java client for QualityCentral can be downloaded from http://qc.codegear.com/qcjavaclient.zip. See the Java client user guide for instructions on
installing and setting up the client. Once the client is set up, you can invoke the field test registration dialog by
selecting the User|Field test registration menu.
Fill in the field test registration values and click the OK button to register. Then restart the client to see the
field test entries added as lookup values for the client.
When you discover an issue during the field test that you think is a bug, use the appropriate field test newsgroup to
discuss what you've found before entering a bug report. Someone else may have discovered the same
thing, and either already provided a link to their bug report in QualityCentral, or have advice on helping you narrow
down your bug report.
After you have discussed the bug and verified that it is indeed a defect, and something not already reported, you
should post it to QualityCentral with as much information as possible in the description, and specific steps to
reproduce the bug.
When you enter the bug report, be sure to put the correct version for the bug report into
QualityCentral. After you have registered for a field test, you are able to see versions that only people registered
for the field test can see. You must be sure to select the field test version when reporting the bug
so you do not violate your NDA. If you are sure the bug exists in a publicly released version of the
product you are testing, then use the public version of that product for the report, so other QC users can see the bug
and vote on it if they so desire.
As our projects become more integrated, the exact project you should use for reporting the bug might become a bit
unclear, so you can use these general guidelines to help you select the right project. Consider the Developer Studio IDE as
an illustration:
Developer Studio 2006 supports multiple languages (C# and Delphi, and C++) and multiple platforms (Win32
and .NET). You might be using the refactoring engine for a Delphi for .NET
application, and encounter a bug. Before entering the report under the Delphi for .NET project, you should check and
see if the bug occurs with any other language or platform the IDE supports. If it does, you should report it under the
main project (in this case, Delphi) rather than a language or platform specific project, like Delphi for .NET or
C#.
Don't get too hung up on this requirement, however. We need the bug report, even if it might be arbitrarily limited
to a specific personality when it applies to multiple personalities. If you can't verify the bug in other
personalities, get it reported anyway. A QC sysop or someone in QA or R&D can probably determine if it applies in a
more broad sense.
Please make an attempt to locate the most appropriate location for the bug report when you file it. Some of the project
hierarchies are very extensive, and the more accurate you make your report, the better the chance of someone from
CodeGear acting on it because it appears in their area of interest.
After you have filed the bug report, post a message to the appropriate fieldtest newsgroup and
include a link to the bug report so others can easily retrieve the bug report and engage in discussion
about it directly in the report itself, so conversation pertaining to the report is retained in the report from that
point on. By providing the link in your initial newsgroup post, you make it convenient for anyone to get more details
on the bug report.
All reports posted into QualityCentral initially have a status of "reported" until the status is changed by a
QC sysop. Unless you flag a QC report as private, all field testers who have registered for a given field test in
QualityCentral will be able to see all field test bug reports. This should help reduce the duplication of bug reports
and facilitate discussion and verification of bugs during the field test.
All QC sysops should be familiar with the QC sysop guide.
Any QC sysop level 1 can mark a report as "Needs attention" so a higher-level sysop can process the bug. When
marking the report for attention, a comment is required to describe what you think should happen with the
report.
QC sysop level 2 can promote the bug report to the internal bug tracking system. Any QC user who has a RAID account
with write access can automatically become a QC Sysop level 2 by registering their RAID user account with
QualityCentral. See the last paragraph of Becoming a sysop
for instructions on registering.
If you are a QC sysop level 2, you should only promote bug reports you have reproduced for yourself.
Promoting bugs that cannot be reproduced is one of the quickest ways to lose your sysop privileges.
Connect with Us