QualityCentral user guide

(Please report any issues you find with this documentation to the QualityCentral project Documentation/User Guide area.)

QualityCentral (QC) provides a community process for resolving, clarifying, and tracking quality issues regarding Borland's products and services. Borland Developer Network (BDN) members can create bug reports and feature requests, view other members' reports, and comment and vote on the reports most important to them. Borland personnel also participate in QualityCentral, providing a permanent link betweenBorland customers and the teams who produce Borland's products.

User guides specific to clients

The user guide specific to the Microsoft® Windows client is documented here.

The Java-based user guide is documented in here.

Using QualityCentral

Before using any QualityCentral client, you must create your QC user account. You can register for QualityCentral by opening the location http://qc.borland.com/qc/BCDownloadCGI.exe/ChangePassword in a browser that supports cookies. Opening this URL brings you to a page where you can change or set your QC account password. You can use the same password you've used for your BDN membership, or use a different one. If you are not currently a BDN member or don't have your BDN user cookie set in your browser, you will be redirected to the BDN account signup page automatically to get your cookie, then brought back to the QC password page.

BDN membership is free, and gives you access to the services offered on the Borland Developer Network, including QualityCentral.

Community process

QualityCentral is a peer-supported application, where other members of the community can rate, comment, or vote on existing reports, or make their own. With QualityCentral, the community has a great impact in helping Borland prioritize the request our customers make.

QC has a workflow process that includes tiers of users who can help Borland in qualifying, classifying, and verifying the issues reported in QC. These users all help Borland to eliminate erroneous reports and refine the details on the issues reported by Borland community members and customers.

Level zero (0)

Every community member is a tier zero (0) QualityCentral user. Level zero users can

• for their own submissions:
• Create a report
• Edit a report
• Delete a report
• Classify a report
• for all submissions:
  • Rate a report
  • Vote for a report
  • Track a report
  • Comment on report or reply to a comment
  • Submit workaround on a report
  • Search

Level one (1)

Level one users are the first level of sysop. In addition to everything level zero users can do, level one users can:

• Re-classify a submission
• Approve workarounds
• Moderate comments
• Escalate (set "Needs Attention")

Level two (2)

Level two has all the rights of level one, and can also:

• verify reports as a real bug

• mark reports for migration to "official status"

• promote a user to level one

Level three (3)

Level three users can do everything level two can, and

• publish bug reports from Borland's "official" database to QualityCentral

• promote a user to level two

Web service functionality

The QC web service provides all the functionality for QualityCentral's repository. There is no undocumented interface for the QualityCentral web service. Some methods will only work for a higher level of user access rights. You can see the QC web services interfaces here.

Maximizing your QC benefits

You can get the most benefit from QC by using it "properly." This section of the user guide is describes effective techniques for posting bug reports, making feature requests and suggestions, and actually getting the bugs, features and suggestions worked on. After all, you're using QC because you want Borland to address issues you care about. This section of the user guide describes the various ways you can maximize your positive impact with QualityCentral.

Reporting bugs

For many people, the initial interest in QC will be bug reports. The principles discussed in this section discuss both obvious and subtle ways to effectively create and process bug reports.

Be specific

Write effective bug reports. Be as complete as possible when describing the bug and what happens. Include steps. The most efficient way to get a bug fixed is to provide a reproducible test case. If you can't readily reproduce it, describe as completely as you can what happened before you saw the bug.

Isolate reports

Be conscientious about submitting corollary thoughts as new reports, not just putting them in as comments for an existing report. This will ensure that the issue is tracked and (hopefully for your interest) eventually worked on.

Research bug reporting techniques

Listed below are some example pages for various bug reporting tools found on the Web. While not all of the information or examples provided here may help, in general they certainly discuss good practices that will help you both use QC effectively and get Borland to work things you care about.

• http://freshmeat.net/articles/view/149/

• http://bugzilla.gnome.org/bugwritinghelp.html

• http://www.qeradiant.com/faq/fom-serve/cache/138.html

• http://www.mozilla.org/bugs/bug-reporting.html

Making suggestions

Discussions

Understanding Duplicate reports

A "duplicate" report is marked as such by a Sysop. Which report is marked as the "master" and which a "duplicate" is based on which report gives the most accurate and detailed information describing the issue both (or many) reports discuss. The master report can change over time if someone else submits another duplicate, but that duplicate actually would describes the issue better. "Master" and "duplicate" has nothing to do with who got in first, but which report most accurately covers the issue.

All duplicates share the same status as the master. That is so you do not have to go look at the actual master to find out the status of the report. When the master is opened, closed, fixed, or whatever, all duplicates will be assigned the same status.

All votes for duplicates are automatically calculated for the master record total, so there is no need to worry about votes being ignored or lost because you voted on something that ended up being marked as a duplicate.

Duplicate records are retained because there may not be a "perfect" master report and the duplicates may provide valuable information for better explaining the issue. Once a report has been marked as a duplicate, you will not be able to delete it because people went to the effort of classifying the report and it may still provide value to other people.

If someone has taken the time to mark a report as a duplicate or comment on it, and so on, that work should not just be thrown away. Only Sysops have the rights to fully delete an item and that should be used in only extreme cases.

How to Interpret some of the fields in QC

Because QualityCentral synchronizes with internal systems, there are some fields that have meaning for our internal processes that may not have obvious meaning outside of our internal processes. The following tables will hopefully explain some of the values for these synchronized fields.

A report starts off with a status of “Reported”. When a sysop promotes the report to Borland’s internal bug tracking system, the status goes from “Reported” to “Open”. When work is completed with the report , the status goes from “Open” to “Closed”.

The “Withdrawn” status is used when the author of a report decides it is no longer valid and “withdraws” the report

The three most common verifications that you will see in QC are a blank field for a new report, ‘Closed’ for a closed report and “Reopened” for a report that was closed but needed to be reopened because there is still a problem that needs to fixed.

Most of the Resolutions are self explanatory except for “Inactive”.

“Inactive” reports  are defects that were marked "Inactive" so that R&D and QA wouldn't spend time investigating unless there was an issue that customers were currently experiencing.  Generally, these are from older versions of a product.

If a QC user sees that a current issue they are still finding painful was marked inactive, they are encouraged to have it re-opened for QA/R&D to review. If they are the owner of the report, they can open the report themselves, otherwise a Level 2 Sysop must do it for them.