Embarcadero’s Quality Portal provides a community process for resolving, clarifying, and tracking quality issues regarding Embarcadero’s products and services. Embarcadero customers with an EDN account can create bug reports and feature requests, view other customers’ 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.

Developers who have active Support and Maintenance contract and need an urgent response on a query should raise a support ticket instead: A Quality Portal record is not the same as a Support ticket.

This guide is here to help you to report issues about the RAD Studio product, including Delphi and C++Builder. This blog post updates and supersedes the post at https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/

Using Embarcadero’s Quality Portal

Before using Quality Portal (QP), you must create your EDN user account (EDN stands for Embarcadero Developers Network). Go to https://my.embarcadero.com to create your account, if you don’t have an existing one. This is the same account you can use to register an Embarcadero product.

With your account, go to https://quality.embarcadero.com/ and login to Quality Portal (or QP). Notice that the login on QP requires you to use your EDN username and not the associated email address.

Community Process

Quality Portal is a peer-supported application, where other members of the community can comment or vote on existing reports, or create 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.

I mentioned above already, but it’s worth repeating, that Embarcadero offers also a technical support program, which you can reach online at https://www.embarcadero.com/support, including both installation and registration support and a number of technical support tickets (depending on your support level). If you want immediate attention for an issue, please use Embarcadero Support and not Quality Portal.

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. In case you have a reproducible test case, but don’t want to share the code on the public QP system for any reason, we can arrange for a direct and more private submission process: Please indicate this in the report itself. Notice also that for some product areas like CodeInsight and FireDAC there are specific steps to provide us with log information, as explained in the tips section at the end of this blog post.

Golden rule: include only one issue into each report.

Issue Type

• Bug: An issue with the product
• Documentation bug: An issue with help or product documentation.
• Feature Request: A new feature you’d like to see in the product

Notice that feature requests follow a different path: They are vetted by Product Managers (rather than the QA team) and assigned to developers for research or implementation in a future release.

Occasionally, we convert an issue from a type to a different one, for example when a bug report can really be addressed by adding a significant feature to the product or in case of an incorrect filing by the customer.

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 eventually worked on.

Understanding Duplicate reports

A “duplicate” report is marked as such by the 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 describes the issue better. “Master” and “duplicate” have nothing to do with who got in first, but which report most accurately covers the issue.

Typically, a “duplicate” issue has “Resolved” status,  a “Duplicate” resolution,  and is linked to the“master” issue with a “duplicates” link. You must check the status and watch updates of 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

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 and the fix is part of a released product, the status goes from “Open” to “Resolved”. Notice that an issue is marked as resolved only when the fix is available, not when it is implemented internally by R&D.

Resolution Field

For issues that are returned with Needs More Info, the status will be marked as ‘Needs Feedback’ to allow the reporter to add additional information. You must use the “Update Content” button when submitting additional information. Once changes submitted via ‘Update Content’ status gets back to ‘Reported’ and the QA team will repeat validation internally. “Update content” may also be used when corrections are made to an already submitted issue.

Generally try to clarify description adding more details and/or context info using the recommendations given above or add/review steps to reproduce. Attaching screenshots and/or projects would be helpful as well. A short and focused video can also be good to understand.

Logs and Some More Tips

For issues related with CodeInsight LSP engine, please refer to the information at the end of this docWiki article. Notice that the LSP logs might contain significant portions of the source code being parsed, so if there are reasons to keep it reserved please ask for a direct communication channel rather than adding the log file to a public QP report.

Similarly, if you are reporting FireDAC issues you should provide environment data and tracing logs. The steps are covered in this article.

In terms of installation and GetIt packages (as you can read in the DocWiki), the GetItInstall.log file is controlled by the setting in

and can be found in a folder like:

You can refer to the QP text formatting tips of the original article at https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/#Hints_and_Tips

Finally, a good source of recommendations for reporting bugs is available at http://www.mozilla.org/bugs/bug-reporting.html.

---

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

---