QualityCentral general user guide

By: John Kaster

Abstract: Read this for an overview of QualityCentral before reading the client-specific user guides

(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 Embarcadero's products and services. Embarcadero Developer Network (EDN) members can create bug reports and feature requests, view other members' reports, and comment and vote on the reports most important to them. Embarcadero personnel also participate in QualityCentral, providing a permanent link between Embarcadero customers and the teams who produce Embarcadero'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 CDN user account. Go to https://members.embarcadero.com to create your account, or login if you already have an existing account.

EDN membership is free, and gives you access to the services offered on the Embarcadero 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 Embarcadero prioritize the request our customers make.

QC has a workflow process that includes tiers of users who can help Embarcadero in qualifying, classifying, and verifying the issues reported in QC. These users all help Embarcadero eliminate erroneous reports and refine the details on the issues reported by 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 Embarcadero’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 Embarcadero 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 Embarcadero to work things you care about.

Making suggestions


    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.

Status Field




Open defect, requires resolution


Resolved defect, requires verification


Requires additional information/steps


Closed defect, no action required


New defect, requires tester review


Report has been withdrawn by submitter

A report starts off with a status of “Reported”. When a sysop promotes the report to Embarcadero’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

Verification Field




Resolution has been verified

Not Resolved

Resolution not approved


Product with bug resolution has shipped


Defect report was reopened


QA disputes resolution

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.

Resolution Field




Bug has been fixed

Deferred to Next MS

Bug has been deferred next milestone

Cannot Reproduce Bug

Bug could not be reproduced as submitted

As Designed

Behavior is as designed

Duplicate Bug

Bug is a duplicate (must note dup bug #)

Test Case Error

Bug description is invalid as submitted

Need More Info

Need more information/demo/steps

Deferred to Next Release

Bug has been deferred until the next release


Please retest in the current build

Checked In

To be delivered

Third Party

Third party problem

Cannot Fix

Cannot fix (vendor problem)

Defer to Inline

Fix for the In-line release


Document in Readme

Feature Removed

The bug is no longer relevent

Web Update

Defer fix until after RTM via Web Update

Won't Do

This will never be implemented or fixed


Defect has been deactivated

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.

For issues that are returned with Needs More Info or Cannot Reproduce, the status will be marked ‘Pending’ to allow Sysops or community members to add comments with the additional information. Generally contact information and description of required information/steps will be provided so that Embarcadero can investigate a difficult to reproduce issue.

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.

Server Response from: ETNASC04