Changes in Quality Portal component's list and some hints

Posted by on in Tools

Recently we've made a little change in Embarcadero’s Quality Portal to improve the way you may report issues for Rad Studio.


In the past, we received a lot of bugs for generic "Libraries and Frameworks", but those bugs were actually for VCL, Firemonkey, RTL,...  this situation required some extra time to process all that "generic" bugs. 

We've decided to update the component's list so you can target better where your issue is located. Having better reports will improve our QA process. Current list is:

  • Install
  • FireMonkey
  • VCL
  • C++ Compiler
  • C++ RTL
  • Delphi Compiler
  • Delphi RTL
  • Linker
  • Database
  • Debugger
  • IDE (Development Environment)
  • Help and Doc
  • Demos

Hints and tips for bug reporting

Give your reports a short and descriptive summary

A good summary helps to quickly identify what’s going on and help to reduce duplicated issues.

Avoid describing generic problems in the summary. You should never use:

  • I have an issue with XYZ
  • XYZ doesn’t work 

A few examples of poor summaries and their good equivalents:

  • Poor: Access violation in the IDE
    • Better!: Opening an empty .pas file raises an access violation
  • Poor: Push notification bug
    • Better!: Push notification count adds one extra notification

 Description should contain all information generated by the issue

If available, include in your description:

  • Full error message.
  • Full call stack.
  • Info about your environment (e.g. Android version or Windows locale settings).
  • Screenshots are very helpful.
  • 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.
  • If your bug report contains code, either attach it to the project or add it to the Steps section. Hint!: Use {code} tags.
  • Keep the size of the attachment to the minimum. Only use ZIP format. Never include binaries that are generated by compiling them.

Steps: the recipe to reproduce a bug

Describe the steps as a recipe to reproduce your bug. Keep steps simple and try to achieve the objective with the minimum number of steps.

Expected and Actual Results

At the end of your step-by-step description, you must describe what is the expected result and what actually happens.


  • Expected: Application shows up the XYZ menu
  • Actual: Application raises an access violation (see attached stack-trace)

One bug. One report

This is a golden rule: don't include more than one issue into one report.

Report issues separately, and link each other if needed:link




Gold User, Rank: 87, Points: 7
Quality Assurance management at Rad Studio


  • Calvin T
    Calvin T Thursday, 1 October 2015

    At this time, we do not have plans for New Feature issue type. We will take it under advisement. It will require changes to the current workflow design, so we should not attempt to change willy-nilly. In the meantime, you can add [Feature Request] tag to the summary. I will this up internally for discussion.

  • Dalija Prasnikar
    Dalija Prasnikar Sunday, 4 October 2015

    With New Feature issue type distinguishing real bugs from feature requests would be much easier.

  • Dalija Prasnikar
    Dalija Prasnikar Thursday, 1 October 2015

    Can we expect more Issue types added? For instance New Feature.

  • Daniel R553
    Daniel R553 Thursday, 1 October 2015

    Like the changes. But, I think it would be good to add to the issue types "New Feature", as it would make it easier to distinguish a feature request from a bug report. Because at the moment, the only issue types available, when creating an issue, are "Bug" and "Documentation Bug".

  • Please login first in order for you to submit comments
  • Page :
  • 1