Since its launch several years ago, QualityCentral (QC) has helped Borland's customers communicate bugs, issues, and feature requests to our product teams. For DeXter, the next release of Delphi, we know our Delphi customers want to have a very clear idea of the level of quality in the release. The quality of Delphi is very important to us, and we have increased our efforts to have the highest level of quality possible in the initial release of DeXter.

We want to communicate the work that we're doing to make DeXter a solid release, and respond to the valuable feedback we've received from current Delphi programmers via QualityCentral. We are now updating the status of QualityCentral reports pertaining to the C#Builder, C++Builder, Delphi, and Delphi .NET projects in QualityCentral. DeXter will contain personalities for these three languages (C#, C++, Delphi) and two platforms (Win32 and .NET), so we have been fixing bugs and implementing features reported in QualityCentral for all of these projects.

There are some differences in the way reports appear in QualityCentral, and I would like to explain them to give you some context for some statistics I'll be providing later.

    Published vs. Customer reports

    Internal Reports

Until now, the reports in QualityCentral were not updated until the product in question was released to manufacturing. We have now changed this policy, and have started frequent updating of report status as the bugs are addressed by our product teams. We are pioneering this new policy with Delphi, because our Delphi community has always been one of our most active customer groups.

This means that we will now inform you of bug fixes very near to the time the fix appears in an internal build. However, you will still not see that bug fix until we either release a patch containing the fix, or release a new product version. The Resolved in Build value in QualityCentral is what you will need to look at to know whether or not a specific fix is publicly available.

Let's look at an example. Use this search URL (http://qc.borland.com/wc/qcmain.aspx?search=1&proj=10&rib=10.0.2098.14501) to retrieve some of the Delphi project reports I recently updated with a specific DeXter build. This link should return 37 or so reports. The search=1 simply means it's a search. proj=10 selects the Delphi (Win32, main IDE) project. rib=10.0.2098.14501 means "resolved in build." If you select one of the reports in the search results above, such as QC#14558, you will see the Resolved in Build value is set to 10.0.2098.14501, which is the DeXter build number I used when pushing out updates for the QC reports.

Build 10.x means "Delphi version 10", which is the product version we call by the DeXter code name. This search URL is automatically created by the QualityCentral web client search page by redirecting you to the search page again after you fill in the criteria for which you want to search.

There are several different types of resolutions for reports that are used by our QA and R&D teams. You will see resolutions like Fixed, Duplicate, Test Case Error, Need More Info, and so on. When a report is marked as a duplicate of another report, its status changes as the "master" report status changes.

The QualityCentral statistics prototype can show you percentage breakdowns by resolution type.

If you want to know exactly what the resolution for a specific report is, you can click on the Resolution Comments link next to the word describing the resolution to get the history of status changes for the report. For the report mentioned above, the link http://qc.borland.com/wc/qcmain.aspx?rc=14558 displays the resolution comments.

The updating of bug status from the internal system does not occur automatically, because it would result in far too many build versions being set as the Resolved in Build value. I started updating QC reports a few weeks ago, and we'll continue to update it every few weeks. We will publish updates throughout the DeXter development cycle, so you can track the improvements yourself and watch the quality of the product improve.

Since QC reports have been updated a few times for DeXter builds, there are more reports than the 37 you'll find above that have been addressed for the Delphi project in the DeXter release.

When I wrote this article, the results of QC reports closed because of work done up to and including the current DeXter build is listed in the QC resolutions column in the Tallies table below.

As I mentioned previously, reports that begin with "(Pulled)" in their short description are reports that did not exist at all in QC until they were published from the internal system. Some of these reports have actually been published manually before, by our Developer Support department. Most of those reports were published before QualityCentral even existed. Since we now have QualityCentral, future publishable reports will be available from there.

The Published resolutions column in the Tallies table shows the number of new, closed reports published to QC from our internal tracking system. This does not mean that all these bugs were actually fixed in DeXter, because many of them predate DeXter. You can look at the Build Number to see what version of the product they were originally reported against. In particular, the C++Builder number includes the backlog of all previously unpublished "public" bug fixes from our internal system, which is why it's so high.

The QC fix counts as of September 30, 2005 are listed in this table. The project named in the QC project name column contains a link to display the search results directly in QualityCentral for each of the four projects comprising DeXter. Your mileage (fix count) may vary when looking at the link on the QC project name, though. See the explanation below the table for the reasons why.

Please note: If you click on the search links for the QC projects listed above, your numbers will be different than those I display in this table. Some of these bug reports are currently only visible to QC sysops and DeXter field testers. Some of the bug reports are Automated Incident Reports (AIR) which are automatically generated by the IDE. AIRs are only visible to Borland. You can learn more about AIRs from this BDN article, which unofficially introduced them for Delphi 8, and this Blog entry by Allen Bauer that describes what they do. They have been an official feature of the product since Delphi 2005, and have already helped us fix bugs that were previously very difficult to track down.

Also, the number you will retrieve by using the search links above is not just for reports originally entered in QC, but also for internal bug reports that were marked for public consumption. I've customized the queries I was using to filter on "(Pulled)" to distinguish between reports that originated in QC, and those that were pushed out from the internal system.

Even with the extra bug closures from C++Builder, the bottom line is still great: to date, we have addressed almost 500 QC reports entered by Delphi, C++Builder, and C#Builder customers. We have already been hearing from people who are quite happy that bugs they've encountered have been fixed. We will continue to fix bugs for DeXter, and keep right on going after that for Highlander and beyond.

If you want to know the status of bugs you are particularly interested in, you can check back every other week or so on QualityCentral as we update the report status, or turn on notifications for that specific report or QC area and QC will automatically notify you when the report is closed.

If you want to get the big picture (literally!) of the progress on DeXter, use the QC statistics reporting prototype to get trends and percentages of the projects in QualityCentral.

We would like to thank you for using QualityCentral and making it such a success, and we sincerely hope you like the great quality we will deliver for DeXter. Keep getting those QC reports in, and we'll do everything we can to address any issues by the time we ship DeXter (currently planned to ship before the end of 2005).

In summary, I would like to repeat that we are completely committed to a high quality release in DeXter, and we are being more open about our quality process than ever before, with frequent updates to QC reports, BDNradio broadcasts, articles, blogs, and more. We are doing all this not only to prove our commitment to delivering a quality product to our customers, but also to encourage you to increase your dialog with us on QualityCentral. QualityCentral works, and the product teams really do use it to help prioritize feature development and fix defects in our products.

Please continue helping us make our products as good as they can be, so we can continue to deliver the industry's best software development tools to you. Thank you.