Have an amazing solution built in RAD Studio? Let us know. Looking for discounts? Visit our Special Offers page!

Rad Studio Quality Portal user guide

Author: Juan Antonio Ruzafa

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-3911321 Bug: An issue with the product
  • documentation-1368488 Documentation bug: An issue with help or product documentation.


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


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


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.


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

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

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.


Makes text strong.
Makes text emphasis..
Makes text in citation.
Makes text as deleted.
Makes text as inserted.
Makes text in superscript.
Makes text in subscript.
Makes text as monospaced.

To make an entire paragraph into a block quotation, place “bq. ” before it.


Some block quoted text

Quote a block of text that’s longer than one paragraph.


here is quotable
content to be quoted

Changes the color of a block of text.


look ma, red text!





Code format improves how code is presented


#include <random>

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);



Sample bug

Here it is a sample bug with all concepts explained above: https://quality.embarcadero.com/browse/RSP-12206


Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.