Site icon Embarcadero RAD Studio, Delphi, & C++Builder Blogs

Rad Studio Quality Portal user guide

Embarcadero Archives

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

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:

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.

Description

All the information generated by the issue. Where available, include:

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.

 

[crayon-672a2425d1e43534669919/] Makes text strong.
[crayon-672a2425d1e4e850842907/] Makes text emphasis..
[crayon-672a2425d1e50310309479/] Makes text in citation.
[crayon-672a2425d1e52071343902/] Makes text as deleted.
[crayon-672a2425d1e53100651517/] Makes text as inserted.
[crayon-672a2425d1e55719240901/] Makes text in superscript.
[crayon-672a2425d1e56104458917/] Makes text in subscript.
[crayon-672a2425d1e57101601346/] Makes text as monospaced.
[crayon-672a2425d1e59200188923/]

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

Example:

Some block quoted text
[crayon-672a2425d1e5a386898626/]

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

Example:

here is quotable
content to be quoted
[crayon-672a2425d1e5b250461696/]

Changes the color of a block of text.

Example:

look ma, red text!
Notation
Comment

 

 

 

Code format improves how code is presented

 

[crayon-672a2425d1e5d256522276/] [crayon-672a2425d1e5e856894093/]
[crayon-672a2425d1e60575763856/]
[crayon-672a2425d1e61239113189/]
[crayon-672a2425d1e62218178281/]
[crayon-672a2425d1e64192577466/]

{code:c++}
#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);
}
{code}

 [crayon-672a2425d1e65924590005/]
[crayon-672a2425d1e66008043216/]
[crayon-672a2425d1e67385334133/]
[crayon-672a2425d1e68421872418/]
[crayon-672a2425d1e6a121900784/]
[crayon-672a2425d1e6b763341802/]
[crayon-672a2425d1e6c674159665/]
[crayon-672a2425d1e6d139951735/]
Notation
Comment

 

Sample bug

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

 

Exit mobile version