I am one of the currently most active QC sysops and do review thatswhy a part of the incomming QC reports. While doing so I do see mistakes in the reports and I just want to tell you about the common mistakes including some hints. When you follow my hints and advices you do yourself a favor and not me. I am sysop on voluntary basis and am not forced to process your reports.
First of all the biggest mistake is not to report an issue, because you do not believe that it will get fixed.
I do not want to expand on that here. There have been a lot discussions on that already and I do have better things to do than trying to convince users with a wrong attitude to report their issues.
Build No
In this field belongs the full version number of RAD Studio and in the case of XE Update #1 this number is 15.0.3953.35171. I have seen at least a half dozen reports by different reporters that entered 7600. (Right that is the build number of their OS [Windows 7 RTM].)
Why is it important to enter the build number when you have already selected 15.1 in the version field?
By original design there should only be a version 15.0 and no version 15.1, because there is no 15.1 product and you should see that till Delphi 2006 largely only .0 version exists, although these versions got more or less updates each. So the build number is required to know which update or hotfix the user is using. For example if you see a specific problem only with the latest IDE compiler hotfix for XE then you would enter 15.0.4066.37021.
The QC Win32 client (in the IDE: Tools | Quality Central) and QC Plus have here options that do release you from manually entering the build number.
Language/Nationality
In this field belongs US for every issue that is not related to your localized version. For every issue that is related to the localized version like truncated text or wrong translations you can enter the language of the localization you are using. I do see regularly compiler reports with a language different from US, but almost all of the compiler issues are not related to the localization.
Carefulness is necessary here, because if the sysop does not see that the language is wrong and does fix it then the issue gets first unnecessarily assigned to the localization team. This consumes unnecessarily resources and may lower the chance that your issue does get fixed soon.
Type and Severity
These both fields would deserve an own post and thatswhy I just tell you the most important things here. One thing is that you should try to see type and severity from the perspective of all users. I hear here regularly from the users that they do not know all the other users, I do not know them either (it are supposed to be several millions), but if you do enter a way too high type and severity then do not wonder when this is changed by a sysop or later by QA. I do see regularly people entering A 0 for minor issues. Well for them this might be major issue, but bugs that affect more user get fixed first.
Another hint for compiler errors – in case of a “F2084 Internal Error: …” please do select A as type. BTW, how to track down an internal compiler error would also deserve an own post.
Steps
Please do add steps to your report even if you think they are obvious and include which behavior you do expect and which behavior you do see. With good steps it is more likely that the error you do see does get fixed and not any other error in that area.
I should also tell you that a report needs to be repeatable in order to get opened.
In combination that means if you report an internal compiler error without a test case and your report gets marked a duplicate of an existing issue then it is not unlikely that your issue does not get fixed, because a lot of test cases produce the same internal error, but the fixes for them are different.
In case you need example reports then have a look at mine.
Automated Reports
Part of the RAD Studio IDE is Quality Insight that is built on top of the JCL stack tracing feature. These reports are also called AIR reports and go into the Delphi.Net project in QC. That is due to historical reasons and should not worry you. I have seen people changing the project of their AIR’s – please refrain from changing the project of these reports to Delphi or C++Builder! A data mining tool processes the AIR’s and it does not look in the Delphi or C++Builder project. Changing the projects to process is more complicated than you might think and if you want to get your report processed do not change it’s project.
Voting
A new voting system has been introduced at the end of 2007 and now you have at least +/- 10 votes for each report and not at all. I do very often see vote amounts not dividedable by 10 and that is because people do use the web client, which is unfortunately not aware of the new voting system. Use the Win32 client or QC Plus.
Questions
No this is not a mistake… If you have any questions about (your) QC reports then ask them in the QC newsgroup.
BTW, if you are not satisfied how fast Embarcadero fixes your bugs this blog is definitely not the place to complain about!
QC Plus is no longer mantained (http://www.jed-software.com/qc.htm) although it could work for a while still. The Win32 QC client would really need an overhaul.
Thanks for letting the readers know. I am aware that QC Plus is not longer maintained, but IMHO it is still the better alternative and having it mentioned would probably make the people hesitant to try QC Plus.
I’d definitely be interested in seeing your hypothetical future post on tracking down compiler errors. You’ve helped me out with that a few times, and your ability to do so borders on the magical IMO. I’d love to be able to add some of your tricks to my repertoire.
I hope I can get some training before that post. Don’t expect this post soon. I should also talk with QA about the options for big proprietary “test cases”.