Rad Studio Quality Portal user guide
Embarcadero’s Quality Portal 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 Quality Portal, providing a permanent link between Embarcadero customers and the teams who produce Embarcadero's products. This guide is here to help you to report issues about Rad Studio product.
Using Embarcadero’s Quality Portal
Before using Quality Portal (QP), you must create your EDN 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 Quality Portal.
Community process
Quality Portal is a peer-supported application, where other members of the community can comment or vote on existing reports, or make their own. With Quality Portal, the community has a great impact in helping Embarcadero prioritize the request our customers make. You can "Watch" other users issues, to get notified when they are updated.
Maximizing your Quality Portal benefits
You can get the most benefit from QP 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 QP 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 Quality Portal.
Reporting bugs guide
For many people, the initial interest in QP will be bug reports. The principles discussed in this section discuss both obvious and subtle ways to effectively create and process bug reports.
You will see a form similar to:
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. Bug reports must provide all the required information in one place.
Golden rule: include just one issue into one report.
Issue Type
Bug: An issue with the product
Documentation bug: An issue with help or product documentation.
Summary
Give the report a short, but descriptive summary. “TButton is not working” is not a good title, but “[Android] An error is raised when TButton is invoked by double tapping” is better.
When appropriate, use tags in the title to help whoever reads it understand the context better.
A good summary helps to quickly identify what’s going on and help to reduce duplicate issues. Avoid describing generic problems in the summary. You should never use:
- I have an issue with XYZ
- XYZ doesn’t work properly
A few examples of poor summaries and their good equivalents:
==Poor: ==Access violation in IDE
==Better: ==Opening an empty .pas file raises an access violation
==Poor: ==Push notification bug
==Better: ==Push notification count adds one extra notification
Component
Identify which sub-part of the software is affected by this bug.
- Install
- FireMonkey
- VCL
- C++ Compiler (see C++ Compiler / Linker bug submitting hints)
- C++ RTL
- Delphi Compiler
- Delphi RTL
- Linker (see C++ Compiler / Linker bug submitting hints)
- Database
- Debugger
- IDE (Development Environment)
- Help and Doc
- Demos
Description
All the information generated by the issue. Where available, include:
- Full error message
- Full call stack
- If you think it is relevant, include info about your environment (e.g. Android version or Windows locale settings)
- For bugs that manifest themselves visually (e.g. Controls not being displayed properly or IDE layout issues) include a screenshot to help whoever reads your report to evaluate it.
- If relevant add device logs, like logcat output for Android.
- For error messages or call stacks use either {code} or {quote} tags.
- If you base your report on an external source of info (e.g. MSDN page for an API call), include a link to that info
- If your bug report contains code, either attach it to the project or add it to the Steps section. If you add code as text to your report, make sure to use {code} tags. This stops JIRA from interpreting your code and messing it up and also helps with the readability of the report (avoids scrolling a few pages to get to relevant fields).
- Keep the size of the attachment to the minimum. ZIP your files and never include binaries that are generated by compiling them (e.g., DCU’s or EXE’s). Only use ZIP format, never use other formats that require a 3rd party program.
- Don't include more than one issue into one report. Report separately, and link each other as needed.
Steps
The goal is to show how to reproduce the bug. Keep it concise and easy to read, you should describe it as a recipe to reproduce the bug. Try to achieve the objective with the minimum number of steps.
Note: Error messages or Call stacks go in the Description, not Steps. For example, Description should say “The following error is raised when invoking TButton by double tapping it on my Android device: [error message]” and the Steps should just provide instruction as to how to reproduce the issue.
Expected and Actual Results
At the end of your step-by-step description, you must describe what should be the expected result and what actually happens.
Example of a poor description:
Expected: Application doesn’t crash
Actual: Application crashes
Better use:
Expected: Application shows up the XYZ menu
Actual: Application raises an access violation (see the attached stack-trace)
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 QP effectively and get Embarcadero to work things you care about.
Understanding Duplicate reports
A "duplicate" report is marked as such by QA team. 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.
Typically, a “duplicate” issue has "Resolved" status and "Duplicate" resolution, linked to “master” issue with “duplicates” link. You must to check status and watch updates at the "master" issue.
How to interpret some of the fields in QP
Because Quality Portal 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 |
|---|---|
| Reported | New defect, requires tester review |
| Open | Open defect, requires resolution |
| Resolved | Internal work done, reporter can verify or dispute resolution |
| Needs Feedback | Requires additional information/steps |
| Closed | Closed defect, no action required |
A report starts off with a status of “Reported”. When an Embarcadero QA tester validates it in 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 “Resolved”.
Resolution Field
Value |
Description |
|---|---|
| Fixed | Bug has been fixed |
| Cannot Reproduce | Bug could not be reproduced as submitted |
| Works as Expected | Behavior is as designed |
| Duplicate | Bug is a duplicate (must note dup bug #) |
| Test Case Error | Bug description is invalid as submitted |
| Needs More Info | Need more information/demo/steps |
| No Longer Applies | Feature has been removed or the bug is no longer relevant |
| Won't Fix | This will never be implemented or fixed |
For issues that are returned with Needs More Info, the status will be marked as ‘Needs Feedback’ to allow reporter to add additional information. You must use “Update Content” button when submitting additional information.Once changes submitted via ‘Update Content’ status gets back to ‘Reported’ and QA team will repeat validation internally. "Update content" also may be used in case after issues submitted appeared it need some corrections.
Generally try to clarify description adding more details and/or context info using the recommendations given above or add/review steps to reproduce. Attaching sreenshots and/or projects would be helpful as well.
Hints and Tips
Text effects and code format
Text effects are used to change the formatting of words and sentences. This contributes to create clean and neat bug reports easier to understand.
*strong*
Makes text strong.
_emphasis_
Makes text emphasis..
??citation??
Makes text in citation.
-deleted-
Makes text as deleted.
+inserted+
Makes text as inserted.
^superscript^
Makes text in superscript.
~subscript~
Makes text in subscript.
{{monospaced}}
Makes text as monospaced.
bq. Some block quoted text
To make an entire paragraph into a block quotation, place "bq. " before it.
Example:
Some block quoted text
{quote} here is quotable
content to be quoted {quote}
Quote a block of text that's longer than one paragraph.
Example:
here is quotable
content to be quoted
{color:red} look ma, red text! {color}
Changes the color of a block of text.
Example:
look ma, red text!
Notation
Comment
Code format improves how code is presented
{code:delphi}
program Sample_prog;
begin
write('Hello World. Prepare to learn Delphi');
readln;
end.
{code}
program Sample_prog;
begin
write('Hello World. Prepare to learn Delphi');
readln;
end.
{code:c++}
- include
int main()
{
std::random_device random_device;
std::mt19937 random_engine{random_device()};
std::bernoulli_distribution coin_distribution{0.25};
bool outcome = coin_distribution(random_engine);
}
{code}
#include
int main()
{
std::random_device random_device;
std::mt19937 random_engine{random_device()};
std::bernoulli_distribution coin_distribution{0.25};
bool outcome = coin_distribution(random_engine);
}
Notation
Comment
Sample bug
Here it is a sample bug with all concepts explained above: https://quality.embarcadero.com/browse/RSP-12206