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
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.
Status Field |
Value |
Description |
Open |
Open defect, requires resolution |
Resolved |
Resolved defect, requires verification |
Pending |
Requires additional information/steps |
Closed |
Closed defect, no action required |
Reported |
New defect, requires tester review |
Withdrawn |
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 |
Value |
Description |
Verified |
Resolution has been verified |
Not Resolved |
Resolution not approved |
Closed |
Product with bug resolution has shipped |
Reopened |
Defect report was reopened |
Disputed |
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 |
Value |
Description |
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 |
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 |
Retest |
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 |
Readme |
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 |
Inactive |
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.
Connect with Us