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.
The user guide specific to the Microsoft® Windows client is documented here.
The Java-based user guide is documented in here.
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.
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.
Every community member is a tier zero (0) QualityCentral user. Level zero users can
Level one users are the first level of sysop. In addition to everything level zero users can do, level one users can:
Level two has all the rights of level one, and can also:
Level three users can do everything level two can, and
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.
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.
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.
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.
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.
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.
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.
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.
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
Resolution has been verified
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.
Bug has been fixed
Deferred to Next MS
Bug has been deferred next milestone
Cannot Reproduce Bug
Bug could not be reproduced as submitted
Behavior is as designed
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
To be delivered
Third party problem
Cannot fix (vendor problem)
Defer to Inline
Fix for the In-line release
Document in Readme
The bug is no longer relevent
Defer fix until after RTM via Web Update
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