GETTING THE MOST OUT OF YOUR BUG TRACKING SYSTEM (BTS)

Rahul V Shah
Sibridge Technologies
rahulv.shah@sibridgetech.com

Bug tracking systems play a key role in the verification stage of a chips development cycle. Freely available Bug Tracking Systems (BTS) like Bugzilla and Mantis facilitate the process of tracking and reporting bugs.

A database acts as the backbone for most bug tracking systems. The automation level which can be achieved with open source database based BTS is still underestimated. Many teams generate customized reports manually using spreadsheet after filling in data from the BTS. Most engineers are still unaware about various reports which BTS can provide. This kind of tunnel vision can hamper the proper analytical usage of the BTS data.

Here are some features which can be easily deployed to get the most out of your BTS system. The following examples are derived using Mantis BTS system. Mantis is a PHP and MySQL based BTS which can be easily integrated with Perl.

Save valuable time by using BTS to kick off regressions
Many projects are executed at two different locations in vatly different timezones, for instance a verification team based in India with the design team in California, a 12 hour time difference This time difference can be efficiently utilized during regression phase.

In verification cycle when the verification has reached a mature state, regressions can take between a couple of hours to a couple of days. Traditionally an offshore verification team will find a bug and report it to the remote design engineer. The design engineer may be able to fix the bug in no time and change the bug status to resolve and make a new release. Due to the twelve hour time difference, the verification team will only be able to check the status of the bug, update to the new
release and re-run the regression only after they have read the email next morning from BTS for the updated status.

BTS systems like Mantis provide a feature of adding custom fields to the bug reporting form. By adding a custom field called “Test Case Name” the verification engineer can report the bug along with the test case name and location. A simple Perl script can periodically poll the open bugs to check any change in the status of a bug to “Resolved”. As soon a status change is detected, the script can extract the data out of the “Test Case Name” field and run the test cases after updating
the RTL. If the test case passes, the script can report back to the designer as well as the verification engineer via email. A regression can be automatically kicked off by the script upon successful run on the new release. The complete process is a cinch to implement, but it can save huge number of hours over the entire duration of the project