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: 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.

• http://www.mozilla.org/bugs/bug-reporting.html

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

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

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.

Code format improves how code is presented

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

---